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

From vyazici at openjdk.org  Fri Jul 11 08:40:40 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 11 Jul 2025 08:40:40 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics
In-Reply-To: <4dolSfV2QJhf4nW0zxQ3Z6hti93KWU1PD9sYvXfYDnc=.307324ef-6bad-43ce-9397-e39abcfad410@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <4dolSfV2QJhf4nW0zxQ3Z6hti93KWU1PD9sYvXfYDnc=.307324ef-6bad-43ce-9397-e39abcfad410@github.com>
Message-ID: <w_UNRtKLIrLTYOorLnJUZBAW5VFt8uten6KXUwAUwwI=.54ceb4fb-85d0-465a-a5a9-9711546ad5bb@github.com>

On Thu, 10 Jul 2025 20:54:24 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` 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...
>
> I disagree with a small part of the statement of goals:
> 
>> Always validate all input at the intrinsic (but preferably behind a VM flag)
> 
> As formulated above, this is a violation of DRY and if embraced the wrong way will lead to code that is harder to review and prove bug-free.  Performing 100% accurate range/null/validation checks is deeply impractical for an assembly-based or IR-based intrinsic.  It?s too hard to verify by code review, and coverage testing is suspect.
> 
> We must frankly put all the weight of verification on Java code, including Java bytecode intrinsic behaviors.  Java code is high-level and can be read mostly as a declarative spec, if clearly written (as straight-line code, then the intrinsic call).  Also, such simple Java code shapes (and their underlying bytecodes) are tested many orders of magnitude more than any given intrinsic.
> 
> I see two bits of evidence that you agree with me on this: 1. The intrinsic-local validation (IR or assembly) is allowed to Halt instead of throw, and 2. the intrinsic-local validation is optional, turned on only by a stress test mode.  This tells me that the extra optional testing is also not required to be 100%.
> 
> Thus, I think the above goal would be better stated this way:
> 
>> Validate input in the IR or assembly code of the intrinsic in an ad hoc manner to catch bugs in the Java validation.
> 
>> Note:  IR or assembly based validation code should not obscure the code or add large maintenance costs, and under a VM diagnostic flag (or debug flag), and causing a VM halt instead of a Java throw.
> 
> I think I'm agreeing with you on the material points.  It is important to summarize our intentions accurately at the top, for those readers that are reading only the top as a summary.

@rose00, thanks so much for the feedback. I agree with your remarks and get your points on _"Always validate all input at the intrinsic"_ is a violation of DRY and an impractical goal.

I incorporated your suggestions as follows:

1. Renamed the ticket to `Move input validation checks to Java for String-related intrinsics` (to better reflect the goal)
2. Replaced `Always validate all input at the intrinsic...` with your suggestion

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

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3061201145

From cstein at openjdk.org  Fri Jul 11 09:10:19 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 11 Jul 2025 09:10:19 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 8
Message-ID: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>

Please review the change to update to using jtreg 8.

The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

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

Commit messages:
 - 8361950: Set required version to 8+2
 - 8361950: Update to use jtreg 8

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

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

From mgronlun at openjdk.org  Fri Jul 11 09:34:13 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 11 Jul 2025 09:34:13 GMT
Subject: RFR: 8361640: JFR: RandomAccessFile::readLine emits events for
 each character
In-Reply-To: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
References: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
Message-ID: <fDox2b1axouS3fkLXeu7bq2LFj0V4z6IgyqvsoBlCMY=.cc684f5b-69fc-4d55-9310-d206732d39c7@github.com>

On Wed, 9 Jul 2025 05:45:01 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of the change that prevents RandomAccessFile::readLine from emitting an event per character? This leads to unnecessary overhead, both with or without JFR enabled.
> 
> Testing: tier1 + tier2 +  jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26210#pullrequestreview-3009487213

From duke at openjdk.org  Fri Jul 11 09:52:12 2025
From: duke at openjdk.org (Pooja-DP)
Date: Fri, 11 Jul 2025 09:52:12 GMT
Subject: RFR: 8361697: Remove duplicate message  in MainResources.properties
Message-ID: <apRAelAuEvvGzVSK4_pllZvS9hloXO3UE6_2CRuCX28=.0d98fffe-f426-4523-b03d-a9d9bda81799@github.com>

Bug reference: https://bugs.openjdk.org/browse/JDK-8361697

The following message is removed:

`
MSG_BundlerFailed=Error: Bundler "{1}" ({0}) failed to produce a package`

Signed-off-by: Pooja.D.P1 <Pooja.D.P1 at ibm.com>

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

Commit messages:
 - Update MainResources.properties with duplicate message removal

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

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

From duke at openjdk.org  Fri Jul 11 10:21:14 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 11 Jul 2025 10:21:14 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v5]
In-Reply-To: <Up5dXvSL6OJUERTIkXI0VnrvwcSwmbNyn8Pjaxl5Sbk=.bfec5c6d-a5c8-44e8-bbb0-5d95f639bfde@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <xHDzjd4IbbYATwuK9I7oZ35Em3Rr9pfWaG3WOk_3lyk=.005270ef-7dba-459c-a653-8912f105ee6b@github.com>
 <Up5dXvSL6OJUERTIkXI0VnrvwcSwmbNyn8Pjaxl5Sbk=.bfec5c6d-a5c8-44e8-bbb0-5d95f639bfde@github.com>
Message-ID: <VpbUI7STHbvevqFqWcLlJewe7T9pz8YVjS8uaJqsQO8=.3ececa54-15ff-4c39-9adc-92ca26c24a1c@github.com>

On Fri, 4 Jul 2025 12:40:43 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

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

Yes, good point. I was simply keeping it "as lazy as it was", but you're right, that train has already left the station.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2200307185

From duke at openjdk.org  Fri Jul 11 10:52:58 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 11 Jul 2025 10:52:58 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v6]
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: <_xVIJlVMVEHjSMYk-XjFuaRqPC_yQ7c-GJF6uKb7KyM=.c4d73ce1-a085-4582-92e7-e76e3cf62827@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:

  Make image file attributes non-lazy (simpler code). Plus minor tweaks of code and comments for clarity.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26054/files
  - new: https://git.openjdk.org/jdk/pull/26054/files/df1705ce..43303574

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

  Stats: 47 lines in 1 file changed: 12 ins; 16 del; 19 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 rgiulietti at openjdk.org  Fri Jul 11 12:41:43 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 11 Jul 2025 12:41:43 GMT
Subject: RFR: 8077587: BigInteger Roots [v18]
In-Reply-To: <EPMNChZccG151dVhM5NjfVkNaHxmkBQ7uClT2JzrjBY=.57de2188-2baa-4877-b20d-2a86a3d17053@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <EPMNChZccG151dVhM5NjfVkNaHxmkBQ7uClT2JzrjBY=.57de2188-2baa-4877-b20d-2a86a3d17053@github.com>
Message-ID: <03GYPzx7uKkVYO4vE0C6sD0AFpuLqZqfYQmpuGLInbo=.314dcd3a-faf2-4ecf-b3a3-0df47a7b9ad2@github.com>

On Fri, 6 Jun 2025 08:08:09 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update "since" version

Sure, the initial value computed in the current commit of the PR is better, but I wonder if this makes any difference in practice, precisely because the Newton-Raphson method is so efficient anyway (but only measurements might tell).

On the other hand, the code contains about 80 lines just to find the initial estimate. To ensure that the code is readable and maintainable, it either needs to be documented better, possibly with math, or simplified so that the correctness becomes obvious even without comments.
Performance is not the only dimension we care about in the JDK. Readability and maintainability are even more important in the long term.

In any case, some comprehensive tests need to be added as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3062181616

From mbaesken at openjdk.org  Fri Jul 11 12:51:22 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 11 Jul 2025 12:51:22 GMT
Subject: RFR: 8361959: [GCC static analyzer] java_props_md.c  leak of 'temp'
 variable is reported
Message-ID: <RqEj6H9uqBuW5LmTcU73gzQNAQnQLgUDWoqfaxIHLBw=.a9871b5c-c36c-433b-8091-8f0648669836@github.com>

The following is reported when building with the gcc static analyzer (-fanalyzer) :


/jdk/src/java.base/unix/native/libjava/java_props_md.c:244:17: warning: leak of 'temp' [CWE-401] [-Wanalyzer-malloc-leak]
  244 | return 0;


Seems we have to free temp in an early return.

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

Commit messages:
 - JDK-8361959

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

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

From shade at openjdk.org  Fri Jul 11 13:07:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 13:07:38 GMT
Subject: RFR: 8361959: [GCC static analyzer] java_props_md.c  leak of
 'temp'  variable is reported
In-Reply-To: <RqEj6H9uqBuW5LmTcU73gzQNAQnQLgUDWoqfaxIHLBw=.a9871b5c-c36c-433b-8091-8f0648669836@github.com>
References: <RqEj6H9uqBuW5LmTcU73gzQNAQnQLgUDWoqfaxIHLBw=.a9871b5c-c36c-433b-8091-8f0648669836@github.com>
Message-ID: <dt_Bv7iBfcp2OomskzVfJCd4eHLZs8-jJMqqUzC20Js=.59cda087-f5eb-4702-81b2-9ce93090510d@github.com>

On Fri, 11 Jul 2025 12:45:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The following is reported when building with the gcc static analyzer (-fanalyzer) :
> 
> 
> /jdk/src/java.base/unix/native/libjava/java_props_md.c:244:17: warning: leak of 'temp' [CWE-401] [-Wanalyzer-malloc-leak]
>   244 | return 0;
> 
> 
> Seems we have to free temp in an early return.

There is another instance a few lines below. See around where `free(encoding_variant);` happen.

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

PR Review: https://git.openjdk.org/jdk/pull/26264#pullrequestreview-3010216750

From rgiulietti at openjdk.org  Fri Jul 11 13:07:40 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 11 Jul 2025 13:07:40 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
In-Reply-To: <JyFXnnkzrbOSXSsVUmDwkKfm-F3UlWHRkWzOsl8CMko=.d8c23079-1ace-4df9-88b7-7628576570a7@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <JyFXnnkzrbOSXSsVUmDwkKfm-F3UlWHRkWzOsl8CMko=.d8c23079-1ace-4df9-88b7-7628576570a7@github.com>
Message-ID: <iU-k-9EJmUVSn-O45JHrHYQSE27TEpVH57GLafkgsxU=.0eaaaf5e-f25e-43fa-a37c-2b0b3a797349@github.com>

On Fri, 11 Jul 2025 08:19:43 GMT, Aleksey Shipilev <shade 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
>
> 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.

Right, "word tearing" and "non-atomic access" are different notions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26258#discussion_r2200683349

From liach at openjdk.org  Fri Jul 11 13:19:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Jul 2025 13:19:38 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
In-Reply-To: <iU-k-9EJmUVSn-O45JHrHYQSE27TEpVH57GLafkgsxU=.0eaaaf5e-f25e-43fa-a37c-2b0b3a797349@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <JyFXnnkzrbOSXSsVUmDwkKfm-F3UlWHRkWzOsl8CMko=.d8c23079-1ace-4df9-88b7-7628576570a7@github.com>
 <iU-k-9EJmUVSn-O45JHrHYQSE27TEpVH57GLafkgsxU=.0eaaaf5e-f25e-43fa-a37c-2b0b3a797349@github.com>
Message-ID: <hVTqb5aXoMwBwtQNThsYewFRlxPDra9KKemnebBLFR0=.4a2300de-8c0c-42c6-93aa-733c0d018757@github.com>

On Fri, 11 Jul 2025 13:05:09 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> 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.
>
> Right, "word tearing" and "non-atomic access" are different notions.

True, word tearing is racing a single memory location. Good that we discovered another spec bug and could fix it in time for 25.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26258#discussion_r2200726935

From duke at openjdk.org  Fri Jul 11 13:25:44 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 11 Jul 2025 13:25:44 GMT
Subject: RFR: 8077587: BigInteger Roots [v18]
In-Reply-To: <03GYPzx7uKkVYO4vE0C6sD0AFpuLqZqfYQmpuGLInbo=.314dcd3a-faf2-4ecf-b3a3-0df47a7b9ad2@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <EPMNChZccG151dVhM5NjfVkNaHxmkBQ7uClT2JzrjBY=.57de2188-2baa-4877-b20d-2a86a3d17053@github.com>
 <03GYPzx7uKkVYO4vE0C6sD0AFpuLqZqfYQmpuGLInbo=.314dcd3a-faf2-4ecf-b3a3-0df47a7b9ad2@github.com>
Message-ID: <KOK2ob1CHlODLzT99WpqHm736jqVTl7s1Qy5-_o0pi0=.065a8c53-71c2-4e54-86d5-71361cdd2595@github.com>

On Fri, 11 Jul 2025 12:38:56 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> On the other hand, the code contains about 80 lines just to find the initial estimate. To ensure that the code is readable and maintainable, it either needs to be documented better, possibly with math, or simplified so that the correctness becomes obvious even without comments. Performance is not the only dimension we care about in the JDK. Readability and maintainability are even more important in the long term.

At the end of the day, the method used to compute the initial estimate is "simply" the generalization of the one used to find the initial estimate of the square root, in the previous implementation of `MBI.sqrt()` now replaced by Zimmermann's algorithm, so it shouldn't be difficult to document the code, in order to prove its correctness.

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

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3062325992

From rgiulietti at openjdk.org  Fri Jul 11 13:25:45 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 11 Jul 2025 13:25:45 GMT
Subject: RFR: 8077587: BigInteger Roots [v18]
In-Reply-To: <EPMNChZccG151dVhM5NjfVkNaHxmkBQ7uClT2JzrjBY=.57de2188-2baa-4877-b20d-2a86a3d17053@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <EPMNChZccG151dVhM5NjfVkNaHxmkBQ7uClT2JzrjBY=.57de2188-2baa-4877-b20d-2a86a3d17053@github.com>
Message-ID: <j9khPQDquKyOaomJCtVFlydnEctz3Taek1Iob7tTBJ4=.9d956e50-0ff2-4751-a734-969b1057d207@github.com>

On Fri, 6 Jun 2025 08:08:09 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update "since" version

Right.

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

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3062331717

From asotona at openjdk.org  Fri Jul 11 14:02:39 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 11 Jul 2025 14:02:39 GMT
Subject: [jdk25] RFR: 8361615: CodeBuilder::parameterSlot throws
 undocumented IOOBE
In-Reply-To: <u9Rl9fu8sx5U4aG54h8rLseSdcwjfnxiuLVDf507WME=.6a57b760-ee9d-4767-8632-4f50201b2029@github.com>
References: <u9Rl9fu8sx5U4aG54h8rLseSdcwjfnxiuLVDf507WME=.6a57b760-ee9d-4767-8632-4f50201b2029@github.com>
Message-ID: <Vgs54YByM-7bTVfhkDeHOJ_3LQ3uM99aq3dzB3wspBI=.1793aed6-e36f-4381-bf78-9e8dc33eb683@github.com>

On Wed, 9 Jul 2025 19:33:38 GMT, Chen Liang <liach at openjdk.org> wrote:

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

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26226#pullrequestreview-3010448374

From asotona at openjdk.org  Fri Jul 11 14:06:40 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 11 Jul 2025 14:06:40 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
In-Reply-To: <GmDnpyc6viSAmg523u-dhD1U4_Wfp5w2mYFqPI7Vel0=.cfc3cbe1-9944-4dd0-beec-3ce95d6bc026@github.com>
References: <GmDnpyc6viSAmg523u-dhD1U4_Wfp5w2mYFqPI7Vel0=.cfc3cbe1-9944-4dd0-beec-3ce95d6bc026@github.com>
Message-ID: <1Ww1KelK6SkfDi3nOCfziIZcwsaxD_Qgi4q0tUapLL0=.78496053-1724-4e16-be20-94a79a479c93@github.com>

On Wed, 9 Jul 2025 21:14:17 GMT, Chen Liang <liach at openjdk.org> wrote:

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

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 628:

> 626:             @Override
> 627:             public int compare(SwitchCase c1, SwitchCase c2) {
> 628:                 return Integer.compare(c1.caseValue(), c2.caseValue());

isn this an implicit null check?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26229#discussion_r2200827480

From asotona at openjdk.org  Fri Jul 11 14:16:45 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 11 Jul 2025 14:16:45 GMT
Subject: RFR: 8361908: Mix and match of dead and valid exception handler
 leads to malformed class file
In-Reply-To: <udEtYLdfL6agJTB3aTFfe7xdAhpBzdKEP_uWn-xalH8=.39d23c00-7a88-4d79-bb31-eb6ff8674fa9@github.com>
References: <udEtYLdfL6agJTB3aTFfe7xdAhpBzdKEP_uWn-xalH8=.39d23c00-7a88-4d79-bb31-eb6ff8674fa9@github.com>
Message-ID: <ZvyVyl757wBQzf7ahZRFTfjTz0O7bXQcW_OkKNm5aSA=.98f33511-3e0a-47e1-9db5-b938add54b75@github.com>

On Thu, 10 Jul 2025 21:47:35 GMT, Chen Liang <liach at openjdk.org> wrote:

> 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

Good catch!

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26255#pullrequestreview-3010497724

From asotona at openjdk.org  Fri Jul 11 14:18:43 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 11 Jul 2025 14:18:43 GMT
Subject: RFR: 8361909: ConstantPoolBuilder::loadableConstantEntry and
 constantValueEntry should throw NPE
In-Reply-To: <jQUgadsvemj8_Wu1vIidHAde3v3llybuTr6vxdneP-4=.82b28b63-27e6-46c2-8f62-c0aaf85b3c02@github.com>
References: <jQUgadsvemj8_Wu1vIidHAde3v3llybuTr6vxdneP-4=.82b28b63-27e6-46c2-8f62-c0aaf85b3c02@github.com>
Message-ID: <-yDLZm0Km1QSRPn6bIN9a_jWXFINBgK0-lekp2OHRIw=.e7288635-64f9-444d-91ac-b74e299f62e3@github.com>

On Thu, 10 Jul 2025 22:32:45 GMT, Chen Liang <liach at openjdk.org> wrote:

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

Looks reasonable.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26257#pullrequestreview-3010505438

From liach at openjdk.org  Fri Jul 11 14:27:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Jul 2025 14:27:21 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v2]
In-Reply-To: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
Message-ID: <WdO97GtQnol71kQLxpz4t9aeLu3af-Fszt54gZqM77o=.f724db41-14e0-4bbe-9db4-b64b4ea08c0a@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`.
> 
> 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

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

  Correct term is atomic, not word tearing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26258/files
  - new: https://git.openjdk.org/jdk/pull/26258/files/142c5855..1550fcc0

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

  Stats: 3 lines in 2 files changed: 0 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 liach at openjdk.org  Fri Jul 11 14:27:39 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Jul 2025 14:27:39 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
In-Reply-To: <1Ww1KelK6SkfDi3nOCfziIZcwsaxD_Qgi4q0tUapLL0=.78496053-1724-4e16-be20-94a79a479c93@github.com>
References: <GmDnpyc6viSAmg523u-dhD1U4_Wfp5w2mYFqPI7Vel0=.cfc3cbe1-9944-4dd0-beec-3ce95d6bc026@github.com>
 <1Ww1KelK6SkfDi3nOCfziIZcwsaxD_Qgi4q0tUapLL0=.78496053-1724-4e16-be20-94a79a479c93@github.com>
Message-ID: <n7qzHXJKDEfGXE54aq72iE5Q04tzZFuGvexOB9jJUJ4=.f3b4cbd0-4350-44b5-987d-f06ad33bd425@github.com>

On Fri, 11 Jul 2025 14:03:44 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> 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.
>
> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 628:
> 
>> 626:             @Override
>> 627:             public int compare(SwitchCase c1, SwitchCase c2) {
>> 628:                 return Integer.compare(c1.caseValue(), c2.caseValue());
> 
> isn this an implicit null check?

Yes, but this doesn't run when the list has just one element of `null` - see case https://github.com/openjdk/jdk/pull/26229/files#diff-cb987200ae23ff7522bd692d4707a012b115bf778a1265ba11db0b3bf5c9aa7cR98

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26229#discussion_r2200872686

From liach at openjdk.org  Fri Jul 11 14:30:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Jul 2025 14:30:48 GMT
Subject: RFR: 8361635: Missing List length validation in the Class-File API
In-Reply-To: <YqhNILbevQ2LlcvsLTnXgduP17cXTHdxToS6tbGlwSE=.e092145a-c661-473c-9be1-ffb523de06fc@github.com>
References: <YqhNILbevQ2LlcvsLTnXgduP17cXTHdxToS6tbGlwSE=.e092145a-c661-473c-9be1-ffb523de06fc@github.com>
Message-ID: <hLJjZm4jt9Tfv0-NJDHjAbY29gVOx5nNBL_nadvNhBA=.95ba51e6-b2f6-4e4e-b664-9116d53ee394@github.com>

On Thu, 10 Jul 2025 21:01:18 GMT, Chen Liang <liach at openjdk.org> wrote:

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

src/java.base/share/classes/java/lang/classfile/attribute/ModuleAttribute.java line 174:

> 172:      * @param provides the provided services
> 173:      * @throws IllegalArgumentException if {@code moduleFlags} is not in the
> 174:      * range {@code [0, 65535]}, or any of the collections have more than

Should I say `any of the {@code Collection} arguments` instead? The uses, services, provides, etc. are passed as `Collection` to this factory.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26252#discussion_r2200874824

From asotona at openjdk.org  Fri Jul 11 14:30:48 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 11 Jul 2025 14:30:48 GMT
Subject: RFR: 8361635: Missing List length validation in the Class-File API
In-Reply-To: <hLJjZm4jt9Tfv0-NJDHjAbY29gVOx5nNBL_nadvNhBA=.95ba51e6-b2f6-4e4e-b664-9116d53ee394@github.com>
References: <YqhNILbevQ2LlcvsLTnXgduP17cXTHdxToS6tbGlwSE=.e092145a-c661-473c-9be1-ffb523de06fc@github.com>
 <hLJjZm4jt9Tfv0-NJDHjAbY29gVOx5nNBL_nadvNhBA=.95ba51e6-b2f6-4e4e-b664-9116d53ee394@github.com>
Message-ID: <SUs8uwT039hYMQ716D1c0M_Hx_Y9MHTYUVdBPogJKPA=.203541a7-9abd-47e4-ab7b-5b16e10e6d90@github.com>

On Fri, 11 Jul 2025 14:25:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 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.
>
> src/java.base/share/classes/java/lang/classfile/attribute/ModuleAttribute.java line 174:
> 
>> 172:      * @param provides the provided services
>> 173:      * @throws IllegalArgumentException if {@code moduleFlags} is not in the
>> 174:      * range {@code [0, 65535]}, or any of the collections have more than
> 
> Should I say `any of the {@code Collection} arguments` instead? The uses, services, provides, etc. are passed as `Collection` to this factory.

I'm sorry, I take it back. It is OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26252#discussion_r2200879729

From liach at openjdk.org  Fri Jul 11 14:38:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Jul 2025 14:38:45 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v2]
In-Reply-To: <hVTqb5aXoMwBwtQNThsYewFRlxPDra9KKemnebBLFR0=.4a2300de-8c0c-42c6-93aa-733c0d018757@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <JyFXnnkzrbOSXSsVUmDwkKfm-F3UlWHRkWzOsl8CMko=.d8c23079-1ace-4df9-88b7-7628576570a7@github.com>
 <iU-k-9EJmUVSn-O45JHrHYQSE27TEpVH57GLafkgsxU=.0eaaaf5e-f25e-43fa-a37c-2b0b3a797349@github.com>
 <hVTqb5aXoMwBwtQNThsYewFRlxPDra9KKemnebBLFR0=.4a2300de-8c0c-42c6-93aa-733c0d018757@github.com>
Message-ID: <qF7Fuo1Cqd9yem8yCjLPZ1Q9YQpK9xJmf8MO1tnz3O4=.84a0fef2-aca7-4d27-9aa5-2038be5f9163@github.com>

On Fri, 11 Jul 2025 13:17:04 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Right, "word tearing" and "non-atomic access" are different notions.
>
> True, word tearing is racing a single memory location. Good that we discovered another spec bug and could fix it in time for 25.

I have changed to use the correct term "atomic". Let me know how this revision looks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26258#discussion_r2200897313

From asotona at openjdk.org  Fri Jul 11 14:40:43 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 11 Jul 2025 14:40:43 GMT
Subject: RFR: 8361635: Missing List length validation in the Class-File API
In-Reply-To: <YqhNILbevQ2LlcvsLTnXgduP17cXTHdxToS6tbGlwSE=.e092145a-c661-473c-9be1-ffb523de06fc@github.com>
References: <YqhNILbevQ2LlcvsLTnXgduP17cXTHdxToS6tbGlwSE=.e092145a-c661-473c-9be1-ffb523de06fc@github.com>
Message-ID: <ODBUcr0NHegSSB8Caz1R-lxh05JEF7wKqvz0ja_ue_A=.0403a8ac-a498-4b10-85a6-1a380ee7bfbb@github.com>

On Thu, 10 Jul 2025 21:01:18 GMT, Chen Liang <liach at openjdk.org> wrote:

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

Great job for mitigating accidental building of invalid class files!

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26252#pullrequestreview-3010572554

From duke at openjdk.org  Fri Jul 11 14:41:30 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 11 Jul 2025 14:41:30 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v7]
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: <C3aAwHxenLIEswZqQg-pjqjWQWbyTHD-5yvAIpbTCUU=.4a1620c8-b794-427c-ba39-1c0133174847@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:

  Linting of a few minor issues (nothing serious).
  
  * Linting of minor issues.
  * Factored out the module existence test, it's only a performance heuristic and could (should?) be removed.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26054/files
  - new: https://git.openjdk.org/jdk/pull/26054/files/43303574..bb9972de

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

  Stats: 44 lines in 3 files changed: 19 ins; 5 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  Fri Jul 11 14:41:59 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 11 Jul 2025 14:41:59 GMT
Subject: RFR: 8077587: BigInteger Roots [v19]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <9WIG9Xg3N1u9AX2INgNePq6diBEbDWCoLpB33PMB4RE=.1db482b8-f1f4-4734-a7d3-74dde97773f1@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

  Optimize the computation of the input's shift
  
  Optimize the computation of the input's shift, in order to avoid having more non-significant bits than necessary in the initial estimate.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/788a82b9..6dcd6792

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=17-18

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

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

From chris.w.dennis at gmail.com  Fri Jul 11 14:42:54 2025
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Fri, 11 Jul 2025 10:42:54 -0400
Subject: ClassLoader Leak via Executors.newSingleThreadExecutor(...)
Message-ID: <CAM1ck5hB3ym3dt8wAp3uQer5W=9=uboU6azgkCtMJji9ovnBBg@mail.gmail.com>

Hi All,

I believe I've identified a bug in
Executors.AutoShutdownDelegatedExecutorService that can trigger a
classloader leak even in the presence of "correct" Executor lifecycling.
AutoShutdownDelegatedExecutorService only unlinks the PhantomReference used
for cleanup handling when it is shutdown via the shutdown() method. If an
Executor wrapped in this way is instead shutdown using the shutdownNow()
method and it references a classloader via an injected attribute:
ThreadFactory, AbortPolicy, etc. then the cleanup action will reference the
classloader, and the classloader will remain strongly referenced. Adding an
additional override as shown in the attached patch is sufficient to fix the
leak in my testing.

Thanks,

Chris

P.S. I believe I'm likely covered wrt OCA via my employer IBM.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250711/2049d68e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: executor-classloader-leak.patch
Type: application/octet-stream
Size: 724 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250711/2049d68e/executor-classloader-leak-0001.patch>

From asotona at openjdk.org  Fri Jul 11 14:43:43 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 11 Jul 2025 14:43:43 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
In-Reply-To: <GmDnpyc6viSAmg523u-dhD1U4_Wfp5w2mYFqPI7Vel0=.cfc3cbe1-9944-4dd0-beec-3ce95d6bc026@github.com>
References: <GmDnpyc6viSAmg523u-dhD1U4_Wfp5w2mYFqPI7Vel0=.cfc3cbe1-9944-4dd0-beec-3ce95d6bc026@github.com>
Message-ID: <QfmtwE1Kle-yT87KGeLMYjaLNF1hqyKfWYcLoeYzCOw=.53761698-f25f-40dc-addf-144f8969f374@github.com>

On Wed, 9 Jul 2025 21:14:17 GMT, Chen Liang <liach at openjdk.org> wrote:

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

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26229#pullrequestreview-3010583452

From nbenalla at openjdk.org  Fri Jul 11 15:31:53 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 11 Jul 2025 15:31:53 GMT
Subject: RFR: 8358627:
 tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 26
 [v2]
In-Reply-To: <mcPF1ypiHlYI3H4kgl0bwvU3KF_YO40Yo6aY6w1LX4c=.4376bebf-3397-4354-be3e-9fd0719b24db@github.com>
References: <mcPF1ypiHlYI3H4kgl0bwvU3KF_YO40Yo6aY6w1LX4c=.4376bebf-3397-4354-be3e-9fd0719b24db@github.com>
Message-ID: <rvwv_NqO4F8KFEwbbh_IvQ7MvPV91hNMuNj8x9yzdM0=.08774f0c-9d45-4800-9464-eb823111325c@github.com>

> Once https://bugs.openjdk.org/browse/JDK-8358769 is resolved, JavaBaseCheckSince no longer needs to be problemlisted.

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

 - Merge branch 'master' into problemlisted-sincecheck-test
   
   # Conflicts:
   #	test/jdk/ProblemList.txt
 - this test no longer needs to be problem listed

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

Changes: https://git.openjdk.org/jdk/pull/25855/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25855&range=01
  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25855.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25855/head:pull/25855

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

From bpb at openjdk.org  Fri Jul 11 15:36:40 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 11 Jul 2025 15:36:40 GMT
Subject: RFR: 8361587: AssertionError in File.listFiles() when path is
 empty and -esa is enabled [v5]
In-Reply-To: <omhJ4IRKTVIbbj1YXXysc5t5QV2VWZ5d6ZJhOWFYAeE=.30c25ad9-0d0c-4046-a125-ea0559f9e85b@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <uM6Bmm5rwcMo6PdyeZJudSBZ4eIUTpfiEsGcmBBMWYA=.21d11e7e-9b04-42ec-9381-dbed0d763a52@github.com>
 <omhJ4IRKTVIbbj1YXXysc5t5QV2VWZ5d6ZJhOWFYAeE=.30c25ad9-0d0c-4046-a125-ea0559f9e85b@github.com>
Message-ID: <xm3Bb65HoUf-pdJPtjm39wZ85Pq-LqE_XfQCmldO5r0=.3eb3ead7-fcfc-48ca-a501-3de20671cc14@github.com>

On Fri, 11 Jul 2025 07:24:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> [...] look to special casing the empty parent in the listFiles methods [...].

Will investigate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26224#discussion_r2201046992

From liach at openjdk.org  Fri Jul 11 15:39:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Jul 2025 15:39:41 GMT
Subject: RFR: 8358627:
 tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 26
 [v2]
In-Reply-To: <rvwv_NqO4F8KFEwbbh_IvQ7MvPV91hNMuNj8x9yzdM0=.08774f0c-9d45-4800-9464-eb823111325c@github.com>
References: <mcPF1ypiHlYI3H4kgl0bwvU3KF_YO40Yo6aY6w1LX4c=.4376bebf-3397-4354-be3e-9fd0719b24db@github.com>
 <rvwv_NqO4F8KFEwbbh_IvQ7MvPV91hNMuNj8x9yzdM0=.08774f0c-9d45-4800-9464-eb823111325c@github.com>
Message-ID: <YelOAps_FyDH9jIozHTMtfnBKwRmvULoWZFQaNSdymQ=.4bb9b423-ffcf-4ba1-a968-bd8f2ccab4dc@github.com>

On Fri, 11 Jul 2025 15:31:53 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.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into problemlisted-sincecheck-test
>    
>    # Conflicts:
>    #	test/jdk/ProblemList.txt
>  - this test no longer needs to be problem listed

lgtm

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25855#pullrequestreview-3010813860

From igraves at openjdk.org  Fri Jul 11 16:15:40 2025
From: igraves at openjdk.org (Ian Graves)
Date: Fri, 11 Jul 2025 16:15:40 GMT
Subject: RFR: 8358768: [vectorapi] Make VectorOperators.SUADD an
 Associative [v2]
In-Reply-To: <p1IgQSvH5cYmNbBfoOBkJBDBPWDZ11OSp4lsUDAGzTM=.0815a03f-50f5-4dec-a0cc-ff879977a700@github.com>
References: <EZ4_14iY5_yTqfv3ZYpfoVRQK4jjxPtpafox1FQjq5M=.046cbb01-5fe5-4cf9-a468-ed22f0b4acda@github.com>
 <qiamVCoEtua2wUct97zOCtoCY0ICCUkNXIjiwK0uwTY=.8f4fcdce-a569-4d0f-b364-bd9ff642ffee@github.com>
 <p1IgQSvH5cYmNbBfoOBkJBDBPWDZ11OSp4lsUDAGzTM=.0815a03f-50f5-4dec-a0cc-ff879977a700@github.com>
Message-ID: <CZkNmpN7wlGQlDzcbQg2u9coAT-vpFWKS8msIUIJiR8=.9791fce2-21d3-471c-be50-4c8bd4d1a28e@github.com>

On Fri, 11 Jul 2025 03:45:14 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> 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);

Ordinarily I'd agree, but I'm going to keep with the established pattern in this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26099#discussion_r2201155129

From shade at openjdk.org  Fri Jul 11 16:32:40 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 16:32:40 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v2]
In-Reply-To: <WdO97GtQnol71kQLxpz4t9aeLu3af-Fszt54gZqM77o=.f724db41-14e0-4bbe-9db4-b64b4ea08c0a@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <WdO97GtQnol71kQLxpz4t9aeLu3af-Fszt54gZqM77o=.f724db41-14e0-4bbe-9db4-b64b4ea08c0a@github.com>
Message-ID: <rN1lpmapXIppR2KGEhtBtgS7sTWMjo037leZwKLRISw=.924520fa-a414-466b-90b5-a940e9edb5bf@github.com>

On Fri, 11 Jul 2025 14:27:21 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
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct term is atomic, not word tearing

I think it looks okay. But I am not spec expert, you need someone else to look at this carefully.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26258#pullrequestreview-3011038416

From almatvee at openjdk.org  Fri Jul 11 16:44:05 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 11 Jul 2025 16:44:05 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v4]
In-Reply-To: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
Message-ID: <2yrhjotF9K5jqUS7jYObkTxgvNmP7-fKlfitnJt7F4I=.0597991e-7474-400e-9d84-7f65424d47c8@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 [v3]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26173/files
  - new: https://git.openjdk.org/jdk/pull/26173/files/4b2a8d94..5ace4034

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

  Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 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  Fri Jul 11 16:44:06 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 11 Jul 2025 16:44:06 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: <IwEKa8xfEzOLKnKCQ9owzkNVcB-J0w2l9a2lEs75ua4=.a23447e0-c235-4598-9bbd-f31c4b236d0a@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 [v3]
- Fixed null pointer exception.

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

PR Comment: https://git.openjdk.org/jdk/pull/26173#issuecomment-3062982907

From rgiulietti at openjdk.org  Fri Jul 11 16:48:39 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 11 Jul 2025 16:48:39 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v2]
In-Reply-To: <WdO97GtQnol71kQLxpz4t9aeLu3af-Fszt54gZqM77o=.f724db41-14e0-4bbe-9db4-b64b4ea08c0a@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <WdO97GtQnol71kQLxpz4t9aeLu3af-Fszt54gZqM77o=.f724db41-14e0-4bbe-9db4-b64b4ea08c0a@github.com>
Message-ID: <lDWFsUlSbQ1pbDtLVu9zFb4BsLetRdviF54aFNSLp_c=.6336ae20-8fb4-441c-ac9b-d216934c088c@github.com>

On Fri, 11 Jul 2025 14:27:21 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
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct term is atomic, not word tearing

Marked as reviewed by rgiulietti (Reviewer).

To be super-pedantic, JLS 17.7 does _not_ guarantee atomic access of `long`s and `double`s, not even on 64-bit platforms. It only encourages implementations to do so if possible.
But I think we can safely assume that quality 64-bit implementations will indeed provide atomic access of `long`s and `double`s.

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

PR Review: https://git.openjdk.org/jdk/pull/26258#pullrequestreview-3011123166
PR Comment: https://git.openjdk.org/jdk/pull/26258#issuecomment-3062999765

From iris at openjdk.org  Fri Jul 11 17:42:38 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 11 Jul 2025 17:42:38 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <hNvkWs8N0batlQY3XmA-hnwS_Z6Tc5DFIAusJSOoaDI=.0b5f04b6-643a-4c59-babb-f313b362f4ca@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3011356650

From psandoz at openjdk.org  Fri Jul 11 17:47:40 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 11 Jul 2025 17:47:40 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v2]
In-Reply-To: <WdO97GtQnol71kQLxpz4t9aeLu3af-Fszt54gZqM77o=.f724db41-14e0-4bbe-9db4-b64b4ea08c0a@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <WdO97GtQnol71kQLxpz4t9aeLu3af-Fszt54gZqM77o=.f724db41-14e0-4bbe-9db4-b64b4ea08c0a@github.com>
Message-ID: <MoHbMObMoQy5VqkAjiy8dQJy3fX1rmleXdg9KJFos3A=.f6935efb-2390-4a3d-992e-df882b755c9e@github.com>

On Fri, 11 Jul 2025 14:27:21 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
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct term is atomic, not word tearing

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 281:

> 279:  * <li>read write access modes for all {@code T}. On 32-bit platforms, access modes
> 280:  *     {@code get} and {@code set} for {@code long}, {@code double} and {@code MemorySegment}
> 281:  *     are supported but not atomic, as described in Section {@jls 17.7}

Pedantically it is "... but are not guaranteed to be atomic, ...", since IIUC some 32-bit CPU architectures support 64-bit loads and stores (e.g., the ARM A32 LDREXD instruction) so the JVM can do something stronger than what is prescribed by the JMM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26258#discussion_r2201432837

From joehw at openjdk.org  Fri Jul 11 17:52:39 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 11 Jul 2025 17:52:39 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <0DTztUpAJe-j6cGqC33j6xyeTb1W_dFdaP65Z7f6NFk=.7bb3d63e-2a5a-4a95-93d2-9249285bcf70@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

test/jaxp/TEST.ROOT looks good.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3011378027

From hboehm at google.com  Fri Jul 11 18:00:06 2025
From: hboehm at google.com (Hans Boehm)
Date: Fri, 11 Jul 2025 11:00:06 -0700
Subject: RFR: 8077587: BigInteger Roots [v19]
In-Reply-To: <9WIG9Xg3N1u9AX2INgNePq6diBEbDWCoLpB33PMB4RE=.1db482b8-f1f4-4734-a7d3-74dde97773f1@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <9WIG9Xg3N1u9AX2INgNePq6diBEbDWCoLpB33PMB4RE=.1db482b8-f1f4-4734-a7d3-74dde97773f1@github.com>
Message-ID: <CAMOCf+jXAw9BjKVtOcqrvZfr_x7DTLMq12J2Q=rsmYBeTYj7Ew@mail.gmail.com>

Apologies if this has been discussed before.

The explanation for the exception for negative n ("This would cause
the operation to yield a non-integer value.") feels wrong to me. I think
the definition of the result as: x.signum() * floor(abs(nthRoot(x, n)))
works fine for that case, if nthRoot(x,-n) is 1/(nthRoot(x,n)) as expected,
right? And the main definition of the result just isn't well-defined.
Neither yields a non-integer.

AFAICT, the two options here are:

1) Just produce the, usually zero, result, usually with a remainder of
`this`. (If 'this' is zero, you would still need an arithmetic exception,
and +-1 is also interesting.)

2) Produce an ArithmeticException with a justification along the lines of
"The result would not be meaningful."

Based on the Wikipedia page, negative n aren't normally a thing, so (2)
seems justifiable. But I think the current justification for the exception
is not.

I can't think of a good reason to prefer (1), but we've all been bitten by
unnecessary domain restrictions, so I'm not positive about that.

Hans

On Fri, Jul 11, 2025 at 7:42?AM fabioromano1 <duke at openjdk.org> wrote:

> > This PR implements nth root computation for BigIntegers using Newton
> method.
>
> fabioromano1 has updated the pull request incrementally with one
> additional commit since the last revision:
>
>   Optimize the computation of the input's shift
>
>   Optimize the computation of the input's shift, in order to avoid having
> more non-significant bits than necessary in the initial estimate.
>
> -------------
>
> Changes:
>   - all: https://git.openjdk.org/jdk/pull/24898/files
>   - new: https://git.openjdk.org/jdk/pull/24898/files/788a82b9..6dcd6792
>
> Webrevs:
>  - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=18
>  - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=17-18
>
>   Stats: 18 lines in 1 file changed: 8 ins; 0 del; 10 mod
>   Patch: https://git.openjdk.org/jdk/pull/24898.diff
>   Fetch: git fetch https://git.openjdk.org/jdk.git
> pull/24898/head:pull/24898
>
> PR: https://git.openjdk.org/jdk/pull/24898
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250711/2d332945/attachment.htm>

From duke at openjdk.org  Fri Jul 11 18:07:31 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 11 Jul 2025 18:07:31 GMT
Subject: RFR: 8077587: BigInteger Roots [v20]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <Knp7tAtQgjRMMbZAdATtAwFMrzE95gvcC7U2JDLxRq4=.5cc96bff-fd18-4957-bd80-3fb01907c551@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

  Avoid to discard fraction bits in the initial estimate

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/6dcd6792..8fabf141

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=18-19

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

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

From duke at openjdk.org  Fri Jul 11 18:43:41 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 11 Jul 2025 18:43:41 GMT
Subject: RFR: 8077587: BigInteger Roots [v20]
In-Reply-To: <Knp7tAtQgjRMMbZAdATtAwFMrzE95gvcC7U2JDLxRq4=.5cc96bff-fd18-4957-bd80-3fb01907c551@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <Knp7tAtQgjRMMbZAdATtAwFMrzE95gvcC7U2JDLxRq4=.5cc96bff-fd18-4957-bd80-3fb01907c551@github.com>
Message-ID: <ioYsgn0VBRtf0NDboh5rpHRZ_RmWAf7rfVcYoKhFa0A=.3a007def-02ef-4da7-b20c-45346e7950d0@github.com>

On Fri, 11 Jul 2025 18:07:31 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid to discard fraction bits in the initial estimate

The current explanation for the exception of negative `n` is justified by consistency with the explanation for negative `exponent` in `BigInteger.pow(int)`, so changing this explanation would cause an inconsistency in the documentation of `BigInteger` operations.

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

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3063352781

From naoto at openjdk.org  Fri Jul 11 18:54:47 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 11 Jul 2025 18:54:47 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal
Message-ID: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>

In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.

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

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/26273/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26273&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361613
  Stats: 565 lines in 12 files changed: 221 ins; 237 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/26273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26273/head:pull/26273

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

From liach at openjdk.org  Fri Jul 11 19:02:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Jul 2025 19:02:31 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v3]
In-Reply-To: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
Message-ID: <tCyx-XkttQoAnJcEOtC8SITb9NaurEROV_OjT-E3Imc=.320d74bc-5aa1-4d8a-9867-c767dea379c5@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`.
> 
> 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

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

  "may be non-atomic"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26258/files
  - new: https://git.openjdk.org/jdk/pull/26258/files/1550fcc0..7563e6b7

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

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 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 liach at openjdk.org  Fri Jul 11 19:02:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Jul 2025 19:02:31 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v2]
In-Reply-To: <WdO97GtQnol71kQLxpz4t9aeLu3af-Fszt54gZqM77o=.f724db41-14e0-4bbe-9db4-b64b4ea08c0a@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <WdO97GtQnol71kQLxpz4t9aeLu3af-Fszt54gZqM77o=.f724db41-14e0-4bbe-9db4-b64b4ea08c0a@github.com>
Message-ID: <Y2c_5sqaUIc6wsaW_KiE8iaaTbgYf96K92uV4yVkEWY=.754329b4-73f0-4d39-9221-8f97d3f44fc5@github.com>

On Fri, 11 Jul 2025 14:27:21 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
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct term is atomic, not word tearing

You are right. I should use "may be non-atomic", as the implementation can make these operations atomic.

Also re JLS 17.7 for 64-bit platforms: this phrase is qualified to be on 32-bit platforms, and we are already under aligned access, so I assume we have sufficient preconditions to ignore this aspect.

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

PR Comment: https://git.openjdk.org/jdk/pull/26258#issuecomment-3063397506

From liach at openjdk.org  Fri Jul 11 19:02:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Jul 2025 19:02:31 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v2]
In-Reply-To: <MoHbMObMoQy5VqkAjiy8dQJy3fX1rmleXdg9KJFos3A=.f6935efb-2390-4a3d-992e-df882b755c9e@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <WdO97GtQnol71kQLxpz4t9aeLu3af-Fszt54gZqM77o=.f724db41-14e0-4bbe-9db4-b64b4ea08c0a@github.com>
 <MoHbMObMoQy5VqkAjiy8dQJy3fX1rmleXdg9KJFos3A=.f6935efb-2390-4a3d-992e-df882b755c9e@github.com>
Message-ID: <tBWoJ6boLwijvCPBhRKq_Bjq13-QOf1x2mgaOmTBT4I=.bad3e39d-f349-412b-bda3-76413a0c7b05@github.com>

On Fri, 11 Jul 2025 17:45:01 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct term is atomic, not word tearing
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 281:
> 
>> 279:  * <li>read write access modes for all {@code T}. On 32-bit platforms, access modes
>> 280:  *     {@code get} and {@code set} for {@code long}, {@code double} and {@code MemorySegment}
>> 281:  *     are supported but not atomic, as described in Section {@jls 17.7}
> 
> Pedantically it is "... but are not guaranteed to be atomic, ...", since IIUC some 32-bit CPU architectures support 64-bit loads and stores (e.g., the ARM A32 LDREXD instruction) so the JVM can do something stronger than what is prescribed by the JMM.

Thanks, updated to be "but may be non-atomic". Please review the CSR as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26258#discussion_r2201559182

From psandoz at openjdk.org  Fri Jul 11 19:17:38 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 11 Jul 2025 19:17:38 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v3]
In-Reply-To: <tCyx-XkttQoAnJcEOtC8SITb9NaurEROV_OjT-E3Imc=.320d74bc-5aa1-4d8a-9867-c767dea379c5@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <tCyx-XkttQoAnJcEOtC8SITb9NaurEROV_OjT-E3Imc=.320d74bc-5aa1-4d8a-9867-c767dea379c5@github.com>
Message-ID: <rTx08DUXOs6d1JFH_kFr8-6iEmiA3TkJjMmHfHwCU0Y=.c35e029d-f38b-40c2-87d9-515e70c9f9ab@github.com>

On Fri, 11 Jul 2025 19:02:31 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
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   "may be non-atomic"

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26258#pullrequestreview-3011629319

From duke at openjdk.org  Fri Jul 11 19:35:20 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 11 Jul 2025 19:35:20 GMT
Subject: RFR: 8077587: BigInteger Roots [v21]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <cXNnzUCdmWkjsabS7YpGmhcEFUP2SCsdlPkqk-nDTmA=.006e2a57-2183-4d3d-bcc2-49767938ce2b@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

  small change for readability

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/8fabf141..aa1a9bec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=19-20

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

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

From almatvee at openjdk.org  Fri Jul 11 20:02:15 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 11 Jul 2025 20:02:15 GMT
Subject: RFR: 8361224: [macos] MacSignTest.testMultipleCertificates failed
Message-ID: <pRWD7kOwWcum4js1s1d48Jx2fhh8bvmd1w9OP0nAvFo=.bce26615-91df-42bb-b8b9-1f17d5ff68c0@github.com>

Test updated to expect `jpackage` to PASS in case of `--mac-signing-key-user-name` and FAIL in case of `-mac-app-image-sign-identity`. See explanation below.

Case 1: Only common name of certificate is used (PASS):
jpackage --type dmg -i input -n Test --main-class components.DynamicTreeDemo --main-jar DynamicTreeDemo.jar --mac-sign --mac-signing-keychain jpackagerTest-duplicate.keychain --mac-signing-key-user-name jpackage.openjdk.java.net
[10:02:37.545] WARNING: Multiple certificates found matching [Developer ID Application: jpackage.openjdk.java.net] using keychain [jpackagerTest-duplicate.keychain], using first one

Actual codesign command in PASS case:
/usr/bin/codesign -s CBDE500D7ED18E08F6DF852A5D23D8C7113EB30C -vvvv --timestamp --options runtime --prefix components. --keychain jpackagerTest-duplicate.keychain --force /var/folders/dr/65dj5x3j0296mqtsn9z27xc80000gn/T/jdk.jpackage3439321874841533317/image/Test.app

CBDE500D7ED18E08F6DF852A5D23D8C7113EB30C is hash of certificate which exist in both jpackagerTest.keychain and jpackagerTest-duplicate.keychain. Based on man page documentation it is allowed. When hash is used codesign will not perform any search of certificates based on man page. So codesign will not fail which is expected.

Case 2: Full name of certificate is used (FAIL):
jpackage --type dmg -i input -n Test --main-class components.DynamicTreeDemo --main-jar DynamicTreeDemo.jar --mac-sign --mac-signing-keychain jpackagerTest-duplicate.keychain --mac-app-image-sign-identity "Developer ID Application: jpackage.openjdk.java.net"
Error: "codesign" failed with following output:
Developer ID Application: jpackage.openjdk.java.net: found in both /Users/alexander/Library/Keychains/jpackagerTest.keychain-db and /Users/alexander/Library/Keychains/jpackagerTest-duplicate.keychain-db (this is all right)
Developer ID Application: jpackage.openjdk.java.net: ambiguous (matches "Developer ID Application: jpackage.openjdk.java.net" in /Users/alexander/Library/Keychains/jpackagerTest.keychain-db and "Developer ID Application: jpackage.openjdk.java.net" in /Users/alexander/Library/Keychains/jpackagerTest-duplicate.keychain-db)

Actual codesign command in FAIL case:
/usr/bin/codesign -s Developer ID Application: jpackage.openjdk.java.net -vvvv --timestamp --options runtime --prefix components. --keychain jpackagerTest-duplicate.keychain /var/folders/dr/65dj5x3j0296mqtsn9z27xc80000gn/T/jdk.jpackage12899615926124631029/image/Test.app/Contents/runtime/Contents/Home/lib/libnet.dylib
[11:20:45.113] Output:
    Developer ID Application: jpackage.openjdk.java.net: found in both /Users/alexander/Library/Keychains/jpackagerTest.keychain-db and /Users/alexander/Library/Keychains/jpackagerTest-duplicate.keychain-db (this is all right)
    Developer ID Application: jpackage.openjdk.java.net: ambiguous (matches "Developer ID Application: jpackage.openjdk.java.net" in /Users/alexander/Library/Keychains/jpackagerTest.keychain-db and "Developer ID Application: jpackage.openjdk.java.net" in /Users/alexander/Library/Keychains/jpackagerTest-duplicate.keychain-db)

Full certificate name is being passed since --mac-app-image-sign-identity is used which is pass through. In this case codesign will perform search and finds duplicated certificate and fails, since it does not know which one to use. Based on man page it is expected.

Suggested fix:
Case when --mac-signing-key-user-name is used. jpackage should PASS, since jpackage performs certificate search and selects first one with warning by design.

Case when --mac-app-image-sign-identity is used. jpackage should FAIL, since codesign selects certificate based on --mac-app-image-sign-identity.

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

Commit messages:
 - 8361224: [macos] MacSignTest.testMultipleCertificates failed

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

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

From bpb at openjdk.org  Fri Jul 11 20:28:54 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 11 Jul 2025 20:28:54 GMT
Subject: RFR: 8361587: AssertionError in File.listFiles() when path is
 empty and -esa is enabled [v6]
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: <4tW-coWn6cxzVAfWkewpSMKuAFPDtm6YZh0prlLiov4=.f06df509-e153-4c07-888d-0d018a4c30ca@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: Address the error directly in listFiles
 - 8361587: Revert changes to File and UnixFileSyetem

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26224/files
  - new: https://git.openjdk.org/jdk/pull/26224/files/91867701..93e61dc1

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

  Stats: 11 lines in 2 files changed: 9 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 aturbanov at openjdk.org  Fri Jul 11 20:37:39 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 11 Jul 2025 20:37:39 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal
In-Reply-To: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
Message-ID: <sPGHxwyEZnTOcAJfWkoid69-mooCq49_icxd9D4Y-Fg=.1afba1fc-b8bb-4c68-b3fd-f25deab49660@github.com>

On Fri, 11 Jul 2025 18:46:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
> This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.

test/jdk/java/io/Console/LocaleTest.java line 52:

> 50:  */
> 51: public class LocaleTest {
> 52:     private static final Calendar TODAY  = new GregorianCalendar(2024, Calendar.APRIL, 22);

Suggestion:

    private static final Calendar TODAY = new GregorianCalendar(2024, Calendar.APRIL, 22);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2201798509

From asemenyuk at openjdk.org  Fri Jul 11 20:50:38 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 11 Jul 2025 20:50:38 GMT
Subject: RFR: 8361224: [macos] MacSignTest.testMultipleCertificates failed
In-Reply-To: <pRWD7kOwWcum4js1s1d48Jx2fhh8bvmd1w9OP0nAvFo=.bce26615-91df-42bb-b8b9-1f17d5ff68c0@github.com>
References: <pRWD7kOwWcum4js1s1d48Jx2fhh8bvmd1w9OP0nAvFo=.bce26615-91df-42bb-b8b9-1f17d5ff68c0@github.com>
Message-ID: <G1_8QR7fDS-d03yOe_qmC0V7UlRV4gqEYwmjzRsW_CU=.6729d96b-95ea-47ec-bc54-f4043f53c7fe@github.com>

On Fri, 11 Jul 2025 19:57:54 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Test updated to expect `jpackage` to PASS in case of `--mac-signing-key-user-name` and FAIL in case of `-mac-app-image-sign-identity`. See explanation below.
> 
> Case 1: Only common name of certificate is used (PASS):
> jpackage --type dmg -i input -n Test --main-class components.DynamicTreeDemo --main-jar DynamicTreeDemo.jar --mac-sign --mac-signing-keychain jpackagerTest-duplicate.keychain --mac-signing-key-user-name jpackage.openjdk.java.net
> [10:02:37.545] WARNING: Multiple certificates found matching [Developer ID Application: jpackage.openjdk.java.net] using keychain [jpackagerTest-duplicate.keychain], using first one
> 
> Actual codesign command in PASS case:
> /usr/bin/codesign -s CBDE500D7ED18E08F6DF852A5D23D8C7113EB30C -vvvv --timestamp --options runtime --prefix components. --keychain jpackagerTest-duplicate.keychain --force /var/folders/dr/65dj5x3j0296mqtsn9z27xc80000gn/T/jdk.jpackage3439321874841533317/image/Test.app
> 
> CBDE500D7ED18E08F6DF852A5D23D8C7113EB30C is hash of certificate which exist in both jpackagerTest.keychain and jpackagerTest-duplicate.keychain. Based on man page documentation it is allowed. When hash is used codesign will not perform any search of certificates based on man page. So codesign will not fail which is expected.
> 
> Case 2: Full name of certificate is used (FAIL):
> jpackage --type dmg -i input -n Test --main-class components.DynamicTreeDemo --main-jar DynamicTreeDemo.jar --mac-sign --mac-signing-keychain jpackagerTest-duplicate.keychain --mac-app-image-sign-identity "Developer ID Application: jpackage.openjdk.java.net"
> Error: "codesign" failed with following output:
> Developer ID Application: jpackage.openjdk.java.net: found in both /Users/alexander/Library/Keychains/jpackagerTest.keychain-db and /Users/alexander/Library/Keychains/jpackagerTest-duplicate.keychain-db (this is all right)
> Developer ID Application: jpackage.openjdk.java.net: ambiguous (matches "Developer ID Application: jpackage.openjdk.java.net" in /Users/alexander/Library/Keychains/jpackagerTest.keychain-db and "Developer ID Application: jpackage.openjdk.java.net" in /Users/alexander/Library/Keychains/jpackagerTest-duplicate.keychain-db)
> 
> Actual codesign command in FAIL case:
> /usr/bin/codesign -s Developer ID Application: jpackage.openjdk.java.net -vvvv --timestamp --options runtime --prefix components. --keychain jpackagerTest-duplicate.keychain /var/folders/dr/65dj5x3j0296mqtsn9z27xc80000gn/T/jdk.jpackage12899615926124631029/image/Test.app/Contents/runtime/Contents/H...

Marked as reviewed by asemenyuk (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26275#pullrequestreview-3011936856

From naoto at openjdk.org  Fri Jul 11 22:07:01 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 11 Jul 2025 22:07:01 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v2]
In-Reply-To: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
Message-ID: <iTEuOKSnDvEPDh3HxMsg6eRIFULYmgEETWwxlaw1xDg=.8ea80543-fba1-418c-88e3-43b183102b4c@github.com>

> In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
> This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.

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

  Update test/jdk/java/io/Console/LocaleTest.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26273/files
  - new: https://git.openjdk.org/jdk/pull/26273/files/ea72f445..82773085

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

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

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

From liach at openjdk.org  Fri Jul 11 22:54:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Jul 2025 22:54:43 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
In-Reply-To: <GmDnpyc6viSAmg523u-dhD1U4_Wfp5w2mYFqPI7Vel0=.cfc3cbe1-9944-4dd0-beec-3ce95d6bc026@github.com>
References: <GmDnpyc6viSAmg523u-dhD1U4_Wfp5w2mYFqPI7Vel0=.cfc3cbe1-9944-4dd0-beec-3ce95d6bc026@github.com>
Message-ID: <Sgwkp3zor5pkeampE-a-y1JAAtL7G2kv8YAMHe7n95M=.5c502e53-a8bf-4aa3-89b2-dbe0244e58d9@github.com>

On Wed, 9 Jul 2025 21:14:17 GMT, Chen Liang <liach at openjdk.org> wrote:

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

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26229#issuecomment-3064113053

From liach at openjdk.org  Fri Jul 11 22:54:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Jul 2025 22:54:43 GMT
Subject: Integrated: 8361102: java.lang.classfile.CodeBuilder.branch(Opcode op, 
 Label target) doesn't throw IllegalArgumentException - if op is not of
 Opcode.Kind.BRANCH
In-Reply-To: <GmDnpyc6viSAmg523u-dhD1U4_Wfp5w2mYFqPI7Vel0=.cfc3cbe1-9944-4dd0-beec-3ce95d6bc026@github.com>
References: <GmDnpyc6viSAmg523u-dhD1U4_Wfp5w2mYFqPI7Vel0=.cfc3cbe1-9944-4dd0-beec-3ce95d6bc026@github.com>
Message-ID: <piI5nzcsOlvtqX03sqloXOmA2qXqcxMRuJR5Ke92nqo=.7a857b83-9abe-47ed-b277-b0bf2f85426f@github.com>

On Wed, 9 Jul 2025 21:14:17 GMT, Chen Liang <liach at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 3f59eae3
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f59eae3d0e00b0aaedf16af48afc7f9fb86e0ed
Stats:     171 lines in 5 files changed: 120 ins; 27 del; 24 mod

8361102: java.lang.classfile.CodeBuilder.branch(Opcode op,  Label target) doesn't throw IllegalArgumentException - if op is not of Opcode.Kind.BRANCH

Reviewed-by: asotona

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

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

From liach at openjdk.org  Fri Jul 11 22:55:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Jul 2025 22:55:48 GMT
Subject: RFR: 8361908: Mix and match of dead and valid exception handler
 leads to malformed class file
In-Reply-To: <udEtYLdfL6agJTB3aTFfe7xdAhpBzdKEP_uWn-xalH8=.39d23c00-7a88-4d79-bb31-eb6ff8674fa9@github.com>
References: <udEtYLdfL6agJTB3aTFfe7xdAhpBzdKEP_uWn-xalH8=.39d23c00-7a88-4d79-bb31-eb6ff8674fa9@github.com>
Message-ID: <TWxmgmjnzbGTuKKl-QpdxLkQN0D3SbDt6y4vTNxqaq0=.b0b68a18-ab73-469f-aa32-8d8901cd80f0@github.com>

On Thu, 10 Jul 2025 21:47:35 GMT, Chen Liang <liach at openjdk.org> wrote:

> 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

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26255#issuecomment-3064113203

From liach at openjdk.org  Fri Jul 11 22:55:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Jul 2025 22:55:49 GMT
Subject: [jdk25] RFR: 8361615: CodeBuilder::parameterSlot throws
 undocumented IOOBE
In-Reply-To: <u9Rl9fu8sx5U4aG54h8rLseSdcwjfnxiuLVDf507WME=.6a57b760-ee9d-4767-8632-4f50201b2029@github.com>
References: <u9Rl9fu8sx5U4aG54h8rLseSdcwjfnxiuLVDf507WME=.6a57b760-ee9d-4767-8632-4f50201b2029@github.com>
Message-ID: <g3Fi0oCvBs2hCg1msTgQAUbDFTQSque1rnKvdebk_xY=.6192c562-b9cd-4884-9410-0c172bb6275a@github.com>

On Wed, 9 Jul 2025 19:33:38 GMT, Chen Liang <liach at openjdk.org> wrote:

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

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26226#issuecomment-3064112495

From liach at openjdk.org  Fri Jul 11 22:55:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Jul 2025 22:55:49 GMT
Subject: Integrated: 8361908: Mix and match of dead and valid exception handler
 leads to malformed class file
In-Reply-To: <udEtYLdfL6agJTB3aTFfe7xdAhpBzdKEP_uWn-xalH8=.39d23c00-7a88-4d79-bb31-eb6ff8674fa9@github.com>
References: <udEtYLdfL6agJTB3aTFfe7xdAhpBzdKEP_uWn-xalH8=.39d23c00-7a88-4d79-bb31-eb6ff8674fa9@github.com>
Message-ID: <4Hog_U8Cb7lJgNBIptxfa13s38Uu0WDGBs0TK2Tcnhc=.f3f9309b-0bfb-4c66-b137-cd677f95136b@github.com>

On Thu, 10 Jul 2025 21:47:35 GMT, Chen Liang <liach at openjdk.org> wrote:

> 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

This pull request has now been integrated.

Changeset: 189017f7
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/189017f750d54e7b53d0dd3a035e8c4e1cd5cab9
Stats:     22 lines in 2 files changed: 20 ins; 1 del; 1 mod

8361908: Mix and match of dead and valid exception handler leads to malformed class file

Reviewed-by: asotona

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

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

From liach at openjdk.org  Fri Jul 11 22:55:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Jul 2025 22:55:50 GMT
Subject: [jdk25] Integrated: 8361615: CodeBuilder::parameterSlot throws
 undocumented IOOBE
In-Reply-To: <u9Rl9fu8sx5U4aG54h8rLseSdcwjfnxiuLVDf507WME=.6a57b760-ee9d-4767-8632-4f50201b2029@github.com>
References: <u9Rl9fu8sx5U4aG54h8rLseSdcwjfnxiuLVDf507WME=.6a57b760-ee9d-4767-8632-4f50201b2029@github.com>
Message-ID: <XQeIrOPyVwLSTbXpdxLDZssF3n609WhxfmwOvaCCHzE=.c22e4418-7a73-4c59-9237-c6df6555179f@github.com>

On Wed, 9 Jul 2025 19:33:38 GMT, Chen Liang <liach at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: c374ac6d
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c374ac6df4b1ba830668e46c208d01fdf063bc23
Stats:     10 lines in 2 files changed: 9 ins; 0 del; 1 mod

8361615: CodeBuilder::parameterSlot throws undocumented IOOBE

Reviewed-by: asotona
Backport-of: c9bea77342672715f8f720d7311d66c2b3ac9f8a

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

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

From duke at openjdk.org  Fri Jul 11 23:03:50 2025
From: duke at openjdk.org (duke)
Date: Fri, 11 Jul 2025 23:03:50 GMT
Subject: Withdrawn: 8352044: Add --with-import-jvms to configure
In-Reply-To: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
Message-ID: <SYBbqtdJjQFvEsh7QM2IrbA6KBPAenCetQej7EUFKMA=.33b20e76-05cd-4b62-9551-cc93de75a9c2@github.com>

On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We should allow pre-built JVMs to be included in a build, so they are just copied into place, and the jvm.cfg file properly updated.

This pull request has been closed without being integrated.

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

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

From rgiulietti at openjdk.org  Fri Jul 11 23:08:53 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 11 Jul 2025 23:08:53 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v3]
In-Reply-To: <tCyx-XkttQoAnJcEOtC8SITb9NaurEROV_OjT-E3Imc=.320d74bc-5aa1-4d8a-9867-c767dea379c5@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <tCyx-XkttQoAnJcEOtC8SITb9NaurEROV_OjT-E3Imc=.320d74bc-5aa1-4d8a-9867-c767dea379c5@github.com>
Message-ID: <0SP6dFBJrWqZZE8jBNq_EJvisGgVvZ23dQ7GJJboUtM=.e0934303-2362-420d-a9f2-0348d0ec572c@github.com>

On Fri, 11 Jul 2025 19:02:31 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
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   "may be non-atomic"

Marked as reviewed by rgiulietti (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26258#pullrequestreview-3012237119

From bpb at openjdk.org  Sat Jul 12 04:25:31 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 12 Jul 2025 04:25:31 GMT
Subject: RFR: 8361587: AssertionError in File.listFiles() when path is
 empty and -esa is enabled [v7]
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: <FtGSJdjUsUTLJqyl5t_5HLA4-ZR-I5M5u7kHyh1cu_M=.9aa4f0e2-a7d0-4ba6-8212-5d04c4b8cb4b@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: Improve previous commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26224/files
  - new: https://git.openjdk.org/jdk/pull/26224/files/93e61dc1..b0555078

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

  Stats: 8 lines in 1 file changed: 0 ins; 2 del; 6 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 duke at openjdk.org  Sat Jul 12 09:12:32 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 12 Jul 2025 09:12:32 GMT
Subject: RFR: 8077587: BigInteger Roots [v22]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <BxY6EmIwL8fMNJP9vojHRegeCIYEoZvT7F2an4GthN0=.1207a22b-e780-4a8e-b3e3-15fc7b798834@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

  Code simplification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/aa1a9bec..fae8c99c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=20-21

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

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

From duke at openjdk.org  Sat Jul 12 09:18:27 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 12 Jul 2025 09:18:27 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

  Removed useless instruction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/fae8c99c..e2a3f402

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=21-22

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

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

From mbaesken at openjdk.org  Sat Jul 12 17:32:40 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Sat, 12 Jul 2025 17:32:40 GMT
Subject: RFR: 8361959: [GCC static analyzer] java_props_md.c  leak of
 'temp'  variable is reported
In-Reply-To: <dt_Bv7iBfcp2OomskzVfJCd4eHLZs8-jJMqqUzC20Js=.59cda087-f5eb-4702-81b2-9ce93090510d@github.com>
References: <RqEj6H9uqBuW5LmTcU73gzQNAQnQLgUDWoqfaxIHLBw=.a9871b5c-c36c-433b-8091-8f0648669836@github.com>
 <dt_Bv7iBfcp2OomskzVfJCd4eHLZs8-jJMqqUzC20Js=.59cda087-f5eb-4702-81b2-9ce93090510d@github.com>
Message-ID: <Q_Qh7GSC_tBOZtFo_epBrEsTLsGWE6fylMtAAStLYs8=.8bc7d936-5992-49e2-9603-bc22c079e4cd@github.com>

On Fri, 11 Jul 2025 13:04:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There is another instance a few lines below. See around where `free(encoding_variant);` happen.

Hi I noticed that one too !  Seems we have to adjust it too , I first thought that it is not needed there but it is. 
Not sure why the GCC analyzer reports only the first .
Unfortunately  one of the calls to ParseLocale does not even check the return value , so it is all a bit 'shaky' .

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

PR Comment: https://git.openjdk.org/jdk/pull/26264#issuecomment-3065896882

From mbaesken at openjdk.org  Sat Jul 12 17:36:54 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Sat, 12 Jul 2025 17:36:54 GMT
Subject: RFR: 8361959: [GCC static analyzer] java_props_md.c  leak of
 'temp'  variable is reported [v2]
In-Reply-To: <RqEj6H9uqBuW5LmTcU73gzQNAQnQLgUDWoqfaxIHLBw=.a9871b5c-c36c-433b-8091-8f0648669836@github.com>
References: <RqEj6H9uqBuW5LmTcU73gzQNAQnQLgUDWoqfaxIHLBw=.a9871b5c-c36c-433b-8091-8f0648669836@github.com>
Message-ID: <KnrbHzTaREYx4MM0mKtjtyprF7KPGv1fTRnyxFzttqQ=.e94cb087-cd46-434c-b3e6-256daf28c348@github.com>

> The following is reported when building with the gcc static analyzer (-fanalyzer) :
> 
> 
> /jdk/src/java.base/unix/native/libjava/java_props_md.c:244:17: warning: leak of 'temp' [CWE-401] [-Wanalyzer-malloc-leak]
>   244 | return 0;
> 
> 
> Seems we have to free temp in an early return.

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

  free before another early return

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26264/files
  - new: https://git.openjdk.org/jdk/pull/26264/files/f6ab84a9..d5735df9

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

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

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

From kbarrett at openjdk.org  Sat Jul 12 18:31:38 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 12 Jul 2025 18:31:38 GMT
Subject: RFR: 8361959: [GCC static analyzer] java_props_md.c  leak of
 'temp'  variable is reported [v2]
In-Reply-To: <KnrbHzTaREYx4MM0mKtjtyprF7KPGv1fTRnyxFzttqQ=.e94cb087-cd46-434c-b3e6-256daf28c348@github.com>
References: <RqEj6H9uqBuW5LmTcU73gzQNAQnQLgUDWoqfaxIHLBw=.a9871b5c-c36c-433b-8091-8f0648669836@github.com>
 <KnrbHzTaREYx4MM0mKtjtyprF7KPGv1fTRnyxFzttqQ=.e94cb087-cd46-434c-b3e6-256daf28c348@github.com>
Message-ID: <icW5i6b8vnFqBq-yE9XiEeIc-uDn6fBFsQYzRIvXScw=.991f1935-18a4-40be-98dc-2700e162a656@github.com>

On Sat, 12 Jul 2025 17:36:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The following is reported when building with the gcc static analyzer (-fanalyzer) :
>> 
>> 
>> /jdk/src/java.base/unix/native/libjava/java_props_md.c:244:17: warning: leak of 'temp' [CWE-401] [-Wanalyzer-malloc-leak]
>>   244 | return 0;
>> 
>> 
>> Seems we have to free temp in an early return.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   free before another early return

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26264#pullrequestreview-3013453183

From yujige at gmail.com  Sun Jul 13 03:54:18 2025
From: yujige at gmail.com (Jige Yu)
Date: Sat, 12 Jul 2025 20:54:18 -0700
Subject: [External] : Re: Question about mapConcurrent() Behavior and
 Happens-Before Guarantees
In-Reply-To: <MW4PR10MB577497AFA09E4E48E813F1CFFF4EA@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAKD1RYv+g1L=ifA-_+Whrqb9cEHuH0zqFVSzW7AFg5Smahx2Bw@mail.gmail.com>
 <MW4PR10MB57740D5C55846B248FD24B4DFF4FA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYt_NrHVV4nEc3gZ4szCvhXzHLVWMKdAoxNj7jh4aGT7dQ@mail.gmail.com>
 <MW4PR10MB577497AFA09E4E48E813F1CFFF4EA@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAKD1RYtR0Vao_CZbfVdB+-Ui9yrpjkKYi832LrFZJy1MEbvxmQ@mail.gmail.com>

Thanks for pressing on that, Viktor!

I think I was fooled by my quick-and-dirty test. As I tried to harden it, I
failed to deduce consistent behavior about what parallel stream does when
unchecked exceptions happen. And in fact, it seems like it does *not*
interrupt pending threads (?).

With this in mind, do you consider this behavior of mapConcurrent()
cancelling and joining the virtual threads on a best-effort basis
acceptable trade-off?

I wonder then if it's even worth it for mapConcurrent() to try to join the
threads at all? If it can sometimes join and sometimes not, why not just
always fail fast? At least then you get consistent fail-fast behavior: if a
thread fails to respond to interruption and hangs, the main thread would
still be able to respond to the exception.

Cheers,



On Tue, Jul 8, 2025 at 2:34?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> >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>
> 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/20250712/34318821/attachment-0001.htm>

From liach at openjdk.org  Sun Jul 13 14:22:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 13 Jul 2025 14:22:40 GMT
Subject: RFR: 8360575: java.util.Properties.list() methods trim each value
 to 37 characters in the listed output [v4]
In-Reply-To: <Jy3J4p5L8D4tpKN_-Ghr4VUdrVgnV3YLlKV00Dq-Z9w=.3bbc3090-f954-4526-95f5-0801eb5fd8b2@github.com>
References: <-dRew0C7Qw5REtfjrGiYdfY_bRcnBiUyKXok3lMF9ug=.57d81faf-4a4f-42a9-9238-539a5d0b5625@github.com>
 <Jy3J4p5L8D4tpKN_-Ghr4VUdrVgnV3YLlKV00Dq-Z9w=.3bbc3090-f954-4526-95f5-0801eb5fd8b2@github.com>
Message-ID: <5ZstTCX-w7Cm7Z9RIDx704x3kYEiz6uFvwE9dH264zk=.d04b5676-fdd9-47d4-a275-c9156642d5e1@github.com>

On Mon, 30 Jun 2025 06:01:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to clarify the current implementation of the `java.util.Properties.list(...)` methods?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8360575, the current implementation trims each value to a size of 37 when printing out the value. This behaviour isn't documented by these methods. The change in this PR adds an `@implNote` to make a mention of this current behaviour.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's review - no need to state the number of characters

src/java.base/share/classes/java/util/Properties.java line 1260:

> 1258:      *      PrintWriter out = ...
> 1259:      *      // list the properties to PrintWriter
> 1260:      *      p.forEach((k, v) -> out.println(k + "=" + v));

Should our example recommend using `toString` as a utility to obtain a debug string instead, as it performs no truncation?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26018#discussion_r2203406850

From duke at openjdk.org  Sun Jul 13 18:31:59 2025
From: duke at openjdk.org (duke)
Date: Sun, 13 Jul 2025 18:31:59 GMT
Subject: Withdrawn: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <gxHnytUC-4FxOCzfdNqXlZKsKaRFxv2sIx4OQd8-3TU=.81d3f2be-1df5-45f6-b8d6-20cc4c6186df@github.com>

On Sun, 23 Feb 2025 18:53:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

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

This pull request has been closed without being integrated.

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

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

From liach at openjdk.org  Sun Jul 13 23:55:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 13 Jul 2025 23:55:24 GMT
Subject: RFR: 8361614: Missing sub-int value validation in the Class-File
 API [v3]
In-Reply-To: <uJfr8RQBE0nk26hcVMgU6JXU6cfPbSd1b8HCGgazH1s=.7916f354-c513-4c39-b999-6769b28551d6@github.com>
References: <uJfr8RQBE0nk26hcVMgU6JXU6cfPbSd1b8HCGgazH1s=.7916f354-c513-4c39-b999-6769b28551d6@github.com>
Message-ID: <RNKyk39muHHHKpafxtmaRUoO0X4y8vz859dRlu93Pig=.44f9858f-9e5b-4870-b2f3-338cd61afeab@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 with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-u2-validation
 - Fix style
 - 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=02
  Stats: 541 lines in 33 files changed: 437 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  Sun Jul 13 23:58:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 13 Jul 2025 23:58:38 GMT
Subject: RFR: 8361635: Missing List length validation in the Class-File API
 [v2]
In-Reply-To: <YqhNILbevQ2LlcvsLTnXgduP17cXTHdxToS6tbGlwSE=.e092145a-c661-473c-9be1-ffb523de06fc@github.com>
References: <YqhNILbevQ2LlcvsLTnXgduP17cXTHdxToS6tbGlwSE=.e092145a-c661-473c-9be1-ffb523de06fc@github.com>
Message-ID: <ZfWKsjd5EDSC3pt3U5IZ_O97qtaAC_PEyk4LiFvwcQk=.dcea81ce-30ec-41de-8403-cbfbe83baaa8@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.

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

 - Merge branch 'fix/cf-u2-validation' into fix/cf-list-sizes
 - 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:
  - all: https://git.openjdk.org/jdk/pull/26252/files
  - new: https://git.openjdk.org/jdk/pull/26252/files/4ab67b40..8b393932

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

  Stats: 10159 lines in 332 files changed: 5203 ins; 1939 del; 3017 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 sherman at openjdk.org  Mon Jul 14 04:58:45 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 14 Jul 2025 04:58:45 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII range
 does not match ASCII char
Message-ID: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>

Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.

This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?closed.?

To conform with Level 1 of UTS #18, specifically RL1.5: Simple Loose Matches, simple case folding must be applied to literals and (optionally) to character classes. When applied to character classes, each character class is expected to **be closed under simple case folding**.  See the standard for the detailed explanation and example of "closed".

**RL1.5 states**: 

To meet this requirement, an implementation that supports case-sensitive matching should

    1. Provide at least the simple, default Unicode case-insensitive matching, and
    2. Specify which character properties or constructs are closed under the matching.

**In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:

    1. back-refs
    2. string slices (sequences)
    3. single character,
    4. character families (Unicode Properties ...), and
    5. character class ranges

**Note**: Single characters and families may appear independently or within a character class.

For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.

This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.

For example:

Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true

The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).

**Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.

Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
vs
Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true

vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)

perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/**_i_** ? "true\n" : "false\n"'. => **_true_**

The root issue is that the range construct is not implemented to be closed under simple case folding. Applying toUpperCase() and toLowerCase() to a range like [\u0170-\u0180] does not produce a meaningful or valid range for case-folding comparisons. For example [\u0170-\u0180]  => [\u0053-\u243] with uppercase conversion. 

**What This PR Does**
This PR adds support for ensuring that character class ranges are closed under simple case folding when the (?ui) (Unicode case-insensitive) flag is used, bringing Pattern into better conformance with UTS #18 Level 1 (RL1.5).

**Notes**

**(1) The PR also tries to fix a special corner case for U+00df** 
see:  https://codepoints.net/U+00DF vs  https://codepoints.net/U+1E9E?lang=en for more context.

Pattern.compile("(?ui)\u00df").matcher("\u1e9e").matches() => false
Pattern.compile("(?ui)\u1e9f").matcher("\u00df").matches()  => false

vs

perl -C -e 'print "\x{1e9e}" =~ /\x{df}/ ? "true\n" : "false\n"'  => false
perl -C -e 'print "\x{df}" =~ /\x{1e9e}/ ? "true\n" : "false\n"'  => false
perl -C -e 'print "\x{1e9e}" =~ /\x{df}/i ? "true\n" : "false\n"'  => true
perl -C -e 'print "\x{df}" =~ /\x{1e9e}/i ? "true\n" : "false\n"'  => true

The Java Character class still CORRECTLY returns u+00df for its upper case, as suggested by the Unicode. So our toUpperCase() != toLowerCase() in single() implementation fails to pick SingleU for case-insensitive matching as expected.  

Integer.toHexString(Character.toUpperCase('\u00df')) => 0xdf

**(2) Known limitations: 3 'S'-like characters still fail**

There are 3 characters whose case folding mappings (per CaseFolding.txt) are not captured by our current logic, which relies only on Java's toUpperCase()/toLowerCase() conversions. These characters cannot be matched across constructs like back-ref, slice, single, or range using the current API. We will leave them unchanged for now, pending a possible migration to a pure case folding based matching implementation.

1FD3; S; 0390; # GREEK SMALL LETTER IOTA WITH DIALYTIKA AND OXIA
1FE3; S; 03B0; # GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND OXIA
FB05; S; FB06; # LATIN SMALL LIGATURE LONG S T

**Refs**:
https://bugs.openjdk.org/browse/JDK-6486934
https://bugs.openjdk.org/browse/CCC-6486934
https://cr.openjdk.org/~sherman/6486934_6233084_6504326_6436458/

We are fixing an almost 20-year old bug :-)

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

Commit messages:
 - 8360459: UNICODE_CASE and character class with non-ASCII range does not match ASCII char

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

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

From liach at openjdk.org  Mon Jul 14 05:12:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Jul 2025 05:12:40 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char
In-Reply-To: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
Message-ID: <KkZbNbSXZYZ22wG-u_Qgzafv-SxHfITuIq7lNk4RFNg=.a5a9e5b6-c1a7-4e7f-983f-919fea7b97be@github.com>

On Mon, 14 Jul 2025 04:53:13 GMT, Xueming Shen <sherman at openjdk.org> wrote:

> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
> 
> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?closed.?
> 
> To conform with Level 1 of UTS #18, specifically RL1.5: Simple Loose Matches, simple case folding must be applied to literals and (optionally) to character classes. When applied to character classes, each character class is expected to **be closed under simple case folding**.  See the standard for the detailed explanation and example of "closed".
> 
> **RL1.5 states**: 
> 
> To meet this requirement, an implementation that supports case-sensitive matching should
> 
>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>     2. Specify which character properties or constructs are closed under the matching.
> 
> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
> 
>     1. back-refs
>     2. string slices (sequences)
>     3. single character,
>     4. character families (Unicode Properties ...), and
>     5. character class ranges
> 
> **Note**: Single characters and families may appear independently or within a character class.
> 
> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
> 
> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
> 
> For example:
> 
> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
> 
> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
> 
> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
> 
> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
> vs
> Pattern.compile("(?ui)[S-S]")....

make/jdk/src/classes/build/tools/generatecharacter/CaseFolding.java line 45:

> 43:         var caseFoldingTxt = Paths.get(args[1]);
> 44:         var genSrcFile = Paths.get(args[2]);
> 45:         var supportedTypes = "^.*; [CTS]; .*$";

Do we still need T here given you already have a hardcoded special case?

make/jdk/src/classes/build/tools/generatecharacter/CaseFolding.java line 60:

> 58:                 .map(cols -> String.format("        entry(0x%s, 0x%s),", cols[0], cols[2]))
> 59:                 .collect(Collectors.joining("\n"))
> 60:                 .replaceFirst(",$", "");  // remove the last ','

Suggestion:

                .map(cols -> String.format("        entry(0x%s, 0x%s)", cols[0], cols[2]))
                .collect(Collectors.joining(",\n", "", "\n"));  // remove the last ','

make/jdk/src/classes/build/tools/generatecharacter/CaseFolding.java line 74:

> 72:                 StandardOpenOption.CREATE, StandardOpenOption.TRUNCATE_EXISTING);
> 73:         } catch (IOException e) {
> 74:             e.printStackTrace();

I recommend removing this catch and add `throws Throwable` in the signature of `main`

src/java.base/share/classes/jdk/internal/util/regex/CaseFolding.java.template line 36:

> 34: public final class CaseFolding {
> 35: 
> 36:     private static Map<Integer, Integer> expanded_casefolding = Map.ofEntries(

Suggestion:

    private static final Map<Integer, Integer> expanded_casefolding = Map.ofEntries(

src/java.base/share/classes/jdk/internal/util/regex/CaseFolding.java.template line 99:

> 97:      */
> 98:     public static int[] getClassRangeClosingCharacters(int start, int end) {
> 99:         int[] expanded = new int[expanded_casefolding.size()];

Can be `Math.min(expanded_casefolding.size(), end - start)` in case the table grows large, and update the `off < expanded.length` check below too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2203858280
PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2203854636
PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2203852720
PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2203850027
PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2203851719

From swen at openjdk.org  Mon Jul 14 06:07:43 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 14 Jul 2025 06:07:43 GMT
Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString
 [v2]
In-Reply-To: <TwdDJGVcdwoL0rZFfzm_aeXcKiQN9KZ6uCD6v0Okk8A=.4737a2ee-1169-4b6b-bb5c-63a0cad0defe@github.com>
References: <dke1qw24WS1EQQYaQtQbBCEyZBdPii4wTjetmtrIRvM=.ca14be29-f249-4348-97b2-783ebf0db3fc@github.com>
 <TwdDJGVcdwoL0rZFfzm_aeXcKiQN9KZ6uCD6v0Okk8A=.4737a2ee-1169-4b6b-bb5c-63a0cad0defe@github.com>
Message-ID: <AvPcRYffdppsgsnccSnuWbDnDpNpD732bmy3eP4QxXQ=.714ab216-bafa-4f3b-b388-3e5238936d60@github.com>

On Sun, 15 Jun 2025 05:53:26 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In PR #22928, UUID introduced long-based vectorized hexadecimal to string conversion, which can also be used in Integer::toHexString and Long::toHexString to eliminate table lookups. The benefit of eliminating table lookups is that the performance is better when cache misses occur.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/UUID.java
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

keep alive

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

PR Comment: https://git.openjdk.org/jdk/pull/22942#issuecomment-3067947337

From viktor.klang at oracle.com  Mon Jul 14 07:25:34 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 14 Jul 2025 07:25:34 +0000
Subject: [External] : Re: Question about mapConcurrent() Behavior and
 Happens-Before Guarantees
In-Reply-To: <CAKD1RYtR0Vao_CZbfVdB+-Ui9yrpjkKYi832LrFZJy1MEbvxmQ@mail.gmail.com>
References: <CAKD1RYv+g1L=ifA-_+Whrqb9cEHuH0zqFVSzW7AFg5Smahx2Bw@mail.gmail.com>
 <MW4PR10MB57740D5C55846B248FD24B4DFF4FA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYt_NrHVV4nEc3gZ4szCvhXzHLVWMKdAoxNj7jh4aGT7dQ@mail.gmail.com>
 <MW4PR10MB577497AFA09E4E48E813F1CFFF4EA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtR0Vao_CZbfVdB+-Ui9yrpjkKYi832LrFZJy1MEbvxmQ@mail.gmail.com>
Message-ID: <MW4PR10MB5774798ECB5CB4C1D22DDAF2FF54A@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Jige,

The current behavior is what's currently achievable within the constraints of the Gatherer-model, if that changes in the future it would also mean that there could be stronger "guarantees" made.

In the mean time, the good news is that if you're not satisfied with the behavior offered by mapConcurrent()?you can create your own which does what you want it to do!

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Jige Yu <yujige at gmail.com>
Sent: Sunday, 13 July 2025 05: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: Question about mapConcurrent() Behavior and Happens-Before Guarantees

Thanks for pressing on that, Viktor!

I think I was fooled by my quick-and-dirty test. As I tried to harden it, I failed to deduce consistent behavior about what parallel stream does when unchecked exceptions happen. And in fact, it seems like it does *not* interrupt pending threads (?).

With this in mind, do you consider this behavior of mapConcurrent() cancelling and joining the virtual threads on a best-effort basis acceptable trade-off?

I wonder then if it's even worth it for mapConcurrent() to try to join the threads at all? If it can sometimes join and sometimes not, why not just always fail fast? At least then you get consistent fail-fast behavior: if a thread fails to respond to interruption and hangs, the main thread would still be able to respond to the exception.

Cheers,



On Tue, Jul 8, 2025 at 2:34?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>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<mailto:yujige at gmail.com>>
Sent: Tuesday, 8 July 2025 04:26
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: [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/20250714/85734b2e/attachment-0001.htm>

From sherman at openjdk.org  Mon Jul 14 07:30:45 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 14 Jul 2025 07:30:45 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char
In-Reply-To: <KkZbNbSXZYZ22wG-u_Qgzafv-SxHfITuIq7lNk4RFNg=.a5a9e5b6-c1a7-4e7f-983f-919fea7b97be@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <KkZbNbSXZYZ22wG-u_Qgzafv-SxHfITuIq7lNk4RFNg=.a5a9e5b6-c1a7-4e7f-983f-919fea7b97be@github.com>
Message-ID: <6AFn-UzXqb_oY_XGpadyiepteLDrlHJsSqZfXrybPug=.c8454bbe-15df-463a-8e6c-53022ece337b@github.com>

On Mon, 14 Jul 2025 05:01:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>> 
>> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?closed.?
>> 
>> To conform with Level 1 of UTS #18, specifically RL1.5: Simple Loose Matches, simple case folding must be applied to literals and (optionally) to character classes. When applied to character classes, each character class is expected to **be closed under simple case folding**.  See the standard for the detailed explanation and example of "closed".
>> 
>> **RL1.5 states**: 
>> 
>> To meet this requirement, an implementation that supports case-sensitive matching should
>> 
>>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>>     2. Specify which character properties or constructs are closed under the matching.
>> 
>> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
>> 
>>     1. back-refs
>>     2. string slices (sequences)
>>     3. single character,
>>     4. character families (Unicode Properties ...), and
>>     5. character class ranges
>> 
>> **Note**: Single characters and families may appear independently or within a character class.
>> 
>> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
>> 
>> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
>> 
>> For example:
>> 
>> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
>> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
>> 
>> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
>> 
>> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
>> 
>> Pattern.compile("(?ui)[\u017f-\u...
>
> src/java.base/share/classes/jdk/internal/util/regex/CaseFolding.java.template line 99:
> 
>> 97:      */
>> 98:     public static int[] getClassRangeClosingCharacters(int start, int end) {
>> 99:         int[] expanded = new int[expanded_casefolding.size()];
> 
> Can be `Math.min(expanded_casefolding.size(), end - start)` in case the table grows large, and update the `off < expanded.length` check below too.

The table itself probably isn't going to grow significantly anytime soon, and we?ll likely have enough time to adjust if CaseFolding.txt does get substantially bigger.

That said, I probably should consider reversing the lookup logic: instead of iterating through [start, end], we could iterate over the expansion table and check whether any of its code points fall within the input range, at least when the range size is larger than the size of the table, kinda O(n) vs O(1)-ish.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2204044141

From sherman at openjdk.org  Mon Jul 14 07:54:31 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 14 Jul 2025 07:54:31 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v2]
In-Reply-To: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
Message-ID: <9h1T1edYRoTT3v5CPkY9DN9Lq0bSnDoU8VtK2xn4sIA=.9b57eb79-b59e-4b59-a2ed-94b68735c04f@github.com>

> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
> 
> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?closed.?
> 
> To conform with Level 1 of UTS #18, specifically RL1.5: Simple Loose Matches, simple case folding must be applied to literals and (optionally) to character classes. When applied to character classes, each character class is expected to **be closed under simple case folding**.  See the standard for the detailed explanation and example of "closed".
> 
> **RL1.5 states**: 
> 
> To meet this requirement, an implementation that supports case-sensitive matching should
> 
>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>     2. Specify which character properties or constructs are closed under the matching.
> 
> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
> 
>     1. back-refs
>     2. string slices (sequences)
>     3. single character,
>     4. character families (Unicode Properties ...), and
>     5. character class ranges
> 
> **Note**: Single characters and families may appear independently or within a character class.
> 
> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
> 
> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
> 
> For example:
> 
> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
> 
> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
> 
> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
> 
> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
> vs
> Pattern.compile("(?ui)[S-S]")....

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

  update to address the review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26285/files
  - new: https://git.openjdk.org/jdk/pull/26285/files/640d7a61..735bd722

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

  Stats: 40 lines in 2 files changed: 7 ins; 12 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/26285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26285/head:pull/26285

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

From sherman at openjdk.org  Mon Jul 14 07:58:39 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 14 Jul 2025 07:58:39 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v2]
In-Reply-To: <KkZbNbSXZYZ22wG-u_Qgzafv-SxHfITuIq7lNk4RFNg=.a5a9e5b6-c1a7-4e7f-983f-919fea7b97be@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <KkZbNbSXZYZ22wG-u_Qgzafv-SxHfITuIq7lNk4RFNg=.a5a9e5b6-c1a7-4e7f-983f-919fea7b97be@github.com>
Message-ID: <FjtJX3d3N6G-cU1UubzPHZIrDJIX4TGmnwRVIW387nk=.223ca743-aff0-46f2-a051-9068b8f55f8b@github.com>

On Mon, 14 Jul 2025 05:08:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to address the review comments
>
> make/jdk/src/classes/build/tools/generatecharacter/CaseFolding.java line 45:
> 
>> 43:         var caseFoldingTxt = Paths.get(args[1]);
>> 44:         var genSrcFile = Paths.get(args[2]);
>> 45:         var supportedTypes = "^.*; [CTS]; .*$";
> 
> Do we still need T here given you already have a hardcoded special case?

Yes, there is another T entry for the 'I's that is picked by the logic

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2204103748

From tschatzl at openjdk.org  Mon Jul 14 08:03:47 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 14 Jul 2025 08:03:47 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v41]
In-Reply-To: <OC28lPKl-HlNSudW-YrzcXjUBkIXHRhLwtai_ybCJxw=.33df09f3-67dc-458b-bb6a-72060db5d99f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <OC28lPKl-HlNSudW-YrzcXjUBkIXHRhLwtai_ybCJxw=.33df09f3-67dc-458b-bb6a-72060db5d99f@github.com>
Message-ID: <mmlNgBegOf3YMmUIXIzwKno1STvzS1_5o7Jhmr7-8XA=.92dac625-f773-498b-a014-addfd74e619e@github.com>

On Mon, 7 Jul 2025 12:36:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

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

Not yet...

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

PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3068246695

From viktor.klang at oracle.com  Mon Jul 14 08:11:49 2025
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 14 Jul 2025 08:11:49 +0000
Subject: ClassLoader Leak via Executors.newSingleThreadExecutor(...)
In-Reply-To: <CAM1ck5hB3ym3dt8wAp3uQer5W=9=uboU6azgkCtMJji9ovnBBg@mail.gmail.com>
References: <CAM1ck5hB3ym3dt8wAp3uQer5W=9=uboU6azgkCtMJji9ovnBBg@mail.gmail.com>
Message-ID: <MW4PR10MB57742C3B50578F9C6A17CC40FF54A@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Chris,

I've opened the following JBS issue based on your email:

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

If you intend to open a PR against the issue, please make sure that the OCA status is in order and that there's a regression test associated with the proposed fix.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Chris Dennis <chris.w.dennis at gmail.com>
Sent: Friday, 11 July 2025 16:42
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: ClassLoader Leak via Executors.newSingleThreadExecutor(...)

Hi All,

I believe I've identified a bug in Executors.AutoShutdownDelegatedExecutorService that can trigger a classloader leak even in the presence of "correct" Executor lifecycling. AutoShutdownDelegatedExecutorService only unlinks the PhantomReference used for cleanup handling when it is shutdown via the shutdown() method. If an Executor wrapped in this way is instead shutdown using the shutdownNow() method and it references a classloader via an injected attribute: ThreadFactory, AbortPolicy, etc. then the cleanup action will reference the classloader, and the classloader will remain strongly referenced. Adding an additional override as shown in the attached patch is sufficient to fix the leak in my testing.

Thanks,

Chris

P.S. I believe I'm likely covered wrt OCA via my employer IBM.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250714/f7ceafb5/attachment.htm>

From aph at openjdk.org  Mon Jul 14 08:25:48 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 14 Jul 2025 08:25:48 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v41]
In-Reply-To: <OC28lPKl-HlNSudW-YrzcXjUBkIXHRhLwtai_ybCJxw=.33df09f3-67dc-458b-bb6a-72060db5d99f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
 <OC28lPKl-HlNSudW-YrzcXjUBkIXHRhLwtai_ybCJxw=.33df09f3-67dc-458b-bb6a-72060db5d99f@github.com>
Message-ID: <gvVKJFTN6wQKkP4VxBh_6-GhYNdQSoq3KQ05pj54A0Q=.7fe80989-b668-420e-b439-179786b39800@github.com>

On Mon, 7 Jul 2025 12:36:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

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

AArch64 looks good.

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

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3015276922

From tschatzl at openjdk.org  Mon Jul 14 09:13:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 14 Jul 2025 09:13:38 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v42]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <8lZdT84SJ-daIPPpdq35hAZ0MGa8b07TPpPa3IDp030=.201a5b52-aecb-424e-9bdf-4c64baff5e87@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 58 commits:

 - Merge branch 'master' into pull/23739
 - 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)
 - ... and 48 more: https://git.openjdk.org/jdk/compare/14c79be1...5ab928e8

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

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=41
  Stats: 7124 lines in 112 files changed: 2589 ins; 3594 del; 941 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 dfenacci at openjdk.org  Mon Jul 14 10:34:45 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 14 Jul 2025 10:34:45 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related 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: <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@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 IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` 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");
>         }
>     }
> }
> ...

Thanks a lot for looking into this Volkan!
I left a couple of minor comments.
I also noticed that you haven't yet added the benchmark results to the description: do you want to run them again after the reviews?

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 6014:

> 6012: }
> 6013: 
> 6014: // Encode given `char[]`/`byte[]` to `byte[]` in ISO_8859_1 or ASCII

Thanks for updating the comments! Do we need the markdown back quotes here (and in other `macroAssembler-*` file comments)?

src/hotspot/share/classfile/vmIntrinsics.hpp line 417:

> 415:                                                                                                                         \
> 416:   do_class(java_lang_StringCoding,        "java/lang/StringCoding")                                                     \
> 417:   do_intrinsic(_countPositives,           java_lang_StringCoding, countPositives_name, countPositives_signature,   F_S) \

It is a matter of taste but it might be better not to change the whitespaces (it might make searching for changes (and possibly backports) harder. The rest of the file is not too consistent anyway).

src/hotspot/share/opto/c2_globals.hpp line 666:

> 664:                                                                             \
> 665:   develop(bool, VerifyIntrinsicChecks, false,                               \
> 666:           "Verify that Java level checks in intrinsics work as expected")   \

To make it clearer I think we might want to move "in intrinsic" after "Verify" or at the end.

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

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3015376813
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2204312397
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2204505403
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2204256430

From mchhipa at openjdk.org  Mon Jul 14 10:52:43 2025
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Mon, 14 Jul 2025 10:52:43 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: <y3NdBM7xpS651wQUko-lssFMHz4A_8_HfFf5nQBF4v8=.783227f6-cadb-4467-b894-058b604924a4@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

Hi @DarraghConway , Could you please convert this test to junit test. example : open/test/jdk/java/io/File/DeleteReadOnly.java

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

PR Comment: https://git.openjdk.org/jdk/pull/26193#issuecomment-3068948381

From nbenalla at openjdk.org  Mon Jul 14 12:39:56 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 14 Jul 2025 12:39:56 GMT
Subject: RFR: 8358627:
 tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 26
 [v2]
In-Reply-To: <rvwv_NqO4F8KFEwbbh_IvQ7MvPV91hNMuNj8x9yzdM0=.08774f0c-9d45-4800-9464-eb823111325c@github.com>
References: <mcPF1ypiHlYI3H4kgl0bwvU3KF_YO40Yo6aY6w1LX4c=.4376bebf-3397-4354-be3e-9fd0719b24db@github.com>
 <rvwv_NqO4F8KFEwbbh_IvQ7MvPV91hNMuNj8x9yzdM0=.08774f0c-9d45-4800-9464-eb823111325c@github.com>
Message-ID: <TXmZg0hCoGunNvDSbPeybL6rDelR8ebAjXS2bFPt8ME=.8b4b6810-c6de-4991-bce2-22e4fbff0c6e@github.com>

On Fri, 11 Jul 2025 15:31:53 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.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into problemlisted-sincecheck-test
>    
>    # Conflicts:
>    #	test/jdk/ProblemList.txt
>  - this test no longer needs to be problem listed

Thanks for the reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/25855#issuecomment-3069334654

From nbenalla at openjdk.org  Mon Jul 14 12:39:57 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 14 Jul 2025 12:39:57 GMT
Subject: Integrated: 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: <u2rljVk1fczAvNxwWWO7JYsgmOnHHhjb8splKMWogfQ=.46607279-6bfb-41d0-b618-f5356c32cf84@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.

This pull request has now been integrated.

Changeset: bcd86d57
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bcd86d575fe0682a234228c18b0c2e817d3816da
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8358627: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 26

Reviewed-by: liach, syan

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

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

From rgiulietti at openjdk.org  Mon Jul 14 14:01:50 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 14 Jul 2025 14:01:50 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
Message-ID: <ODSWgGiEFEVnTNYqRtcxjdnltw2zjR1IhYU00uIZVfc=.a73f39a5-8840-43fe-95dd-7bfa9604e420@github.com>

On Sat, 12 Jul 2025 09:18:27 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed useless instruction

I agree that, for the scope of this PR, we should favor consistency with the current spec of `BigInteger.pow()`.
Removing the restriction for some special values like -1 and 1 should be left for a followup PR, if at all, and in a way consistent with `BigInteger.pow()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3069722834

From rgiulietti at openjdk.org  Mon Jul 14 14:39:45 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 14 Jul 2025 14:39:45 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
Message-ID: <hlJRzBO6IWnQ1naGAPRydFUxc7dqbhIGY-ak7va0jCY=.e1965f33-4206-49ec-8403-4bf9ff7aee65@github.com>

On Sat, 12 Jul 2025 09:18:27 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed useless instruction

I'm looking forward for better documentation for the initial estimate code and for the tests.

src/java.base/share/classes/java/math/BigInteger.java line 2750:

> 2748:      * {@code n}th root of the corresponding mathematical integer {@code x} has the
> 2749:      * same sign of {@code x}, and its magnitude is the largest integer {@code r}
> 2750:      * such that {@code r**n <= abs(x)}. It is equal to the value of

Please use HTML `<sup>`, `&le;`, vertical bars, etc., when writing math in Javadoc.
Likewise for `&lfloor;`,`&rfloor;`, and whenever there are better typographic means to express math in Javadoc.
It's more tedious to write, but reads much better.

src/java.base/share/classes/java/math/BigInteger.java line 2803:

> 2801:     /**
> 2802:      * Assume {@code n != 1 && n != 2}
> 2803:      */

There's no need for Javadoc here.
Alternatively, it should document parameters, return value, etc., as usual.

src/java.base/share/classes/java/math/MutableBigInteger.java line 167:

> 165:      * Assume val is in the finite double range.
> 166:      */
> 167:     static MutableBigInteger valueOf(double val, int pow) {

Suggestion:

    private static MutableBigInteger valueOf(double val, int pow) {

src/java.base/share/classes/java/math/MutableBigInteger.java line 1936:

> 1934:      * where {@code nthRoot(., n)} denotes the mathematical {@code n}th root.
> 1935:      * The contents of {@code this} are <em>not</em> changed. The value of {@code this}
> 1936:      * is assumed to be non-negative and the root degree {@code n >= 3}.

I don't think `this` can be negative, can it?

src/java.base/share/classes/java/math/MutableBigInteger.java line 1940:

> 1938:      * @implNote The implementation is based on the material in Richard P. Brent
> 1939:      * and Paul Zimmermann, <a href="https://maths-people.anu.edu.au/~brent/pd/mca-cup-0.5.9.pdf">
> 1940:      * Modern Computer Arithmetic</a>, 27-28.

Suggestion:

     * Modern Computer Arithmetic</a>, p. 27-28.

src/java.base/share/classes/java/math/MutableBigInteger.java line 1943:

> 1941:      *
> 1942:      * @return the integer {@code n}th root of {@code this} and the remainder
> 1943:      */

`@param` is missing.

src/java.base/share/classes/java/math/MutableBigInteger.java line 1964:

> 1962:             final double rad = Math.nextUp(x >= 0 ? x : x + 0x1p64);
> 1963:             final double approx = n == 3 ? Math.cbrt(rad) : Math.pow(rad, Math.nextUp(1.0 / n));
> 1964:             long rLong = (long) Math.ceil(Math.nextUp(approx));

Does `rLong` need to be an overestimate of the true value, or does the algorithm also works for underestimates?
I'm asking because I'm not sure that `Math.pow()` has strong guarantees about its error bounds, whatever the documentation states.

src/java.base/share/classes/java/math/MutableBigInteger.java line 1988:

> 1986:             // Try to shift as many bits as possible
> 1987:             // without losing precision in double's representation
> 1988:             if (bitLength > Double.PRECISION) {

This condition is always `true`, as `bitLength > Long.SIZE` holds here.

src/java.base/share/classes/java/math/MutableBigInteger.java line 2009:

> 2007:             } else {
> 2008:                 shift = 0L;
> 2009:                 rad = this.toBigInteger().doubleValue();

By the above, this becomes useless.

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

PR Review: https://git.openjdk.org/jdk/pull/24898#pullrequestreview-3016614559
PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2205097131
PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2205098001
PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2205098431
PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2205098874
PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2205099587
PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2205099747
PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2205100318
PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2205100683
PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2205100880

From almatvee at openjdk.org  Mon Jul 14 15:10:46 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 14 Jul 2025 15:10:46 GMT
Subject: Integrated: 8361224: [macos] MacSignTest.testMultipleCertificates
 failed
In-Reply-To: <pRWD7kOwWcum4js1s1d48Jx2fhh8bvmd1w9OP0nAvFo=.bce26615-91df-42bb-b8b9-1f17d5ff68c0@github.com>
References: <pRWD7kOwWcum4js1s1d48Jx2fhh8bvmd1w9OP0nAvFo=.bce26615-91df-42bb-b8b9-1f17d5ff68c0@github.com>
Message-ID: <S344GZZd13pBcONCqRIRZEGuWoQ8WAr5BbVoonB38_Q=.6260adb4-3a10-4448-b8ff-4a866fe8ab5e@github.com>

On Fri, 11 Jul 2025 19:57:54 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Test updated to expect `jpackage` to PASS in case of `--mac-signing-key-user-name` and FAIL in case of `-mac-app-image-sign-identity`. See explanation below.
> 
> Case 1: Only common name of certificate is used (PASS):
> jpackage --type dmg -i input -n Test --main-class components.DynamicTreeDemo --main-jar DynamicTreeDemo.jar --mac-sign --mac-signing-keychain jpackagerTest-duplicate.keychain --mac-signing-key-user-name jpackage.openjdk.java.net
> [10:02:37.545] WARNING: Multiple certificates found matching [Developer ID Application: jpackage.openjdk.java.net] using keychain [jpackagerTest-duplicate.keychain], using first one
> 
> Actual codesign command in PASS case:
> /usr/bin/codesign -s CBDE500D7ED18E08F6DF852A5D23D8C7113EB30C -vvvv --timestamp --options runtime --prefix components. --keychain jpackagerTest-duplicate.keychain --force /var/folders/dr/65dj5x3j0296mqtsn9z27xc80000gn/T/jdk.jpackage3439321874841533317/image/Test.app
> 
> CBDE500D7ED18E08F6DF852A5D23D8C7113EB30C is hash of certificate which exist in both jpackagerTest.keychain and jpackagerTest-duplicate.keychain. Based on man page documentation it is allowed. When hash is used codesign will not perform any search of certificates based on man page. So codesign will not fail which is expected.
> 
> Case 2: Full name of certificate is used (FAIL):
> jpackage --type dmg -i input -n Test --main-class components.DynamicTreeDemo --main-jar DynamicTreeDemo.jar --mac-sign --mac-signing-keychain jpackagerTest-duplicate.keychain --mac-app-image-sign-identity "Developer ID Application: jpackage.openjdk.java.net"
> Error: "codesign" failed with following output:
> Developer ID Application: jpackage.openjdk.java.net: found in both /Users/alexander/Library/Keychains/jpackagerTest.keychain-db and /Users/alexander/Library/Keychains/jpackagerTest-duplicate.keychain-db (this is all right)
> Developer ID Application: jpackage.openjdk.java.net: ambiguous (matches "Developer ID Application: jpackage.openjdk.java.net" in /Users/alexander/Library/Keychains/jpackagerTest.keychain-db and "Developer ID Application: jpackage.openjdk.java.net" in /Users/alexander/Library/Keychains/jpackagerTest-duplicate.keychain-db)
> 
> Actual codesign command in FAIL case:
> /usr/bin/codesign -s Developer ID Application: jpackage.openjdk.java.net -vvvv --timestamp --options runtime --prefix components. --keychain jpackagerTest-duplicate.keychain /var/folders/dr/65dj5x3j0296mqtsn9z27xc80000gn/T/jdk.jpackage12899615926124631029/image/Test.app/Contents/runtime/Contents/H...

This pull request has now been integrated.

Changeset: a10ee46e
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a10ee46e6dd94a279e0821d431944bb096493664
Stats:     15 lines in 1 file changed: 6 ins; 0 del; 9 mod

8361224: [macos] MacSignTest.testMultipleCertificates failed

Reviewed-by: asemenyuk

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

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

From duke at openjdk.org  Mon Jul 14 15:42:45 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 14 Jul 2025 15:42:45 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <hlJRzBO6IWnQ1naGAPRydFUxc7dqbhIGY-ak7va0jCY=.e1965f33-4206-49ec-8403-4bf9ff7aee65@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <hlJRzBO6IWnQ1naGAPRydFUxc7dqbhIGY-ak7va0jCY=.e1965f33-4206-49ec-8403-4bf9ff7aee65@github.com>
Message-ID: <UYLJINZ26NuZAcCc6jq0KCpI11uVwVOWSGNrkXcLUIk=.70bdaf9b-b066-454f-806a-e3b104588f2d@github.com>

On Mon, 14 Jul 2025 14:33:26 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed useless instruction
>
> src/java.base/share/classes/java/math/MutableBigInteger.java line 1964:
> 
>> 1962:             final double rad = Math.nextUp(x >= 0 ? x : x + 0x1p64);
>> 1963:             final double approx = n == 3 ? Math.cbrt(rad) : Math.pow(rad, Math.nextUp(1.0 / n));
>> 1964:             long rLong = (long) Math.ceil(Math.nextUp(approx));
> 
> Does `rLong` need to be an overestimate of the true value, or does the algorithm also works for underestimates?
> I'm asking because I'm not sure that `Math.pow()` has strong guarantees about its error bounds, whatever the documentation states.

@rgiulietti The convergence of the recurrence is guaranteed if the initial estimate is larger than or equal to the exact value, AFAIK no guarantee is given when the estimate is smaller than the exact value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2205244158

From rgiulietti at openjdk.org  Mon Jul 14 15:46:45 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 14 Jul 2025 15:46:45 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <UYLJINZ26NuZAcCc6jq0KCpI11uVwVOWSGNrkXcLUIk=.70bdaf9b-b066-454f-806a-e3b104588f2d@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <hlJRzBO6IWnQ1naGAPRydFUxc7dqbhIGY-ak7va0jCY=.e1965f33-4206-49ec-8403-4bf9ff7aee65@github.com>
 <UYLJINZ26NuZAcCc6jq0KCpI11uVwVOWSGNrkXcLUIk=.70bdaf9b-b066-454f-806a-e3b104588f2d@github.com>
Message-ID: <jAyW8BztvN-9vdU9r1pTdFFMuTK4VPrz3lrGNJPUSsQ=.22b8c9ac-5001-47f9-9b23-ae32454fb47d@github.com>

On Mon, 14 Jul 2025 15:40:18 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1964:
>> 
>>> 1962:             final double rad = Math.nextUp(x >= 0 ? x : x + 0x1p64);
>>> 1963:             final double approx = n == 3 ? Math.cbrt(rad) : Math.pow(rad, Math.nextUp(1.0 / n));
>>> 1964:             long rLong = (long) Math.ceil(Math.nextUp(approx));
>> 
>> Does `rLong` need to be an overestimate of the true value, or does the algorithm also works for underestimates?
>> I'm asking because I'm not sure that `Math.pow()` has strong guarantees about its error bounds, whatever the documentation states.
>
> @rgiulietti The convergence of the recurrence is guaranteed if the initial estimate is larger than or equal to the exact value, AFAIK no guarantee is given when the estimate is smaller than the exact value.

This is my hunch as well.
So while the use of `nextUp()` and `ceil()` certainly help to achieve an overestimate, I'm less sure that this is sufficient when using `pow()`. If the latter has some error bigger than a few ulps, then we are in trouble.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2205251784

From duke at openjdk.org  Mon Jul 14 15:49:42 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 14 Jul 2025 15:49:42 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <hlJRzBO6IWnQ1naGAPRydFUxc7dqbhIGY-ak7va0jCY=.e1965f33-4206-49ec-8403-4bf9ff7aee65@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <hlJRzBO6IWnQ1naGAPRydFUxc7dqbhIGY-ak7va0jCY=.e1965f33-4206-49ec-8403-4bf9ff7aee65@github.com>
Message-ID: <LrzpLm_AX3q1Lm2yxgEV78CaALSx0zDo6O4CPKngTho=.80dbfe1e-47e9-43ff-8b0c-23f0fb4be3e5@github.com>

On Mon, 14 Jul 2025 14:32:45 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed useless instruction
>
> src/java.base/share/classes/java/math/MutableBigInteger.java line 1936:
> 
>> 1934:      * where {@code nthRoot(., n)} denotes the mathematical {@code n}th root.
>> 1935:      * The contents of {@code this} are <em>not</em> changed. The value of {@code this}
>> 1936:      * is assumed to be non-negative and the root degree {@code n >= 3}.
> 
> I don't think `this` can be negative, can it?

@rgiulietti `this` could be negative if it were a `SignedMutableBigInteger`, by the way the same assuption is made in `MBI.sqrtRem()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2205257292

From rgiulietti at openjdk.org  Mon Jul 14 15:56:53 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 14 Jul 2025 15:56:53 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <LrzpLm_AX3q1Lm2yxgEV78CaALSx0zDo6O4CPKngTho=.80dbfe1e-47e9-43ff-8b0c-23f0fb4be3e5@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <hlJRzBO6IWnQ1naGAPRydFUxc7dqbhIGY-ak7va0jCY=.e1965f33-4206-49ec-8403-4bf9ff7aee65@github.com>
 <LrzpLm_AX3q1Lm2yxgEV78CaALSx0zDo6O4CPKngTho=.80dbfe1e-47e9-43ff-8b0c-23f0fb4be3e5@github.com>
Message-ID: <Q3MYteZsDu_5Hg-6MBdd7D8M1siSz1PCK05W84PIdm4=.447c9277-c261-446e-8c90-3dcd302217f7@github.com>

On Mon, 14 Jul 2025 15:46:47 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1936:
>> 
>>> 1934:      * where {@code nthRoot(., n)} denotes the mathematical {@code n}th root.
>>> 1935:      * The contents of {@code this} are <em>not</em> changed. The value of {@code this}
>>> 1936:      * is assumed to be non-negative and the root degree {@code n >= 3}.
>> 
>> I don't think `this` can be negative, can it?
>
> @rgiulietti `this` could be negative if it were a `SignedMutableBigInteger`, by the way the same assumption is made in `MBI.sqrtRem()`.

True

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2205270772

From duke at openjdk.org  Mon Jul 14 15:56:53 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 14 Jul 2025 15:56:53 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <jAyW8BztvN-9vdU9r1pTdFFMuTK4VPrz3lrGNJPUSsQ=.22b8c9ac-5001-47f9-9b23-ae32454fb47d@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <hlJRzBO6IWnQ1naGAPRydFUxc7dqbhIGY-ak7va0jCY=.e1965f33-4206-49ec-8403-4bf9ff7aee65@github.com>
 <UYLJINZ26NuZAcCc6jq0KCpI11uVwVOWSGNrkXcLUIk=.70bdaf9b-b066-454f-806a-e3b104588f2d@github.com>
 <jAyW8BztvN-9vdU9r1pTdFFMuTK4VPrz3lrGNJPUSsQ=.22b8c9ac-5001-47f9-9b23-ae32454fb47d@github.com>
Message-ID: <bhSaUJRAfVGUx_F0FVl4tb7YIn7qWlodOUbOfmorQp8=.7ec3d676-6885-4b6d-afc5-f12063fbff5b@github.com>

On Mon, 14 Jul 2025 15:43:58 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This is my hunch as well. So while the use of `nextUp()` and `ceil()` certainly help to achieve an overestimate, I'm less sure that this is sufficient when using `pow()`. If the latter has some error bigger than a few ulps, then we are in trouble.

If the results are guaranteed to be semi-monotonic, then `nextUp()` and `ceil()` should be sufficient to achieve an overestimate...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2205267660

From hboehm at google.com  Mon Jul 14 16:20:35 2025
From: hboehm at google.com (Hans Boehm)
Date: Mon, 14 Jul 2025 09:20:35 -0700
Subject: RFR: 8077587: BigInteger Roots [v20]
In-Reply-To: <ioYsgn0VBRtf0NDboh5rpHRZ_RmWAf7rfVcYoKhFa0A=.3a007def-02ef-4da7-b20c-45346e7950d0@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <Knp7tAtQgjRMMbZAdATtAwFMrzE95gvcC7U2JDLxRq4=.5cc96bff-fd18-4957-bd80-3fb01907c551@github.com>
 <ioYsgn0VBRtf0NDboh5rpHRZ_RmWAf7rfVcYoKhFa0A=.3a007def-02ef-4da7-b20c-45346e7950d0@github.com>
Message-ID: <CAMOCf+gnr-B5i=9dENJnE+U4sNXbDCqFYXNsc17gTy4v83Z-WA@mail.gmail.com>

On Fri, Jul 11, 2025 at 11:44?AM fabioromano1 <duke at openjdk.org> wrote:
>
> On Fri, 11 Jul 2025 18:07:31 GMT, fabioromano1 <duke at openjdk.org> wrote:
>
> >> This PR implements nth root computation for BigIntegers using Newton
method.
> >
> > fabioromano1 has updated the pull request incrementally with one
additional commit since the last revision:
> >
> >   Avoid to discard fraction bits in the initial estimate
>
> The current explanation for the exception of negative `n` is justified by
consistency with the explanation for negative `exponent` in
`BigInteger.pow(int)`, so changing this explanation would cause an
inconsistency in the documentation of `BigInteger` operations.
>
But the mathematics are completely different. The comment makes sense for
pow(), which naturally produces integers for non-negative arguments.

It makes no sense at all for nthRoot, which almost never naturally produces
an integer. We make it produce an integer via suitable truncation, as the
spec says. We could clearly do the same thing for negative n, though I tend
to agree we probably don't want to.

Let's please not fake consistency here where there inherently is none. the
integers are closed under positive powers, and not under positive nthRoots.
We can't change that.

Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250714/9ef8b7b3/attachment.htm>

From jvernee at openjdk.org  Mon Jul 14 16:31:17 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 14 Jul 2025 16:31:17 GMT
Subject: RFR: 8362169: Pointer passed to upcall may get wrong scope
Message-ID: <p9Ykd_mrk9HP9goCgtwnry5CJEzhtSpIblLZUZLIl0w=.73dae209-8b94-4e5b-9001-bf8c3861a2b5@github.com>

Issue copied from the JBS issue:

When an upcall stub accepts a by-value struct, and the struct is passed by the underlying ABI as a pointer to a temporary copy on the caller's stack (for instance on Windows when the struct doesn't fit into a single register), a scope is created for the duration of the upcall, to which the memory segment for this struct is attached.

However, if such a scope is created for the upcall, any other unrelated pointer argument will _also_ be attached to the same scope. This is incorrect, as unrelated pointer arguments should be attached to the global scope. The underlying issue is that, when deciding whether a particular argument needs to be attached to the scope, we check if _any_ of the argument needs to be attached to the created scope.

This PR fixes the issue by calling `boxAddress.needsScope()` in `BindingSpecializer::emitBoxAddress`, which checks only if that particular argument needs to be attached to the upcall scope.

I've also renamed the 'global' `needsScope` method, which checks whether _any_ of the arguments need a scope, to `anyArgNeedsScope` for clarity.

Testing: `jdk_foreign` test suite on Mac/Windows/Linux x64, and Mac/Linux aarch64

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

Commit messages:
 - fix
 - fix test
 - add test

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

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

From duke at openjdk.org  Mon Jul 14 16:34:42 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 14 Jul 2025 16:34:42 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <bhSaUJRAfVGUx_F0FVl4tb7YIn7qWlodOUbOfmorQp8=.7ec3d676-6885-4b6d-afc5-f12063fbff5b@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <hlJRzBO6IWnQ1naGAPRydFUxc7dqbhIGY-ak7va0jCY=.e1965f33-4206-49ec-8403-4bf9ff7aee65@github.com>
 <UYLJINZ26NuZAcCc6jq0KCpI11uVwVOWSGNrkXcLUIk=.70bdaf9b-b066-454f-806a-e3b104588f2d@github.com>
 <jAyW8BztvN-9vdU9r1pTdFFMuTK4VPrz3lrGNJPUSsQ=.22b8c9ac-5001-47f9-9b23-ae32454fb47d@github.com>
 <bhSaUJRAfVGUx_F0FVl4tb7YIn7qWlodOUbOfmorQp8=.7ec3d676-6885-4b6d-afc5-f12063fbff5b@github.com>
Message-ID: <fXGHdMQcRrUn3BjeWfo_VjVTwTjQ6HyGkliRSjW3z0w=.4ac3edec-14ad-4af8-940e-0a5f860b3706@github.com>

On Mon, 14 Jul 2025 15:52:19 GMT, fabioromano1 <duke at openjdk.org> wrote:

> This is my hunch as well. So while the use of `nextUp()` and `ceil()` certainly help to achieve an overestimate, I'm less sure that this is sufficient when using `pow()`. If the latter has some error bigger than a few ulps, then we are in trouble.

@rgiulietti Anyway, if `Math.pow()` does not respect the specifications, an overestimate is guaranteed to be found taking the ceil integer part of the division in the first iteration of the recurence, rather than the floor integer part.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2205343348

From duke at openjdk.org  Mon Jul 14 16:43:39 2025
From: duke at openjdk.org (Darragh Conway)
Date: Mon, 14 Jul 2025 16:43:39 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: <IjwtjWSWvnt-ITWc7qrSdokuBhcRmaN2SVtTNBqX9mM=.6b88aac4-45a8-4a08-a8bf-47c785288457@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

Thanks for the suggestion, I'll create a separate ticket for that junit conversion...

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

PR Comment: https://git.openjdk.org/jdk/pull/26193#issuecomment-3070243572

From duke at openjdk.org  Mon Jul 14 16:56:49 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 14 Jul 2025 16:56:49 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
Message-ID: <NAgYZ-UqgcNwUTjo7AKhIE-sb6omORrqalQYxMQgefc=.46e0e0b3-01af-49c4-b948-44fdcb7ff937@github.com>

On Sat, 12 Jul 2025 09:18:27 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed useless instruction

The integers are closed under positive powers, and not under positive nthRoots, this is true. However, the problem remains, as if the root degree `n` is negative, then for radicands that are not 1, -1 or 0 we should return 0, and zero raised to a negative exponent is undefined in real numbers, and so the remainder is.

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

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3070276534

From rriggs at openjdk.org  Mon Jul 14 17:16:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 14 Jul 2025 17:16:40 GMT
Subject: RFR: 8361959: [GCC static analyzer] java_props_md.c  leak of
 'temp'  variable is reported [v2]
In-Reply-To: <KnrbHzTaREYx4MM0mKtjtyprF7KPGv1fTRnyxFzttqQ=.e94cb087-cd46-434c-b3e6-256daf28c348@github.com>
References: <RqEj6H9uqBuW5LmTcU73gzQNAQnQLgUDWoqfaxIHLBw=.a9871b5c-c36c-433b-8091-8f0648669836@github.com>
 <KnrbHzTaREYx4MM0mKtjtyprF7KPGv1fTRnyxFzttqQ=.e94cb087-cd46-434c-b3e6-256daf28c348@github.com>
Message-ID: <sjy0tmO4QB9bQq_Hdk_3vYeBpObDwv2bGM9e0LMd21c=.f4664421-9c22-4e1d-9364-f460d57c41f1@github.com>

On Sat, 12 Jul 2025 17:36:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The following is reported when building with the gcc static analyzer (-fanalyzer) :
>> 
>> 
>> /jdk/src/java.base/unix/native/libjava/java_props_md.c:244:17: warning: leak of 'temp' [CWE-401] [-Wanalyzer-malloc-leak]
>>   244 | return 0;
>> 
>> 
>> Seems we have to free temp in an early return.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   free before another early return

Looks good.

(temp doesn't look like a temporary since its used throughout the function.
And all the other locals have useful names.)

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26264#pullrequestreview-3017138764

From rriggs at openjdk.org  Mon Jul 14 17:08:43 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 14 Jul 2025 17:08:43 GMT
Subject: RFR: 8360575: java.util.Properties.list() methods trim each value
 to 37 characters in the listed output [v4]
In-Reply-To: <5ZstTCX-w7Cm7Z9RIDx704x3kYEiz6uFvwE9dH264zk=.d04b5676-fdd9-47d4-a275-c9156642d5e1@github.com>
References: <-dRew0C7Qw5REtfjrGiYdfY_bRcnBiUyKXok3lMF9ug=.57d81faf-4a4f-42a9-9238-539a5d0b5625@github.com>
 <Jy3J4p5L8D4tpKN_-Ghr4VUdrVgnV3YLlKV00Dq-Z9w=.3bbc3090-f954-4526-95f5-0801eb5fd8b2@github.com>
 <5ZstTCX-w7Cm7Z9RIDx704x3kYEiz6uFvwE9dH264zk=.d04b5676-fdd9-47d4-a275-c9156642d5e1@github.com>
Message-ID: <SPjdwdh1yOESPSxZT4-P9O61ItXdg8-U8ei-56rk9Nc=.f55da6ee-4558-4791-b219-521c9f339fe3@github.com>

On Sun, 13 Jul 2025 14:20:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Alan's review - no need to state the number of characters
>
> src/java.base/share/classes/java/util/Properties.java line 1260:
> 
>> 1258:      *      PrintWriter out = ...
>> 1259:      *      // list the properties to PrintWriter
>> 1260:      *      p.forEach((k, v) -> out.println(k + "=" + v));
> 
> Should our example recommend using `toString` as a utility to obtain a debug string instead, as it performs no truncation?

Using `toString()` will be harder to read; as proposed each property is on a separate line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26018#discussion_r2205406016

From duke at openjdk.org  Mon Jul 14 16:43:41 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 14 Jul 2025 16:43:41 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <jAyW8BztvN-9vdU9r1pTdFFMuTK4VPrz3lrGNJPUSsQ=.22b8c9ac-5001-47f9-9b23-ae32454fb47d@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <hlJRzBO6IWnQ1naGAPRydFUxc7dqbhIGY-ak7va0jCY=.e1965f33-4206-49ec-8403-4bf9ff7aee65@github.com>
 <UYLJINZ26NuZAcCc6jq0KCpI11uVwVOWSGNrkXcLUIk=.70bdaf9b-b066-454f-806a-e3b104588f2d@github.com>
 <jAyW8BztvN-9vdU9r1pTdFFMuTK4VPrz3lrGNJPUSsQ=.22b8c9ac-5001-47f9-9b23-ae32454fb47d@github.com>
Message-ID: <xgskj4LLvFR3upWuqjKEDVCLQ4uEXrorlfxlimZ17ts=.6ae32e3b-56c8-453b-a369-f806fa2ec3fa@github.com>

On Mon, 14 Jul 2025 15:43:58 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti The convergence of the recurrence is guaranteed if the initial estimate is larger than or equal to the exact value, AFAIK no guarantee is given when the estimate is smaller than the exact value.
>
> This is my hunch as well.
> So while the use of `nextUp()` and `ceil()` certainly help to achieve an overestimate, I'm less sure that this is sufficient when using `pow()`. If the latter has some error bigger than a few ulps, then we are in trouble.

@rgiulietti Now that I checked the recurrence better, it seems to me that it should give an overestimate if `rLong` is an underestimate, without modify it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2205358875

From naoto at openjdk.org  Mon Jul 14 17:21:24 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 14 Jul 2025 17:21:24 GMT
Subject: RFR: 8361972: Clarify the condition of System.console() about standard
 input/output
Message-ID: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>

This accompanies the fix for [JDK-8361613](https://bugs.openjdk.org/browse/JDK-8361613), which restricts `System.console()` to return a `Console` instance only when both standard input and output are connected to a terminal. The change here is solely a specification clarification and tightening of the `java.io.Console` javadoc to reflect this behavior. We are separating the spec clarification because the fix itself may be backported to prior LTS releases without requiring a Maintenance Review process.

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

Commit messages:
 - initial commit

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

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

From rriggs at openjdk.org  Mon Jul 14 17:08:42 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 14 Jul 2025 17:08:42 GMT
Subject: RFR: 8360575: java.util.Properties.list() methods trim each value
 to 37 characters in the listed output [v4]
In-Reply-To: <Jy3J4p5L8D4tpKN_-Ghr4VUdrVgnV3YLlKV00Dq-Z9w=.3bbc3090-f954-4526-95f5-0801eb5fd8b2@github.com>
References: <-dRew0C7Qw5REtfjrGiYdfY_bRcnBiUyKXok3lMF9ug=.57d81faf-4a4f-42a9-9238-539a5d0b5625@github.com>
 <Jy3J4p5L8D4tpKN_-Ghr4VUdrVgnV3YLlKV00Dq-Z9w=.3bbc3090-f954-4526-95f5-0801eb5fd8b2@github.com>
Message-ID: <cMoQM_ARhbmKsX60uksHu0JtsnmaDTkQ5IUiW9r3z00=.928a3369-3005-4663-bb2e-3645ee2bb98c@github.com>

On Mon, 30 Jun 2025 06:01:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to clarify the current implementation of the `java.util.Properties.list(...)` methods?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8360575, the current implementation trims each value to a size of 37 when printing out the value. This behaviour isn't documented by these methods. The change in this PR adds an `@implNote` to make a mention of this current behaviour.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's review - no need to state the number of characters

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26018#pullrequestreview-3017111709

From hboehm at google.com  Mon Jul 14 17:39:46 2025
From: hboehm at google.com (Hans Boehm)
Date: Mon, 14 Jul 2025 10:39:46 -0700
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <NAgYZ-UqgcNwUTjo7AKhIE-sb6omORrqalQYxMQgefc=.46e0e0b3-01af-49c4-b948-44fdcb7ff937@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <NAgYZ-UqgcNwUTjo7AKhIE-sb6omORrqalQYxMQgefc=.46e0e0b3-01af-49c4-b948-44fdcb7ff937@github.com>
Message-ID: <CAMOCf+jvFDoJ+3R5qcr9i1X2AAADLi-13g1MEE2hCK2N9wyjCA@mail.gmail.com>

On Mon, Jul 14, 2025 at 10:14?AM fabioromano1 <duke at openjdk.org> wrote:
>
> On Sat, 12 Jul 2025 09:18:27 GMT, fabioromano1 <duke at openjdk.org> wrote:
>
> >> This PR implements nth root computation for BigIntegers using Newton
method.
> >
> > fabioromano1 has updated the pull request incrementally with one
additional commit since the last revision:
> >
> >   Removed useless instruction
>
> The integers are closed under positive powers, and not under positive
nthRoots, this is true. However, the problem remains, as if the root degree
`n` is negative, then for radicands that are not 1, -1 or 0 we should
return 0, and zero raised to a negative exponent is undefined in real
numbers, and so the remainder is.
>
Good point. But by that argument nthRoot(int n) should still be
well-defined. And the comment for nthRootAndRemainder still looks wrong to
me

>From the spec, we can take the answer to be "(x.signum() *
floor(abs(nthRoot(x, n)))), where nthRoot(x, n) denotes the real nth root
of x treated as a real".

This means that e.g. the (-3)rd root of 2, is floor(abs(nthRoot(2, -3))),
nthRoot(2, -3) is presumably 1 / nthRoot(2, 3), which is 0.79... So if we
take this as the definition, the answer is clearly 0, which is perfectly
well-defined.

Again, I'm not arguing for a functional change. I just don't like the spec
comments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250714/b1312a7d/attachment.htm>

From naoto at openjdk.org  Mon Jul 14 18:14:48 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 14 Jul 2025 18:14:48 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v2]
In-Reply-To: <9h1T1edYRoTT3v5CPkY9DN9Lq0bSnDoU8VtK2xn4sIA=.9b57eb79-b59e-4b59-a2ed-94b68735c04f@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <9h1T1edYRoTT3v5CPkY9DN9Lq0bSnDoU8VtK2xn4sIA=.9b57eb79-b59e-4b59-a2ed-94b68735c04f@github.com>
Message-ID: <AZoyQaqBTkKTCt1R05DWBsFQXyYJJ87VoEn4djB8JfM=.2afebbe4-23fc-42e7-b4d1-ab1ab62fcb8d@github.com>

On Mon, 14 Jul 2025 07:54:31 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>> 
>> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?closed.?
>> 
>> To conform with Level 1 of UTS #18, specifically RL1.5: Simple Loose Matches, simple case folding must be applied to literals and (optionally) to character classes. When applied to character classes, each character class is expected to **be closed under simple case folding**.  See the standard for the detailed explanation and example of "closed".
>> 
>> **RL1.5 states**: 
>> 
>> To meet this requirement, an implementation that supports case-sensitive matching should
>> 
>>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>>     2. Specify which character properties or constructs are closed under the matching.
>> 
>> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
>> 
>>     1. back-refs
>>     2. string slices (sequences)
>>     3. single character,
>>     4. character families (Unicode Properties ...), and
>>     5. character class ranges
>> 
>> **Note**: Single characters and families may appear independently or within a character class.
>> 
>> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
>> 
>> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
>> 
>> For example:
>> 
>> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
>> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
>> 
>> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
>> 
>> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
>> 
>> Pattern.compile("(?ui)[\u017f-\u...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to address the review comments

Looks good. Thanks for adding case folding support which is long overdue ?
Since this is adding a new support for casefolding for character class ranges, I think CSR and a release note should be considered.

make/jdk/src/classes/build/tools/generatecharacter/CaseFolding.java line 73:

> 71:             StandardOpenOption.CREATE, StandardOpenOption.TRUNCATE_EXISTING);
> 72:     }
> 73: }

Needs a NL at the end

test/jdk/java/util/regex/CaseFoldingTest.java line 30:

> 28:  * @library /lib/testlibrary/java/lang
> 29:  * @author Xueming Shen
> 30:  * @run testng CaseFoldingTest

Since this is a new test, I think we prefer junit over testng

test/jdk/java/util/regex/CaseFoldingTest.java line 61:

> 59: 
> 60:         var results = Files.readAllLines(UCDFiles.CASEFOLDING)
> 61:             .stream()

Files.lines() may be more concise

test/jdk/lib/testlibrary/java/lang/UCDFiles.java line 59:

> 57:         UCD_DIR.resolve("emoji").resolve("emoji-data.txt");
> 58:     public static Path CASEFOLDING =
> 59:         UCD_DIR.resolve("CaseFolding.txt");

Copyright year -> 2025

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

PR Review: https://git.openjdk.org/jdk/pull/26285#pullrequestreview-3017279774
PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2205510750
PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2205508784
PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2205517080
PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2205521609

From igraves at openjdk.org  Mon Jul 14 18:51:28 2025
From: igraves at openjdk.org (Ian Graves)
Date: Mon, 14 Jul 2025 18:51:28 GMT
Subject: RFR: 8358768: [vectorapi] Make VectorOperators.SUADD an
 Associative [v3]
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: <y0Hl_HpYyWrixEU6wE_UOyqGGuk9nvhZBz5ajRKNV84=.5529adc7-f7ea-4aa7-b8a4-704c21e5f16e@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:

  Cleaning up test cases

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26099/files
  - new: https://git.openjdk.org/jdk/pull/26099/files/6c8d8952..8cfc55ee

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

  Stats: 611 lines in 21 files changed: 568 ins; 0 del; 43 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 jlu at openjdk.org  Mon Jul 14 18:54:40 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 14 Jul 2025 18:54:40 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v2]
In-Reply-To: <iTEuOKSnDvEPDh3HxMsg6eRIFULYmgEETWwxlaw1xDg=.8ea80543-fba1-418c-88e3-43b183102b4c@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <iTEuOKSnDvEPDh3HxMsg6eRIFULYmgEETWwxlaw1xDg=.8ea80543-fba1-418c-88e3-43b183102b4c@github.com>
Message-ID: <f5V9zypdDopC_CPihCYcUPJ6jEUOgCCi-6r5yM7eT7U=.1280a81d-11ed-476e-b798-d072afdde2e9@github.com>

On Fri, 11 Jul 2025 22:07:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
>> This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/io/Console/LocaleTest.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/java/io/Console/DefaultCharsetTest.java line 52:

> 50:     void testDefaultCharset(String stdoutEncoding) throws Exception {
> 51:         // check "expect" command availability
> 52:         var expect = Paths.get("/usr/bin/expect");

We only need to check "expect" availability once, so we should move this check to a `@BeforeAll` static method. It's also more clear that this check is a precondition, and not part of the actual test. Applies to the other locations, but primarily the other parameterized tests.

test/jdk/java/io/Console/ModuleSelectionTest.java line 32:

> 30:  * @library /test/lib
> 31:  * @build jdk.test.lib.Utils
> 32:  *        jdk.test.lib.JDKToolFinder

Is `jdk.test.lib.JDKToolFinder` needed?

test/jdk/java/io/Console/ModuleSelectionTest.java line 65:

> 63:     @ParameterizedTest
> 64:     @MethodSource("options")
> 65:     void testWithoutExpect(String opts, String expected) throws Exception {

`expected` param looks unused.

test/jdk/java/io/Console/ModuleSelectionTest.java line 75:

> 73:     @ParameterizedTest
> 74:     @MethodSource("options")
> 75:     void testWithExpect(String opts, String expected) throws Exception {

I think it would be more clear if these tests were renamed to `expectConsoleTest` and `noConsoleTest` or something along those lines.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2205500449
PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2205576522
PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2205557781
PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2205573038

From jlu at openjdk.org  Mon Jul 14 18:58:44 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 14 Jul 2025 18:58:44 GMT
Subject: RFR: 8361972: Clarify the condition of System.console() about
 standard input/output
In-Reply-To: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
References: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
Message-ID: <JLbbLxKm-RKiYkrnRpuPKEczGfcUayNftwBAWHydwZQ=.b9d6c1ec-99a4-49dd-a665-83be8c4bb1bf@github.com>

On Mon, 14 Jul 2025 17:15:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This accompanies the fix for [JDK-8361613](https://bugs.openjdk.org/browse/JDK-8361613), which restricts `System.console()` to return a `Console` instance only when both standard input and output are connected to a terminal. The change here is solely a specification clarification and tightening of the `java.io.Console` javadoc to reflect this behavior. We are separating the spec clarification because the fix itself may be backported to prior LTS releases without requiring a Maintenance Review process.

src/java.base/share/classes/java/io/Console.java line 49:

> 47:  * was launched.  If the virtual machine is started automatically, for
> 48:  * example by a background job scheduler, or if one or both of the
> 49:  * standard input or output has been redirected, then it may not have a

If we are claiming that `System.console()` should only return a "Console instance only when both standard input and output are connected to a terminal." then is this _may_ wording not restrictive enough? Or is that nuance negligible?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26299#discussion_r2205601642

From naoto at openjdk.org  Mon Jul 14 19:40:40 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 14 Jul 2025 19:40:40 GMT
Subject: RFR: 8361972: Clarify the condition of System.console() about
 standard input/output
In-Reply-To: <JLbbLxKm-RKiYkrnRpuPKEczGfcUayNftwBAWHydwZQ=.b9d6c1ec-99a4-49dd-a665-83be8c4bb1bf@github.com>
References: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
 <JLbbLxKm-RKiYkrnRpuPKEczGfcUayNftwBAWHydwZQ=.b9d6c1ec-99a4-49dd-a665-83be8c4bb1bf@github.com>
Message-ID: <bskq681GA51Af9bhRGSKfTL4RLtvLw7QlWqo2_v5pZ4=.f7f5bb9f-6ff2-4533-b5fc-57667264ca54@github.com>

On Mon, 14 Jul 2025 18:56:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This accompanies the fix for [JDK-8361613](https://bugs.openjdk.org/browse/JDK-8361613), which restricts `System.console()` to return a `Console` instance only when both standard input and output are connected to a terminal. The change here is solely a specification clarification and tightening of the `java.io.Console` javadoc to reflect this behavior. We are separating the spec clarification because the fix itself may be backported to prior LTS releases without requiring a Maintenance Review process.
>
> src/java.base/share/classes/java/io/Console.java line 49:
> 
>> 47:  * was launched.  If the virtual machine is started automatically, for
>> 48:  * example by a background job scheduler, or if one or both of the
>> 49:  * standard input or output has been redirected, then it may not have a
> 
> If we are claiming that `System.console()` should **only** return a "Console instance only when both standard input and output are connected to a terminal." then is the _may_ wording not restrictive enough? Or is that nuance negligible?

Intention here is that, we do want to restirct to not return JLine based Console when either/both of stdin/out is redirected, I think we would not want to restrict them as the spec. For example, `System.console()` in jshell returns non-null, even if the remote JVM is not-attached to a terminal. I will describe this sublety in the CSR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26299#discussion_r2205665390

From rriggs at openjdk.org  Mon Jul 14 19:58:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 14 Jul 2025 19:58:40 GMT
Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes [v4]
In-Reply-To: <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
 <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>
Message-ID: <LWeR7w6C_9o9alZa3ceQDEB2VX_8HuyZpsLG5jqv47U=.e3f2e5ed-6144-410a-a583-519ceace9a6f@github.com>

On Tue, 1 Jul 2025 17:02:27 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:
> 
>   Adding comment about maintainability.

Looks good

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26044#pullrequestreview-3017586022

From sherman at openjdk.org  Mon Jul 14 20:13:06 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 14 Jul 2025 20:13:06 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v3]
In-Reply-To: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
Message-ID: <FMXB0H9GZvga0ffJAmCnSKL6uTOaDOc3JS2Ze9Ph6Xg=.bcaf2b51-7a0f-4bc2-8c11-d613dda03116@github.com>

> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
> 
> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
> 
> **RL1.5 states**: 
> 
> To meet this requirement, an implementation that supports case-sensitive matching should
> 
>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>     2. Specify which character properties or constructs are closed under the matching.
> 
> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
> 
>     1. back-refs
>     2. string slices (sequences)
>     3. single character,
>     4. character families (Unicode Properties ...), and
>     5. character class ranges
> 
> **Note**: Single characters and families may appear independently or within a character class.
> 
> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
> 
> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
> 
> For example:
> 
> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
> 
> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
> 
> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
> 
> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
> vs
> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
> 
> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
> 
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/**_i_** ? "true\n" : "false\n"'. => **_true_**
> 
> The root issue is that the ran...

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

  update to address the review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26285/files
  - new: https://git.openjdk.org/jdk/pull/26285/files/735bd722..e18d2668

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

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

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

From naoto at openjdk.org  Mon Jul 14 20:23:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 14 Jul 2025 20:23:25 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v3]
In-Reply-To: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
Message-ID: <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>

> In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
> This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.

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

  Reflects review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26273/files
  - new: https://git.openjdk.org/jdk/pull/26273/files/82773085..5a4114c7

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

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

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

From naoto at openjdk.org  Mon Jul 14 20:32:44 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 14 Jul 2025 20:32:44 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v2]
In-Reply-To: <f5V9zypdDopC_CPihCYcUPJ6jEUOgCCi-6r5yM7eT7U=.1280a81d-11ed-476e-b798-d072afdde2e9@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <iTEuOKSnDvEPDh3HxMsg6eRIFULYmgEETWwxlaw1xDg=.8ea80543-fba1-418c-88e3-43b183102b4c@github.com>
 <f5V9zypdDopC_CPihCYcUPJ6jEUOgCCi-6r5yM7eT7U=.1280a81d-11ed-476e-b798-d072afdde2e9@github.com>
Message-ID: <rf5xQ_CGwHtzkolp923Zulecw2CbYqfoYk88vPh3f14=.02f0462a-3f03-4f7e-b626-e85f32e3973b@github.com>

On Mon, 14 Jul 2025 17:57:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/jdk/java/io/Console/LocaleTest.java
>>   
>>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> test/jdk/java/io/Console/DefaultCharsetTest.java line 52:
> 
>> 50:     void testDefaultCharset(String stdoutEncoding) throws Exception {
>> 51:         // check "expect" command availability
>> 52:         var expect = Paths.get("/usr/bin/expect");
> 
> We only need to check "expect" availability once, so we should move this check to a `@BeforeAll` static method. It's also more clear that this check is a precondition, and not part of the actual test. Applies to the other locations, but primarily the other parameterized tests.

Good point. Modified to use `@BeforeAll`. For `ModuleSelectionTest`, one of the test is not using `expect`, so I left it as it is. In addition to that, I removed the `@requires` condition to allow that test to run on windows.

> test/jdk/java/io/Console/ModuleSelectionTest.java line 75:
> 
>> 73:     @ParameterizedTest
>> 74:     @MethodSource("options")
>> 75:     void testWithExpect(String opts, String expected) throws Exception {
> 
> I think it would be more clear if these tests were renamed to `expectConsoleTest` and `noConsoleTest` or something along those lines.

Yeah, using `expect` command with junit's expect is confusing ?. Just renamed those methods using TTY/NonTTY, as"expect/noConsoleTest" reads somewhat odd as it includes the expected results in the test name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2205749625
PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2205753058

From sherman at openjdk.org  Mon Jul 14 20:40:39 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 14 Jul 2025 20:40:39 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v2]
In-Reply-To: <AZoyQaqBTkKTCt1R05DWBsFQXyYJJ87VoEn4djB8JfM=.2afebbe4-23fc-42e7-b4d1-ab1ab62fcb8d@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <9h1T1edYRoTT3v5CPkY9DN9Lq0bSnDoU8VtK2xn4sIA=.9b57eb79-b59e-4b59-a2ed-94b68735c04f@github.com>
 <AZoyQaqBTkKTCt1R05DWBsFQXyYJJ87VoEn4djB8JfM=.2afebbe4-23fc-42e7-b4d1-ab1ab62fcb8d@github.com>
Message-ID: <NsQ2d3VOrQtdAfPVmnfDrrz1LOqnPPy4uflMRCbCrIg=.2e14a2be-79fc-4e47-91b9-a0afa38322d6@github.com>

On Mon, 14 Jul 2025 18:10:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Looks good. Thanks for adding case folding support which is long overdue ? Since this is adding a new support for casefolding for character class ranges, I think CSR and a release note should be considered.

Thanks for the review. Arguably, the change I made years ago to support Level 1 + RL2.1/2 already implies that character class ranges should conform to RL1.5 ? just like other constructs (back-ref, slice, single and property) So it might be reasonable to categorize this as "just" a pure bug fix.

That said, it is a behavioral change, and I?m happy to go through the CSR and release note process if strongly preferred. ?

My initial thought was to defer the CSR until we fully switch to a case-folding-mapping?based implementation (replacing the current toUpperCase/toLowerCase logic), at which point we could also update the javadoc to explicitly document the behavior of each construct, as RL1.5 recommends/suggests.

But if we prefer to align all of that now with this fix, I?m fine doing it together.

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

PR Comment: https://git.openjdk.org/jdk/pull/26285#issuecomment-3070905666

From jlu at openjdk.org  Mon Jul 14 20:53:40 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 14 Jul 2025 20:53:40 GMT
Subject: RFR: 8361972: Clarify the condition of System.console() about
 standard input/output
In-Reply-To: <bskq681GA51Af9bhRGSKfTL4RLtvLw7QlWqo2_v5pZ4=.f7f5bb9f-6ff2-4533-b5fc-57667264ca54@github.com>
References: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
 <JLbbLxKm-RKiYkrnRpuPKEczGfcUayNftwBAWHydwZQ=.b9d6c1ec-99a4-49dd-a665-83be8c4bb1bf@github.com>
 <bskq681GA51Af9bhRGSKfTL4RLtvLw7QlWqo2_v5pZ4=.f7f5bb9f-6ff2-4533-b5fc-57667264ca54@github.com>
Message-ID: <cMRCppUcuiSprrL7kI-t2irb2TwnG6JJ8i0sbiXJWGE=.1d3f279e-df8b-47ee-aad8-fbfa904a6b98@github.com>

On Mon, 14 Jul 2025 19:38:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 49:
>> 
>>> 47:  * was launched.  If the virtual machine is started automatically, for
>>> 48:  * example by a background job scheduler, or if one or both of the
>>> 49:  * standard input or output has been redirected, then it may not have a
>> 
>> If we are claiming that `System.console()` should **only** return a "Console instance only when both standard input and output are connected to a terminal." then is the _may_ wording not restrictive enough? Or is that nuance negligible?
>
> Intention here is that, we do want to restirct to not return JLine based Console when either/both of stdin/out is redirected, I think we would not want to restrict them as the spec. For example, `System.console()` in jshell returns non-null, even if the remote JVM is not-attached to a terminal. I will describe this sublety in the CSR

OK, I see your point. It is a hint as to what the behavior of this implementation does, but not enforced in the specification by any means as indicated by the _may_ wording. Nit: if that is the case, then shouldn't there technically be minimal compatibility risk in the CSR, since nothing is being "enforced" specification wise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26299#discussion_r2205797490

From jlu at openjdk.org  Mon Jul 14 21:02:39 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 14 Jul 2025 21:02:39 GMT
Subject: RFR: 8361972: Clarify the condition of System.console() about
 standard input/output
In-Reply-To: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
References: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
Message-ID: <sKL_UHmzbiD_x6fg5zV38_txopTyYtrTxnl9TZ6z_MQ=.2036fac0-c1ba-4b4a-ae28-55247391d342@github.com>

On Mon, 14 Jul 2025 17:15:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This accompanies the fix for [JDK-8361613](https://bugs.openjdk.org/browse/JDK-8361613), which restricts `System.console()` to return a `Console` instance only when both standard input and output are connected to a terminal. The change here is solely a specification clarification and tightening of the `java.io.Console` javadoc to reflect this behavior. We are separating the spec clarification because the fix itself may be backported to prior LTS releases without requiring a Maintenance Review process.

src/java.base/share/classes/java/io/Console.java line 47:

> 45:  * output streams then its console will exist and will typically be
> 46:  * connected to the keyboard and display from which the virtual machine
> 47:  * was launched.  If the virtual machine is started automatically, for

I think it might read easier if we reword the structure of the sentence to make it more concise.

E.g.

> The virtual machine may not have a console if started automatically, (e.g., by a background scheduler) or if either the standard input or output has been redirected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26299#discussion_r2205817651

From igraves at openjdk.org  Mon Jul 14 21:43:58 2025
From: igraves at openjdk.org (Ian Graves)
Date: Mon, 14 Jul 2025 21:43:58 GMT
Subject: RFR: 8358768: [vectorapi] Make VectorOperators.SUADD an
 Associative [v4]
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: <O67Y19Stozc98wx_PhjkjLhdpCDPkMopKsyMCvpcc30=.98af4320-04da-49b4-ad4c-eaf849fec957@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:

  Condensing test data

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26099/files
  - new: https://git.openjdk.org/jdk/pull/26099/files/8cfc55ee..c88f20ef

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

  Stats: 338 lines in 21 files changed: 21 ins; 253 del; 64 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 psandoz at openjdk.org  Mon Jul 14 22:02:41 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 14 Jul 2025 22:02:41 GMT
Subject: RFR: 8358768: [vectorapi] Make VectorOperators.SUADD an
 Associative [v4]
In-Reply-To: <O67Y19Stozc98wx_PhjkjLhdpCDPkMopKsyMCvpcc30=.98af4320-04da-49b4-ad4c-eaf849fec957@github.com>
References: <EZ4_14iY5_yTqfv3ZYpfoVRQK4jjxPtpafox1FQjq5M=.046cbb01-5fe5-4cf9-a468-ed22f0b4acda@github.com>
 <O67Y19Stozc98wx_PhjkjLhdpCDPkMopKsyMCvpcc30=.98af4320-04da-49b4-ad4c-eaf849fec957@github.com>
Message-ID: <VxcM3Z3zP65pCjXwXgDg6FM_sde-P5tvwK0vjR9RwiI=.b5c02f12-836e-4959-8632-c1d8847778ac@github.com>

On Mon, 14 Jul 2025 21:43: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:
> 
>   Condensing test data

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26099#pullrequestreview-3017948964

From naoto at openjdk.org  Mon Jul 14 22:39:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 14 Jul 2025 22:39:56 GMT
Subject: RFR: 8361972: Clarify the condition of System.console() about
 standard input/output [v2]
In-Reply-To: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
References: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
Message-ID: <TKnCmtTeM0-f1yunDtO8zRno4ZbVWxhiWN0kagttFns=.3f8e4e55-84f4-4eee-924a-e04e46485c12@github.com>

> This accompanies the fix for [JDK-8361613](https://bugs.openjdk.org/browse/JDK-8361613), which restricts `System.console()` to return a `Console` instance only when both standard input and output are connected to a terminal. The change here is solely a specification clarification and tightening of the `java.io.Console` javadoc to reflect this behavior. We are separating the spec clarification because the fix itself may be backported to prior LTS releases without requiring a Maintenance Review process.

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

  Wording modification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26299/files
  - new: https://git.openjdk.org/jdk/pull/26299/files/4db1950e..e2a64c95

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

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

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

From asemenyuk at openjdk.org  Mon Jul 14 22:53:47 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 14 Jul 2025 22:53:47 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v2]
In-Reply-To: <YugxvKu8OSSx0JLzZoEutLfGJHpHCYtSIEeV5mHyD9Q=.b12b2e72-6ac3-4346-9be0-04c72404f418@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>
 <YugxvKu8OSSx0JLzZoEutLfGJHpHCYtSIEeV5mHyD9Q=.b12b2e72-6ac3-4346-9be0-04c72404f418@github.com>
Message-ID: <jf-Sd2JRij8ob4wirvmFVulyPmAs_pRLpr_-NzE_i5U=.6d2be671-b44b-43cb-9d50-6e481b816d06@github.com>

On Wed, 9 Jul 2025 01:32:38 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> RUNTIME_PACKAGE_LAYOUT points to "Contents/Home". Bundle is "Contents/Home", "Contents/MacOS" and "Contents/Info.plist".

Right, so `RUNTIME_PACKAGE_LAYOUT` points to a bundle just like [ApplicationLayoutUtils.MAC_APPLICATION_LAYOUT](https://github.com/openjdk/jdk/blob/5cf672e7784b9a9a82f29977a072b162cc240fd1/src/jdk.jpackage/share/classes/jdk/jpackage/internal/ApplicationLayoutUtils.java#L43) points to a bundle too. If you need "Contents/MacOS" in the `RUNTIME_PACKAGE_LAYOUT`, add it to it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2205951133

From asemenyuk at openjdk.org  Mon Jul 14 22:57:46 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 14 Jul 2025 22:57:46 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v2]
In-Reply-To: <YugxvKu8OSSx0JLzZoEutLfGJHpHCYtSIEeV5mHyD9Q=.b12b2e72-6ac3-4346-9be0-04c72404f418@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>
 <YugxvKu8OSSx0JLzZoEutLfGJHpHCYtSIEeV5mHyD9Q=.b12b2e72-6ac3-4346-9be0-04c72404f418@github.com>
Message-ID: <GJJJ8fXkO_z3--KI0_5UnUTl13wW4fs-sIRNh7gYfbA=.8773fbd5-77ac-43f4-99ad-ec19f0fe5ec5@github.com>

On Thu, 10 Jul 2025 01:30:19 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> runtimeImageDir is a value of --runtime-image in case of runtime installer.

This duplicates `Package.predefinedAppImage()` function. In case of runtime packaging, the "predefined app image" should be the value of `--runtime-image`. Can you evaluate if you can use `Package.predefinedAppImage()` function instead of adding a new one?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2205954659

From jlu at openjdk.org  Mon Jul 14 22:58:39 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 14 Jul 2025 22:58:39 GMT
Subject: RFR: 8361972: Clarify the condition of System.console() about
 standard input/output [v2]
In-Reply-To: <TKnCmtTeM0-f1yunDtO8zRno4ZbVWxhiWN0kagttFns=.3f8e4e55-84f4-4eee-924a-e04e46485c12@github.com>
References: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
 <TKnCmtTeM0-f1yunDtO8zRno4ZbVWxhiWN0kagttFns=.3f8e4e55-84f4-4eee-924a-e04e46485c12@github.com>
Message-ID: <pJtyvcqjuO5Lx57RgFT35-lbStHBZmC9a-8RAoNNPCQ=.7099e40a-fd05-4f6a-97da-d2c98e0de47b@github.com>

On Mon, 14 Jul 2025 22:39:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This accompanies the fix for [JDK-8361613](https://bugs.openjdk.org/browse/JDK-8361613), which restricts `System.console()` to return a `Console` instance only when both standard input and output are connected to a terminal. The change here is solely a specification clarification and tightening of the `java.io.Console` javadoc to reflect this behavior. We are separating the spec clarification because the fix itself may be backported to prior LTS releases without requiring a Maintenance Review process.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wording modification

New wording lgtm.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26299#pullrequestreview-3018023504

From naoto at openjdk.org  Mon Jul 14 23:07:38 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 14 Jul 2025 23:07:38 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v3]
In-Reply-To: <FMXB0H9GZvga0ffJAmCnSKL6uTOaDOc3JS2Ze9Ph6Xg=.bcaf2b51-7a0f-4bc2-8c11-d613dda03116@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <FMXB0H9GZvga0ffJAmCnSKL6uTOaDOc3JS2Ze9Ph6Xg=.bcaf2b51-7a0f-4bc2-8c11-d613dda03116@github.com>
Message-ID: <8xXhxlxCAZZxhZ4fzXjOY797duMUpixmRB6mtS_pPUg=.c848f4b9-59e6-4f5e-a6c7-4254b2ee253c@github.com>

On Mon, 14 Jul 2025 20:13:06 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>> 
>> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
>> 
>> **RL1.5 states**: 
>> 
>> To meet this requirement, an implementation that supports case-sensitive matching should
>> 
>>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>>     2. Specify which character properties or constructs are closed under the matching.
>> 
>> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
>> 
>>     1. back-refs
>>     2. string slices (sequences)
>>     3. single character,
>>     4. character families (Unicode Properties ...), and
>>     5. character class ranges
>> 
>> **Note**: Single characters and families may appear independently or within a character class.
>> 
>> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
>> 
>> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
>> 
>> For example:
>> 
>> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
>> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
>> 
>> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
>> 
>> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
>> 
>> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
>> vs
>> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
>> 
>> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
>> 
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{0...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to address the review comments

Changes look good to me. 
As to the CSR, it seems ok without it if this is a pure bug fix.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26285#pullrequestreview-3018037051

From asemenyuk at openjdk.org  Mon Jul 14 23:11:43 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 14 Jul 2025 23:11:43 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v2]
In-Reply-To: <YugxvKu8OSSx0JLzZoEutLfGJHpHCYtSIEeV5mHyD9Q=.b12b2e72-6ac3-4346-9be0-04c72404f418@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>
 <YugxvKu8OSSx0JLzZoEutLfGJHpHCYtSIEeV5mHyD9Q=.b12b2e72-6ac3-4346-9be0-04c72404f418@github.com>
Message-ID: <hUH_cVzi0fFwFfrhHjhHQ31_i9hmWZVh-Z9iDslfXzE=.3190be50-b48f-4d9a-9131-5dfa7bb98563@github.com>

On Wed, 9 Jul 2025 00:31:39 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

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

If you need a property of a `MacApplication` instance, create it and get the property.
`MacApplicationBuilder.validatedBundleIdentifier()` function is internal and should not be used outside of `MacApplicationBuilder`.

It is OK to call `MacApplicationBuilder.create()` multiple times. See how this is done in [LinuxPackageBuilder.java](https://github.com/openjdk/jdk/blob/f36147b3263662229e9a0ec712b9748711d2d85d/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBuilder.java#L48)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2205967869

From asemenyuk at openjdk.org  Mon Jul 14 23:14:44 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 14 Jul 2025 23:14:44 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v2]
In-Reply-To: <YugxvKu8OSSx0JLzZoEutLfGJHpHCYtSIEeV5mHyD9Q=.b12b2e72-6ac3-4346-9be0-04c72404f418@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>
 <YugxvKu8OSSx0JLzZoEutLfGJHpHCYtSIEeV5mHyD9Q=.b12b2e72-6ac3-4346-9be0-04c72404f418@github.com>
Message-ID: <iIetjUKkamapZaY32V8TqzNCKLXF2j36kx2zMxYGyUc=.fca77dd6-f33f-48c5-bdff-09a5cb19965c@github.com>

On Thu, 10 Jul 2025 00:27:55 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

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

Please file a bug to address the hardcoded value of the `CFBundleDevelopmentRegion`. We may decide later what to do with it: change it to `en-US`, remove it, or add a new cli option to set it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2205970959

From asemenyuk at openjdk.org  Mon Jul 14 23:18:46 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 14 Jul 2025 23:18:46 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v4]
In-Reply-To: <Rqjl9y0pqY-kiAV0BA9ik-vBIahRO5jn7Wg4QoMYn0s=.7a39146b-3e54-4595-b7c8-0d09e9904d88@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>
 <Rqjl9y0pqY-kiAV0BA9ik-vBIahRO5jn7Wg4QoMYn0s=.7a39146b-3e54-4595-b7c8-0d09e9904d88@github.com>
Message-ID: <XMtc8TtESzI62lRz8QIwj_Ry-S1uYQbe1bm-bWFy3ug=.30fd8e4d-2484-4596-9478-74e8c10e19d5@github.com>

On Wed, 9 Jul 2025 01:27:32 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

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

Try,


builder.task(MacCopyAppImageTaskID.SIGN_RUNTIME_BUNDLE)
                            .appImageAction(MacPackagingPipeline::signApplicationBundle)
                            .add();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2205975190

From asemenyuk at openjdk.org  Mon Jul 14 23:28:47 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 14 Jul 2025 23:28:47 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v4]
In-Reply-To: <2yrhjotF9K5jqUS7jYObkTxgvNmP7-fKlfitnJt7F4I=.0597991e-7474-400e-9d84-7f65424d47c8@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <2yrhjotF9K5jqUS7jYObkTxgvNmP7-fKlfitnJt7F4I=.0597991e-7474-400e-9d84-7f65424d47c8@github.com>
Message-ID: <LKaTQFnvBSfVGI3bzRhI3FhvwelWBOhOONZOnSh4p6c=.f4827965-0db6-4ac6-8649-8daf7e684795@github.com>

On Fri, 11 Jul 2025 16:44:05 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 [v3]

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacFromParams.java line 221:

> 219:         return IOUtils.exists(path1)
> 220:                 && path1.toFile().list() != null
> 221:                 && path1.toFile().list().length > 0

This will result in reading the directory contents twice.
Do this instead:

Optional.ofNullable(path1.toFile().list()).map(list -> list.length > 0).orElse(false)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2205983779

From asemenyuk at openjdk.org  Mon Jul 14 23:32:47 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 14 Jul 2025 23:32:47 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v4]
In-Reply-To: <2yrhjotF9K5jqUS7jYObkTxgvNmP7-fKlfitnJt7F4I=.0597991e-7474-400e-9d84-7f65424d47c8@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <2yrhjotF9K5jqUS7jYObkTxgvNmP7-fKlfitnJt7F4I=.0597991e-7474-400e-9d84-7f65424d47c8@github.com>
Message-ID: <nHEwYtl3w5eTDHZsyeY1qwWRiNlwqqjVOLw3yUyhtXM=.bc007f36-1b79-4b0c-bac8-6b543a7f646a@github.com>

On Fri, 11 Jul 2025 16:44:05 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 [v3]

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacFromParams.java line 223:

> 221:                 && path1.toFile().list().length > 0
> 222:                 && IOUtils.exists(path2)
> 223:                 && IOUtils.exists(path3);

Please don't use `IOUtils.exists()` and other redundant wrappers over the `Files` class in the new code. Use `Files.exists()` instead.

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacFromParams.java line 238:

> 236:             return false;
> 237:         } catch (IOException ex) {
> 238:             throw new RuntimeException(ex);

Should be either

ExceptionBox.rethrowUnchecked(ex);


or

throw new UncheckedIOException(ex);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2205986042
PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2205987403

From almatvee at openjdk.org  Mon Jul 14 23:36:49 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 14 Jul 2025 23:36:49 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v4]
In-Reply-To: <XMtc8TtESzI62lRz8QIwj_Ry-S1uYQbe1bm-bWFy3ug=.30fd8e4d-2484-4596-9478-74e8c10e19d5@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>
 <Rqjl9y0pqY-kiAV0BA9ik-vBIahRO5jn7Wg4QoMYn0s=.7a39146b-3e54-4595-b7c8-0d09e9904d88@github.com>
 <XMtc8TtESzI62lRz8QIwj_Ry-S1uYQbe1bm-bWFy3ug=.30fd8e4d-2484-4596-9478-74e8c10e19d5@github.com>
Message-ID: <RIBt4nBLrafRvEf1RMOYnlK_gXuqz9XAZ9XEv9knBQQ=.1c516030-9e0f-426e-8bdf-fe466231ac61@github.com>

On Mon, 14 Jul 2025 23:16:14 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> 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`.
>
> Try,
> 
> 
> builder.task(MacCopyAppImageTaskID.SIGN_RUNTIME_BUNDLE)
>                             .appImageAction(MacPackagingPipeline::signApplicationBundle)
>                             .add();

Getting following exception at runtime with code above:

java.lang.ClassCastException: class com.sun.proxy.jdk.proxy1.$Proxy0 cannot be cast to class jdk.jpackage.internal.MacApplicationLayout (com.sun.proxy.jdk.proxy1.$Proxy0 is in module jdk.proxy1 of loader 'app'; jdk.jpackage.internal.MacApplicationLayout is in module jdk.jpackage of loader 'app')

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2205990108

From liach at openjdk.org  Mon Jul 14 23:37:42 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Jul 2025 23:37:42 GMT
Subject: RFR: 8361909: ConstantPoolBuilder::loadableConstantEntry and
 constantValueEntry should throw NPE
In-Reply-To: <jQUgadsvemj8_Wu1vIidHAde3v3llybuTr6vxdneP-4=.82b28b63-27e6-46c2-8f62-c0aaf85b3c02@github.com>
References: <jQUgadsvemj8_Wu1vIidHAde3v3llybuTr6vxdneP-4=.82b28b63-27e6-46c2-8f62-c0aaf85b3c02@github.com>
Message-ID: <QUc5Hj3dau8HsWebnENksaA11kuPmiYjDEO_Rh2sdBA=.807e1cc9-5935-42fa-8a96-421953eed1b2@github.com>

On Thu, 10 Jul 2025 22:32:45 GMT, Chen Liang <liach at openjdk.org> wrote:

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

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26257#issuecomment-3071336522

From liach at openjdk.org  Mon Jul 14 23:37:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Jul 2025 23:37:43 GMT
Subject: Integrated: 8361909: ConstantPoolBuilder::loadableConstantEntry and
 constantValueEntry should throw NPE
In-Reply-To: <jQUgadsvemj8_Wu1vIidHAde3v3llybuTr6vxdneP-4=.82b28b63-27e6-46c2-8f62-c0aaf85b3c02@github.com>
References: <jQUgadsvemj8_Wu1vIidHAde3v3llybuTr6vxdneP-4=.82b28b63-27e6-46c2-8f62-c0aaf85b3c02@github.com>
Message-ID: <WDLWCtD8Bb4NHqU18UQCGIyyA5MMyv8D_EivvA7tIQs=.da336c76-6603-4af1-b06c-bd65a1747377@github.com>

On Thu, 10 Jul 2025 22:32:45 GMT, Chen Liang <liach at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 0acd065b
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0acd065bf5a75090b84c28b28856a62d86c52791
Stats:     11 lines in 2 files changed: 8 ins; 0 del; 3 mod

8361909: ConstantPoolBuilder::loadableConstantEntry and constantValueEntry should throw NPE

Reviewed-by: asotona

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

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

From sherman at openjdk.org  Tue Jul 15 00:32:22 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 15 Jul 2025 00:32:22 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v4]
In-Reply-To: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
Message-ID: <fILvArbLjSHximeExPfy_DQcWKxiNIriOhKo2NVPZ6o=.522d4980-3496-4a87-a6e7-6d62e03b1104@github.com>

> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
> 
> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
> 
> **RL1.5 states**: 
> 
> To meet this requirement, an implementation that supports case-sensitive matching should
> 
>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>     2. Specify which character properties or constructs are closed under the matching.
> 
> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
> 
>     1. back-refs
>     2. string slices (sequences)
>     3. single character,
>     4. character families (Unicode Properties ...), and
>     5. character class ranges
> 
> **Note**: Single characters and families may appear independently or within a character class.
> 
> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
> 
> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
> 
> For example:
> 
> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
> 
> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
> 
> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
> 
> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
> vs
> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
> 
> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
> 
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/**_i_** ? "true\n" : "false\n"'. => **_true_**
> 
> The root issue is that the ran...

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

  update and add more test cases, and fix a test failure

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26285/files
  - new: https://git.openjdk.org/jdk/pull/26285/files/e18d2668..c2afc42c

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

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

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

From darcy at openjdk.org  Tue Jul 15 01:15:20 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 15 Jul 2025 01:15:20 GMT
Subject: RFR: 8362207: Add more test cases for possible double-rounding in fma
Message-ID: <vo6ZFgc9-NCGHZcd5ftuMzaH2aswSB6rkclyJknn7BI=.45bf8bdf-5d0f-4751-b694-a294f8820b35@github.com>

>From discussions related to IEEE 754, a few explicit test cases were identified where plausible, but incorrect, implementations of fma using higher precision. These test cases are useful to include in the regression tests of the float-precision and Float16-precision fused multiple add methods.

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

Commit messages:
 - JDK-8362207: Add more test cases for possible double-rounding in fma

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

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

From asemenyuk at openjdk.org  Tue Jul 15 01:32:53 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 15 Jul 2025 01:32:53 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v4]
In-Reply-To: <RIBt4nBLrafRvEf1RMOYnlK_gXuqz9XAZ9XEv9knBQQ=.1c516030-9e0f-426e-8bdf-fe466231ac61@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>
 <Rqjl9y0pqY-kiAV0BA9ik-vBIahRO5jn7Wg4QoMYn0s=.7a39146b-3e54-4595-b7c8-0d09e9904d88@github.com>
 <XMtc8TtESzI62lRz8QIwj_Ry-S1uYQbe1bm-bWFy3ug=.30fd8e4d-2484-4596-9478-74e8c10e19d5@github.com>
 <RIBt4nBLrafRvEf1RMOYnlK_gXuqz9XAZ9XEv9knBQQ=.1c516030-9e0f-426e-8bdf-fe466231ac61@github.com>
Message-ID: <zyMhnDNFA2fBmFNLw8YQ13CmfgTqUbJkLWywrUxbOHM=.7c4dd792-7ff9-4397-8f4a-1eb00f64f939@github.com>

On Mon, 14 Jul 2025 23:33:36 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Try,
>> 
>> 
>> builder.task(MacCopyAppImageTaskID.SIGN_RUNTIME_BUNDLE)
>>                             .appImageAction(MacPackagingPipeline::signApplicationBundle)
>>                             .add();
>
> Getting following exception at runtime with code above:
> 
> java.lang.ClassCastException: class com.sun.proxy.jdk.proxy1.$Proxy0 cannot be cast to class jdk.jpackage.internal.MacApplicationLayout (com.sun.proxy.jdk.proxy1.$Proxy0 is in module jdk.proxy1 of loader 'app'; jdk.jpackage.internal.MacApplicationLayout is in module jdk.jpackage of loader 'app')

What is the full stack trace?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2206097560

From almatvee at openjdk.org  Tue Jul 15 01:47:52 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 15 Jul 2025 01:47:52 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v4]
In-Reply-To: <zyMhnDNFA2fBmFNLw8YQ13CmfgTqUbJkLWywrUxbOHM=.7c4dd792-7ff9-4397-8f4a-1eb00f64f939@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>
 <Rqjl9y0pqY-kiAV0BA9ik-vBIahRO5jn7Wg4QoMYn0s=.7a39146b-3e54-4595-b7c8-0d09e9904d88@github.com>
 <XMtc8TtESzI62lRz8QIwj_Ry-S1uYQbe1bm-bWFy3ug=.30fd8e4d-2484-4596-9478-74e8c10e19d5@github.com>
 <RIBt4nBLrafRvEf1RMOYnlK_gXuqz9XAZ9XEv9knBQQ=.1c516030-9e0f-426e-8bdf-fe466231ac61@github.com>
 <zyMhnDNFA2fBmFNLw8YQ13CmfgTqUbJkLWywrUxbOHM=.7c4dd792-7ff9-4397-8f4a-1eb00f64f939@github.com>
Message-ID: <qf6nbCdHaeeu4X-t4B2JBRngl6ttgZVuoO5d1wohnJU=.e00038d7-03c5-462f-be2d-2ef35d961083@github.com>

On Tue, 15 Jul 2025 01:29:44 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Getting following exception at runtime with code above:
>> 
>> java.lang.ClassCastException: class com.sun.proxy.jdk.proxy1.$Proxy0 cannot be cast to class jdk.jpackage.internal.MacApplicationLayout (com.sun.proxy.jdk.proxy1.$Proxy0 is in module jdk.proxy1 of loader 'app'; jdk.jpackage.internal.MacApplicationLayout is in module jdk.jpackage of loader 'app')
>
> What is the full stack trace?

It does not print call stack. Not sure why. Once I figure it I will update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2206110106

From asemenyuk at openjdk.org  Tue Jul 15 02:18:56 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 15 Jul 2025 02:18:56 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v4]
In-Reply-To: <qf6nbCdHaeeu4X-t4B2JBRngl6ttgZVuoO5d1wohnJU=.e00038d7-03c5-462f-be2d-2ef35d961083@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>
 <Rqjl9y0pqY-kiAV0BA9ik-vBIahRO5jn7Wg4QoMYn0s=.7a39146b-3e54-4595-b7c8-0d09e9904d88@github.com>
 <XMtc8TtESzI62lRz8QIwj_Ry-S1uYQbe1bm-bWFy3ug=.30fd8e4d-2484-4596-9478-74e8c10e19d5@github.com>
 <RIBt4nBLrafRvEf1RMOYnlK_gXuqz9XAZ9XEv9knBQQ=.1c516030-9e0f-426e-8bdf-fe466231ac61@github.com>
 <zyMhnDNFA2fBmFNLw8YQ13CmfgTqUbJkLWywrUxbOHM=.7c4dd792-7ff9-4397-8f4a-1eb00f64f939@github.com>
 <qf6nbCdHaeeu4X-t4B2JBRngl6ttgZVuoO5d1wohnJU=.e00038d7-03c5-462f-be2d-2ef35d961083@github.com>
Message-ID: <YzJ8yWN3aOGiV3QJ9FECKdWJQJKL3XvWl1FQylq_cSM=.65e4c40a-7293-4c3a-8c69-1ad69beeeea0@github.com>

On Tue, 15 Jul 2025 01:45:11 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> What is the full stack trace?
>
> It does not print call stack. Not sure why. Once I figure it I will update.

Maybe run jpackage with `--verbose` flag?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2206135319

From almatvee at openjdk.org  Tue Jul 15 02:18:56 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 15 Jul 2025 02:18:56 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v4]
In-Reply-To: <YzJ8yWN3aOGiV3QJ9FECKdWJQJKL3XvWl1FQylq_cSM=.65e4c40a-7293-4c3a-8c69-1ad69beeeea0@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>
 <Rqjl9y0pqY-kiAV0BA9ik-vBIahRO5jn7Wg4QoMYn0s=.7a39146b-3e54-4595-b7c8-0d09e9904d88@github.com>
 <XMtc8TtESzI62lRz8QIwj_Ry-S1uYQbe1bm-bWFy3ug=.30fd8e4d-2484-4596-9478-74e8c10e19d5@github.com>
 <RIBt4nBLrafRvEf1RMOYnlK_gXuqz9XAZ9XEv9knBQQ=.1c516030-9e0f-426e-8bdf-fe466231ac61@github.com>
 <zyMhnDNFA2fBmFNLw8YQ13CmfgTqUbJkLWywrUxbOHM=.7c4dd792-7ff9-4397-8f4a-1eb00f64f939@github.com>
 <qf6nbCdHaeeu4X-t4B2JBRngl6ttgZVuoO5d1wohnJU=.e00038d7-03c5-462f-be2d-2ef35d961083@github.com>
 <YzJ8yWN3aOGiV3QJ9FECKdWJQJKL3XvWl1FQylq_cSM=.65e4c40a-7293-4c3a-8c69-1ad69beeeea0@github.com>
Message-ID: <5UAfUJRT3rIO5twWDl7kY37boUoh5bN4z20PBEoR-sw=.e3db1531-931c-4373-800a-81408da99de2@github.com>

On Tue, 15 Jul 2025 02:13:41 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> It does not print call stack. Not sure why. Once I figure it I will update.
>
> Maybe run jpackage with `--verbose` flag?

[19:14:45.620] jdk.jpackage.internal.model.PackagerException: java.lang.ClassCastException: class com.sun.proxy.jdk.proxy1.$Proxy0 cannot be cast to class jdk.jpackage.internal.MacApplicationLayout (com.sun.proxy.jdk.proxy1.$Proxy0 is in module jdk.proxy1 of loader 'app'; jdk.jpackage.internal.MacApplicationLayout is in module jdk.jpackage of loader 'app')
	at jdk.jpackage/jdk.jpackage.internal.PackagingPipeline.execute(PackagingPipeline.java:487)
	at jdk.jpackage/jdk.jpackage.internal.PackagingPipeline.execute(PackagingPipeline.java:68)
	at jdk.jpackage/jdk.jpackage.internal.PackagerBuilder.execute(PackagerBuilder.java:67)
	at jdk.jpackage/jdk.jpackage.internal.MacDmgPackager$Builder.execute(MacDmgPackager.java:81)
	at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:80)
	at jdk.jpackage/jdk.jpackage.internal.Arguments.executeBundler(Arguments.java:741)
	at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:702)
	at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:553)
	at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:93)
	at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:54)
Caused by: java.lang.ClassCastException: class com.sun.proxy.jdk.proxy1.$Proxy0 cannot be cast to class jdk.jpackage.internal.MacApplicationLayout (com.sun.proxy.jdk.proxy1.$Proxy0 is in module jdk.proxy1 of loader 'app'; jdk.jpackage.internal.MacApplicationLayout is in module jdk.jpackage of loader 'app')
	at jdk.jpackage/jdk.jpackage.internal.MacPackagingPipeline.signApplicationBundle(MacPackagingPipeline.java:367)
	at jdk.jpackage/jdk.jpackage.internal.PackagingPipeline$DefaultTaskContext.execute(PackagingPipeline.java:571)
	at jdk.jpackage/jdk.jpackage.internal.MacPackagingPipeline$TaskContextProxy.execute(MacPackagingPipeline.java:541)
	at jdk.jpackage/jdk.jpackage.internal.PackagingPipeline.lambda$createTask$0(PackagingPipeline.java:604)
	at jdk.jpackage/jdk.jpackage.internal.pipeline.TaskPipelineBuilder$SequentialWrapperTask.call(TaskPipelineBuilder.java:130)
	at jdk.jpackage/jdk.jpackage.internal.pipeline.TaskPipelineBuilder$SequentialWrapperTask.call(TaskPipelineBuilder.java:121)
	at jdk.jpackage/jdk.jpackage.internal.PackagingPipeline.execute(PackagingPipeline.java:480)
	... 9 more
java.lang.ClassCastException: class com.sun.proxy.jdk.proxy1.$Proxy0 cannot be cast to class jdk.jpackage.internal.MacApplicationLayout (com.sun.proxy.jdk.proxy1.$Proxy0 is in module jdk.proxy1 of loader 'app'; jdk.jpackage.internal.MacApplicationLayout is in module jdk.jpackage of loader 'app')

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2206137080

From asemenyuk at openjdk.org  Tue Jul 15 02:33:58 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 15 Jul 2025 02:33:58 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v4]
In-Reply-To: <5UAfUJRT3rIO5twWDl7kY37boUoh5bN4z20PBEoR-sw=.e3db1531-931c-4373-800a-81408da99de2@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>
 <Rqjl9y0pqY-kiAV0BA9ik-vBIahRO5jn7Wg4QoMYn0s=.7a39146b-3e54-4595-b7c8-0d09e9904d88@github.com>
 <XMtc8TtESzI62lRz8QIwj_Ry-S1uYQbe1bm-bWFy3ug=.30fd8e4d-2484-4596-9478-74e8c10e19d5@github.com>
 <RIBt4nBLrafRvEf1RMOYnlK_gXuqz9XAZ9XEv9knBQQ=.1c516030-9e0f-426e-8bdf-fe466231ac61@github.com>
 <zyMhnDNFA2fBmFNLw8YQ13CmfgTqUbJkLWywrUxbOHM=.7c4dd792-7ff9-4397-8f4a-1eb00f64f939@github.com>
 <qf6nbCdHaeeu4X-t4B2JBRngl6ttgZVuoO5d1wohnJU=.e00038d7-03c5-462f-be2d-2ef35d961083@github.com>
 <YzJ8yWN3aOGiV3QJ9FECKdWJQJKL3XvWl1FQylq_cSM=.65e4c40a-7293-4c3a-8c69-1ad69beeeea0@github.com>
 <5UAfUJRT3rIO5twWDl7kY37boUoh5bN4z20PBEoR-sw=.e3db1531-931c-4373-800a-81408da99de2@github.com>
Message-ID: <uRcsfxSIZZqqLhEmU4Pi2DBkLlMuzcOzf34ACGVT1B4=.9ef2af43-8c56-4e0b-a02d-46002db16de3@github.com>

On Tue, 15 Jul 2025 02:15:56 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Maybe run jpackage with `--verbose` flag?
>
> [19:14:45.620] jdk.jpackage.internal.model.PackagerException: java.lang.ClassCastException: class com.sun.proxy.jdk.proxy1.$Proxy0 cannot be cast to class jdk.jpackage.internal.MacApplicationLayout (com.sun.proxy.jdk.proxy1.$Proxy0 is in module jdk.proxy1 of loader 'app'; jdk.jpackage.internal.MacApplicationLayout is in module jdk.jpackage of loader 'app')
> 	at jdk.jpackage/jdk.jpackage.internal.PackagingPipeline.execute(PackagingPipeline.java:487)
> 	at jdk.jpackage/jdk.jpackage.internal.PackagingPipeline.execute(PackagingPipeline.java:68)
> 	at jdk.jpackage/jdk.jpackage.internal.PackagerBuilder.execute(PackagerBuilder.java:67)
> 	at jdk.jpackage/jdk.jpackage.internal.MacDmgPackager$Builder.execute(MacDmgPackager.java:81)
> 	at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:80)
> 	at jdk.jpackage/jdk.jpackage.internal.Arguments.executeBundler(Arguments.java:741)
> 	at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:702)
> 	at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:553)
> 	at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:93)
> 	at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:54)
> Caused by: java.lang.ClassCastException: class com.sun.proxy.jdk.proxy1.$Proxy0 cannot be cast to class jdk.jpackage.internal.MacApplicationLayout (com.sun.proxy.jdk.proxy1.$Proxy0 is in module jdk.proxy1 of loader 'app'; jdk.jpackage.internal.MacApplicationLayout is in module jdk.jpackage of loader 'app')
> 	at jdk.jpackage/jdk.jpackage.internal.MacPackagingPipeline.signApplicationBundle(MacPackagingPipeline.java:367)
> 	at jdk.jpackage/jdk.jpackage.internal.PackagingPipeline$DefaultTaskContext.execute(PackagingPipeline.java:571)
> 	at jdk.jpackage/jdk.jpackage.internal.MacPackagingPipeline$TaskContextProxy.execute(MacPackagingPipeline.java:541)
> 	at jdk.jpackage/jdk.jpackage.internal.PackagingPipeline.lambda$createTask$0(PackagingPipeline.java:604)
> 	at jdk.jpackage/jdk.jpackage.internal.pipeline.TaskPipelineBuilder$SequentialWrapperTask.call(TaskPipelineBuilder.java:130)
> 	at jdk.jpackage/jdk.jpackage.internal.pipeline.TaskPipelineBuilder$SequentialWrapperTask.call(TaskPipelineBuilder.java:121)
> 	at jdk.jpackage/jdk.jpackage.internal.PackagingPipeline.execute(PackagingPipeline.java:480)
> 	... 9 more
> java.lang.ClassCastException: class com.sun.proxy.jdk.proxy1.$Proxy0 cannot be cast to class jdk.jpackage.internal.MacApplicationLayout (com.sun.proxy.jdk.proxy1.$Proxy0 is in module jdk.proxy1 of loader 'a...

Try to change the signature from

private static void signApplicationBundle(AppImageBuildEnv<MacApplication, MacApplicationLayout> env) throws IOException


to

private static void signApplicationBundle(AppImageBuildEnv<MacApplication, AppImageLayout> env) throws IOException


I guess if you change the signature or the original `sign()` from:

void sign(AppImageBuildEnv<MacApplication, MacApplicationLayout> env) throws IOException

to

void sign(AppImageBuildEnv<MacApplication, AppImageLayout> env) throws IOException

and use it instead of `signRuntimeBundle()` and `signApplicationBundle()` it will work too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2206154942

From rriggs at openjdk.org  Tue Jul 15 02:50:44 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 02:50:44 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v7]
In-Reply-To: <C3aAwHxenLIEswZqQg-pjqjWQWbyTHD-5yvAIpbTCUU=.4a1620c8-b794-427c-ba39-1c0133174847@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <C3aAwHxenLIEswZqQg-pjqjWQWbyTHD-5yvAIpbTCUU=.4a1620c8-b794-427c-ba39-1c0133174847@github.com>
Message-ID: <3rpHvyWtHhdZJs90s9eu7YIWmDX2kC7ycM9UptH0zxk=.8bd18955-a5cb-4ea8-8769-40209d2867f7@github.com>

On Fri, 11 Jul 2025 14:41:30 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:
> 
>   Linting of a few minor issues (nothing serious).
>   
>   * Linting of minor issues.
>   * Factored out the module existence test, it's only a performance heuristic and could (should?) be removed.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 148:

> 146:     /**
> 147:      * Returns the content of a resource node.
> 148:      *

It may be helpful to mention that the byte[] returned is a copy and on return the caller is the owner.
If/when we have immutable byte arrays, it would save allocation and copying to return a/the cached byte array.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 182:

> 180: 
> 181:     private static final class SharedImageReader extends BasicImageReader {
> 182:         // TODO: Should this be OPEN_FILES or openFiles (it's not constant).

All caps is good for final statics.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 204:

> 202:             super(imagePath, byteOrder);
> 203:             this.imageFileAttributes = Files.readAttributes(imagePath, BasicFileAttributes.class);
> 204:             // TODO (review note): Given there are ~30,000 nodes in the image, is setting an initial capacity a good idea?

Likely yes, saving multiple (12) re-sizing's before reaching the 30k occupancy.

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 at these offsets.

ok as is, its stable.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 348:

> 346:             }
> 347:             // Tests the implied module directory location "/modules/<module>" exists.
> 348:             ImageLocation loc = findLocation(name.substring(0, moduleEnd));

There might be an opportunity to save some string creation if some functions took a (string, start, end) parameters. It would need to ripple down through ImageStringsReader.hashCode and would make the code less readable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2205724093
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2205741054
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2205751547
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2205754037
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2205816781

From rriggs at openjdk.org  Tue Jul 15 02:50:45 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 02:50:45 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v7]
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: <WnMRreXok6ifshwsxt5-K9jvllvaGkgr4mAgP0X0sMU=.c01385b7-ae64-4fb9-8ee5-650bb2b75860@github.com>

On Tue, 1 Jul 2025 14:09:49 GMT, David Beaumont <duke at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Linting of a few minor issues (nothing serious).
>>   
>>   * Linting of minor issues.
>>   * Factored out the module existence test, it's only a performance heuristic and could (should?) be removed.
>
> 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.

It would be safer synchronized (especially `findNode`), since the nodes are shared and another thread might be accessing nodes.
But it might drop performance even in the non-contended case.
The alternative would be to use a ConcurrentHashMap but it has its own costs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2205768773

From darcy at openjdk.org  Tue Jul 15 04:33:40 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 15 Jul 2025 04:33:40 GMT
Subject: RFR: 8358540: Enhance MathUtils in view of FloatingDecimal
 enhancements [v3]
In-Reply-To: <_QoHLEtHuXdK1UOkNJR23Y1SuvclnmnugRXeWCLaKZc=.157d923c-dadd-49a7-bb2a-0939864777ce@github.com>
References: <QCVtBd071dMKhosNAlY09O1LpR6G9W4pnXpxPhwvTPA=.34e14f02-699d-49d7-8fc5-8090080aa106@github.com>
 <_QoHLEtHuXdK1UOkNJR23Y1SuvclnmnugRXeWCLaKZc=.157d923c-dadd-49a7-bb2a-0939864777ce@github.com>
Message-ID: <hfqPwbUv3nt7tDKYwcR7Mud7sNHpJJx4A39ebNt2oq0=.08606fc2-11c9-4c99-848e-3b9cc2c0cfc4@github.com>

On Mon, 30 Jun 2025 18:05:58 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Another step in enhancing floating-point <-> decimal conversions.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8358540
>  - Merge branch 'master' into 8358540
>  - 8358540: Enhance MathUtils in view of FloatingDecimal enhancements

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25641#pullrequestreview-3018510887

From duke at openjdk.org  Tue Jul 15 04:37:41 2025
From: duke at openjdk.org (Jason Mehrens)
Date: Tue, 15 Jul 2025 04:37:41 GMT
Subject: RFR: 8360575: java.util.Properties.list() methods trim each value
 to 37 characters in the listed output [v4]
In-Reply-To: <Jy3J4p5L8D4tpKN_-Ghr4VUdrVgnV3YLlKV00Dq-Z9w=.3bbc3090-f954-4526-95f5-0801eb5fd8b2@github.com>
References: <-dRew0C7Qw5REtfjrGiYdfY_bRcnBiUyKXok3lMF9ug=.57d81faf-4a4f-42a9-9238-539a5d0b5625@github.com>
 <Jy3J4p5L8D4tpKN_-Ghr4VUdrVgnV3YLlKV00Dq-Z9w=.3bbc3090-f954-4526-95f5-0801eb5fd8b2@github.com>
Message-ID: <rnVocZ7-E0gzZGhbtSVI-rr2fWbMtcCkYA2svMgl5Xc=.d124250d-7d05-45ff-98f9-b8f1fa564adf@github.com>

On Mon, 30 Jun 2025 06:01:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to clarify the current implementation of the `java.util.Properties.list(...)` methods?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8360575, the current implementation trims each value to a size of 37 when printing out the value. This behaviour isn't documented by these methods. The change in this PR adds an `@implNote` to make a mention of this current behaviour.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's review - no need to state the number of characters

If I understand the code, Properties::forEach doesn't walk up the default Properties. Properties::list walks the defaults.  To get the same keys you would have to use 
p.stringPropertyNames() and p.getProperty to fetch the value.

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

PR Comment: https://git.openjdk.org/jdk/pull/26018#issuecomment-3071861953

From egahlin at openjdk.org  Tue Jul 15 04:44:37 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 15 Jul 2025 04:44:37 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: <IZ_JQ401cUHXNC3iciH3To6fC6djlkNJg0jiq0nPraE=.2f0a6828-b754-4b84-9ce1-6c0a89a878ce@github.com>

On Wed, 9 Jul 2025 05:45:01 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of the change that prevents RandomAccessFile::readLine from emitting an event per character? This leads to unnecessary overhead, both with or without JFR enabled.
> 
> Testing: tier1 + tier2 +  jdk/jdk/jfr
> 
> Thanks
> Erik

It would be good if I could get a review from someone in core-libs before integrating. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/26210#issuecomment-3071888608

From jlahoda at openjdk.org  Tue Jul 15 06:29:38 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 15 Jul 2025 06:29:38 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v3]
In-Reply-To: <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
Message-ID: <dG7hgPRXXcJFrhc5DSjunpSZY_QbgDD1VGelBbvNFyo=.ef1a0ab5-4a61-4f7c-b3f1-2b1d00faeb1f@github.com>

On Mon, 14 Jul 2025 20:23:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
>> This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Looks good to me, although additional review from core libs might be desirable. Thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26273#pullrequestreview-3018857714

From alanb at openjdk.org  Tue Jul 15 06:30:43 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Jul 2025 06:30:43 GMT
Subject: RFR: 8361533: Apply java.io.Serial annotations in java.logging
In-Reply-To: <v6eZBS5s4FryKFbdnWdLb8lruzbR1GcfjQOn16PALwg=.5ab0f52d-5a90-4a96-a630-12086772f629@github.com>
References: <v6eZBS5s4FryKFbdnWdLb8lruzbR1GcfjQOn16PALwg=.5ab0f52d-5a90-4a96-a630-12086772f629@github.com>
Message-ID: <TkXXHEpzmcvSHn3n4YmK15Ak5o4dF40ibIEsrQjYX-w=.9513f6b0-634c-419d-b2df-f828380891dd@github.com>

On Wed, 9 Jul 2025 02:58:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

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

This is okay but just to point out that the SecurityManager feature is disabled completely since JDK 24 and LoggingPermission is deprecated for removal. So unlikely that new code will make use of this.

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

PR Comment: https://git.openjdk.org/jdk/pull/26208#issuecomment-3072179227

From alanb at openjdk.org  Tue Jul 15 06:39:42 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Jul 2025 06:39:42 GMT
Subject: RFR: 8361587: AssertionError in File.listFiles() when path is
 empty and -esa is enabled [v7]
In-Reply-To: <FtGSJdjUsUTLJqyl5t_5HLA4-ZR-I5M5u7kHyh1cu_M=.9aa4f0e2-a7d0-4ba6-8212-5d04c4b8cb4b@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <FtGSJdjUsUTLJqyl5t_5HLA4-ZR-I5M5u7kHyh1cu_M=.9aa4f0e2-a7d0-4ba6-8212-5d04c4b8cb4b@github.com>
Message-ID: <T0IaW5AqoO9Ay9wbQDFzrFck0md371Mk_ztoNtmbUZ0=.0866f1f0-e089-4a60-b1e9-c15498a14044@github.com>

On Sat, 12 Jul 2025 04:25:31 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: Improve previous commit

test/jdk/java/io/File/EmptyPath.java line 283:

> 281:             assertTrue(child.mkdirs());
> 282:             assertTrue(child.delete());
> 283:         }

The updated proposal is local to listFiles and doesn't change UnixFileSystem.resolve. Is the test update in sync with the latest change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26224#discussion_r2206535232

From shade at openjdk.org  Tue Jul 15 07:03:45 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Jul 2025 07:03:45 GMT
Subject: RFR: 8361959: [GCC static analyzer] java_props_md.c  leak of
 'temp'  variable is reported [v2]
In-Reply-To: <KnrbHzTaREYx4MM0mKtjtyprF7KPGv1fTRnyxFzttqQ=.e94cb087-cd46-434c-b3e6-256daf28c348@github.com>
References: <RqEj6H9uqBuW5LmTcU73gzQNAQnQLgUDWoqfaxIHLBw=.a9871b5c-c36c-433b-8091-8f0648669836@github.com>
 <KnrbHzTaREYx4MM0mKtjtyprF7KPGv1fTRnyxFzttqQ=.e94cb087-cd46-434c-b3e6-256daf28c348@github.com>
Message-ID: <iWZb7hUH6t17VuHqUOXPMrUbAN7WEvzGPkz5dSRCsgE=.1cc08ba6-cd25-42c2-8ca5-dac178af7b50@github.com>

On Sat, 12 Jul 2025 17:36:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The following is reported when building with the gcc static analyzer (-fanalyzer) :
>> 
>> 
>> /jdk/src/java.base/unix/native/libjava/java_props_md.c:244:17: warning: leak of 'temp' [CWE-401] [-Wanalyzer-malloc-leak]
>>   244 | return 0;
>> 
>> 
>> Seems we have to free temp in an early return.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   free before another early return

There is another instance a few lines below. See around where `free(encoding_variant);` happen.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26264#pullrequestreview-3018962127

From mbaesken at openjdk.org  Tue Jul 15 07:20:47 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 15 Jul 2025 07:20:47 GMT
Subject: RFR: 8361959: [GCC static analyzer] java_props_md.c  leak of
 'temp'  variable is reported [v2]
In-Reply-To: <KnrbHzTaREYx4MM0mKtjtyprF7KPGv1fTRnyxFzttqQ=.e94cb087-cd46-434c-b3e6-256daf28c348@github.com>
References: <RqEj6H9uqBuW5LmTcU73gzQNAQnQLgUDWoqfaxIHLBw=.a9871b5c-c36c-433b-8091-8f0648669836@github.com>
 <KnrbHzTaREYx4MM0mKtjtyprF7KPGv1fTRnyxFzttqQ=.e94cb087-cd46-434c-b3e6-256daf28c348@github.com>
Message-ID: <iie4HwPC_OC817NW_aWX4Fza-Z--d1i6ceaYkQvigOc=.b9edba10-95eb-4a5c-9d1e-be3cb3d47935@github.com>

On Sat, 12 Jul 2025 17:36:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The following is reported when building with the gcc static analyzer (-fanalyzer) :
>> 
>> 
>> /jdk/src/java.base/unix/native/libjava/java_props_md.c:244:17: warning: leak of 'temp' [CWE-401] [-Wanalyzer-malloc-leak]
>>   244 | return 0;
>> 
>> 
>> Seems we have to free temp in an early return.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   free before another early return

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/26264#issuecomment-3072355880

From mbaesken at openjdk.org  Tue Jul 15 07:20:48 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 15 Jul 2025 07:20:48 GMT
Subject: Integrated: 8361959: [GCC static analyzer] java_props_md.c  leak of
 'temp'  variable is reported
In-Reply-To: <RqEj6H9uqBuW5LmTcU73gzQNAQnQLgUDWoqfaxIHLBw=.a9871b5c-c36c-433b-8091-8f0648669836@github.com>
References: <RqEj6H9uqBuW5LmTcU73gzQNAQnQLgUDWoqfaxIHLBw=.a9871b5c-c36c-433b-8091-8f0648669836@github.com>
Message-ID: <GPOIiqTK00IvxfLCIq_v_7f1oI0HUD-T1AedjfM1Qv0=.7e0b1aba-f4b1-49f0-9322-95acae448e2e@github.com>

On Fri, 11 Jul 2025 12:45:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The following is reported when building with the gcc static analyzer (-fanalyzer) :
> 
> 
> /jdk/src/java.base/unix/native/libjava/java_props_md.c:244:17: warning: leak of 'temp' [CWE-401] [-Wanalyzer-malloc-leak]
>   244 | return 0;
> 
> 
> Seems we have to free temp in an early return.

This pull request has now been integrated.

Changeset: bf225c20
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bf225c201f00f3a478b51c3cf045759b66899684
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8361959: [GCC static analyzer] java_props_md.c  leak of 'temp'  variable is reported

Reviewed-by: shade, kbarrett, rriggs

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

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

From duke at openjdk.org  Tue Jul 15 09:39:19 2025
From: duke at openjdk.org (cagliostro92)
Date: Tue, 15 Jul 2025 09:39:19 GMT
Subject: RFR: 8358530: enhanced Properties#list javadoc
Message-ID: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>

Trivial PR to enhance Javadoc for the `Properties#list` method, which has cost me some debugging time.

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

Commit messages:
 - 8358530: adds warnings against non-String values in Properties class documentation

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

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

From jlu at openjdk.org  Tue Jul 15 09:39:20 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 15 Jul 2025 09:39:20 GMT
Subject: RFR: 8358530: enhanced Properties#list javadoc
In-Reply-To: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
References: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
Message-ID: <8NuDR-76UsKGJz8ZoZS7bVEXrNHnchfy21O3UG2Kg1k=.6dad1ac6-2895-4acc-aa44-e0ceb6228967@github.com>

On Tue, 20 May 2025 16:03:14 GMT, cagliostro92 <duke at openjdk.org> wrote:

> Trivial PR to enhance Javadoc for the `Properties#list` method, which has cost me some debugging time.

It does appear true that a `ClassCastException` is thrown if a value is not a String for `Properties.list(PrintWriter)` and the behavior looks to be long-standing. A minimal update to make this apparent seems appropriate. 

I filed the following issue: [JDK-8358530](https://bugs.openjdk.org/browse/JDK-8358530) for this PR. I can create a CSR (to cover the specification changes) for you when the wording changes are finalized.

The class description wording,

> the call to the propertyNames or list method will fail if it is called on a "compromised" Properties object that contains a non-String key. 

should also probably get an update as well.

src/java.base/share/classes/java/util/Properties.java line 1240:

> 1238:      *
> 1239:      * @param   out   an output stream.
> 1240:      * @throws  ClassCastException if either a key or a value

This change can be applied to `Properties.list(PrintStream out)` as well.

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

Changes requested by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25334#pullrequestreview-3011894003
PR Review Comment: https://git.openjdk.org/jdk/pull/25334#discussion_r2201789369

From duke at openjdk.org  Tue Jul 15 09:39:20 2025
From: duke at openjdk.org (cagliostro92)
Date: Tue, 15 Jul 2025 09:39:20 GMT
Subject: RFR: 8358530: enhanced Properties#list javadoc
In-Reply-To: <8NuDR-76UsKGJz8ZoZS7bVEXrNHnchfy21O3UG2Kg1k=.6dad1ac6-2895-4acc-aa44-e0ceb6228967@github.com>
References: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
 <8NuDR-76UsKGJz8ZoZS7bVEXrNHnchfy21O3UG2Kg1k=.6dad1ac6-2895-4acc-aa44-e0ceb6228967@github.com>
Message-ID: <lcfhTCAGnm9gj8SY65XRyWm9-7VltlJ-9Yk4LEzAOhY=.9d1a87a4-f617-4902-8769-4f0c07704f5c@github.com>

On Fri, 11 Jul 2025 20:51:38 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Trivial PR to enhance Javadoc for the `Properties#list` method, which has cost me some debugging time.
>
> It does appear true that a `ClassCastException` is thrown if a value is not a String for `Properties.list(PrintWriter)` and the behavior looks to be long-standing. A minimal update to make this apparent seems appropriate. 
> 
> I filed the following issue: [JDK-8358530](https://bugs.openjdk.org/browse/JDK-8358530) for this PR. I can create a CSR (to cover the specification changes) for you when the wording changes are finalized.
> 
> The class description wording,
> 
>> the call to the propertyNames or list method will fail if it is called on a "compromised" Properties object that contains a non-String key. 
> 
> should also probably get an update as well.

Hi @justin-curtis-lu I've just pushed a new commit following your suggestion. Would be great if you could create a CSR on my behalf. ?

> src/java.base/share/classes/java/util/Properties.java line 1240:
> 
>> 1238:      *
>> 1239:      * @param   out   an output stream.
>> 1240:      * @throws  ClassCastException if either a key or a value
> 
> This change can be applied to `Properties.list(PrintStream out)` as well.

solved with 7e28926d92f4d499b854894f9371f0bfd1f052b6

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

PR Comment: https://git.openjdk.org/jdk/pull/25334#issuecomment-3072897583
PR Review Comment: https://git.openjdk.org/jdk/pull/25334#discussion_r2206977481

From duke at openjdk.org  Tue Jul 15 10:27:47 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 15 Jul 2025 10:27:47 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v7]
In-Reply-To: <3rpHvyWtHhdZJs90s9eu7YIWmDX2kC7ycM9UptH0zxk=.8bd18955-a5cb-4ea8-8769-40209d2867f7@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <C3aAwHxenLIEswZqQg-pjqjWQWbyTHD-5yvAIpbTCUU=.4a1620c8-b794-427c-ba39-1c0133174847@github.com>
 <3rpHvyWtHhdZJs90s9eu7YIWmDX2kC7ycM9UptH0zxk=.8bd18955-a5cb-4ea8-8769-40209d2867f7@github.com>
Message-ID: <J9qJNoyWJQ-AdrOXsIv_FMto4c7ZKeiT-aZNXdoQr-M=.8b254e28-4410-4f39-a7ff-653f5bb709f3@github.com>

On Mon, 14 Jul 2025 20:11:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Linting of a few minor issues (nothing serious).
>>   
>>   * Linting of minor issues.
>>   * Factored out the module existence test, it's only a performance heuristic and could (should?) be removed.
>
> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 148:
> 
>> 146:     /**
>> 147:      * Returns the content of a resource node.
>> 148:      *
> 
> It may be helpful to mention that the byte[] returned is a copy and on return the caller is the owner.
> If/when we have immutable byte arrays, it would save allocation and copying to return a/the cached byte array.

Will do. Though I'd be very cautious about caching arrays here since these bytes are likely consumed and transformed by callers, and probably only looked-up once or twice at most.

> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 182:
> 
>> 180: 
>> 181:     private static final class SharedImageReader extends BasicImageReader {
>> 182:         // TODO: Should this be OPEN_FILES or openFiles (it's not constant).
> 
> All caps is good for final statics.

Even if mutable? I've seen both in the codebase so wasn't sure what the style should be. I'll remove the TODO.

> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 204:
> 
>> 202:             super(imagePath, byteOrder);
>> 203:             this.imageFileAttributes = Files.readAttributes(imagePath, BasicFileAttributes.class);
>> 204:             // TODO (review note): Given there are ~30,000 nodes in the image, is setting an initial capacity a good idea?
> 
> Likely yes, saving multiple (12) re-sizing's before reaching the 30k occupancy.

Any thoughts on a good-enough first guess. The benchmark has a list of 800 or so classes loaded just to get the simplest "hello world" working, so I'm thinking that something between 2000 and 5000 as an initial size would be justifiable (and we can always change it later). Ideally we'd be able to report/imply the value and figure it out empirically.

> 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 at these offsets.
> 
> ok as is, its stable.

Cool. Will remove the TODO. Thanks.

> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 348:
> 
>> 346:             }
>> 347:             // Tests the implied module directory location "/modules/<module>" exists.
>> 348:             ImageLocation loc = findLocation(name.substring(0, moduleEnd));
> 
> There might be an opportunity to save some string creation if some functions took a (string, start, end) parameters. It would need to ripple down through ImageStringsReader.hashCode and would make the code less readable.

Yeah, I looked at making a hashcode from string parts, but the API gets messy fast. I still might do it as a followup (now we will have benchmarks to test performance with).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2207091408
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2207085022
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2207083384
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2207085176
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2207088339

From duke at openjdk.org  Tue Jul 15 10:44:03 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 15 Jul 2025 10:44:03 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v8]
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: <fRWwZYsIQ0KqnYQbZ-bmlAbs8uZRyA_foq2uflqVPU0=.3064b763-1eb8-4d2e-9a7a-17e1f25e1a40@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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26054/files
  - new: https://git.openjdk.org/jdk/pull/26054/files/bb9972de..92a7eb62

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

  Stats: 12 lines in 1 file changed: 5 ins; 2 del; 5 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 15 10:44:04 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 15 Jul 2025 10:44:04 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v7]
In-Reply-To: <C3aAwHxenLIEswZqQg-pjqjWQWbyTHD-5yvAIpbTCUU=.4a1620c8-b794-427c-ba39-1c0133174847@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <C3aAwHxenLIEswZqQg-pjqjWQWbyTHD-5yvAIpbTCUU=.4a1620c8-b794-427c-ba39-1c0133174847@github.com>
Message-ID: <pq2cUxk_kSZ6r9NnqeNOCsxSzPLp2iHmgYxwM1_UkFQ=.77e80229-7506-4b95-b68a-c67cbb7caef1@github.com>

On Fri, 11 Jul 2025 14:41:30 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:
> 
>   Linting of a few minor issues (nothing serious).
>   
>   * Linting of minor issues.
>   * Factored out the module existence test, it's only a performance heuristic and could (should?) be removed.

@RogerRiggs I did most of the things you suggested. With regards to locking, I am very hesitant to change anything in the PR (the issue was already there) but will open a bug for it I think. I am also wary of locking two locks at the same time, so would want to move `nodes.clear()` probably after the detaching of the reader from the "openers" cache.
Plus, I set an initial capacity of 2000 in the node cache (seems the smallest reasonable guess).

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

PR Comment: https://git.openjdk.org/jdk/pull/26054#issuecomment-3073092265

From alan.bateman at oracle.com  Tue Jul 15 10:50:20 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 15 Jul 2025 11:50:20 +0100
Subject: ClassLoader Leak via Executors.newSingleThreadExecutor(...)
In-Reply-To: <CAM1ck5hB3ym3dt8wAp3uQer5W=9=uboU6azgkCtMJji9ovnBBg@mail.gmail.com>
References: <CAM1ck5hB3ym3dt8wAp3uQer5W=9=uboU6azgkCtMJji9ovnBBg@mail.gmail.com>
Message-ID: <f02c0d49-9199-4061-90cd-f9dce54e13c3@oracle.com>

On 11/07/2025 15:42, Chris Dennis wrote:
> Hi All,
>
> I believe I've identified a bug in 
> Executors.AutoShutdownDelegatedExecutorService that can trigger a 
> classloader leak even in the presence of "correct" Executor 
> lifecycling. AutoShutdownDelegatedExecutorService only unlinks the 
> PhantomReference used for?cleanup handling when it is shutdown via the 
> shutdown() method. If an Executor wrapped in this way is instead 
> shutdown using the shutdownNow() method and it references a 
> classloader via an injected attribute: ThreadFactory, AbortPolicy, 
> etc. then the cleanup action will reference the classloader, and the 
> classloader will remain strongly referenced. Adding an additional 
> override as shown in the attached patch is sufficient to fix the leak 
> in my testing.
>
It would be useful if you could say more about the scenario. The cleaner 
should execute once the executor service is eligible to be GC'ed and the 
reference is queued. Invoking shutdown just means it is early 
unregistered. So I'm wondering if your issue is more about timing in 
that it's not being GC'ed in a timely manner.

-Alan

From duke at openjdk.org  Tue Jul 15 11:05:27 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 15 Jul 2025 11:05:27 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v9]
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: <kxhjZFUvpTxJpaPh5_zgtJSa4C1dZ3Qyu2ycSRuKzhc=.6dfc8e6d-ca19-4b6c-8532-627af04ea680@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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26054/files
  - new: https://git.openjdk.org/jdk/pull/26054/files/92a7eb62..332a1c84

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

  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 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 chris.w.dennis at gmail.com  Tue Jul 15 11:59:35 2025
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Tue, 15 Jul 2025 07:59:35 -0400
Subject: ClassLoader Leak via Executors.newSingleThreadExecutor(...)
In-Reply-To: <f02c0d49-9199-4061-90cd-f9dce54e13c3@oracle.com>
References: <CAM1ck5hB3ym3dt8wAp3uQer5W=9=uboU6azgkCtMJji9ovnBBg@mail.gmail.com>
 <f02c0d49-9199-4061-90cd-f9dce54e13c3@oracle.com>
Message-ID: <CAM1ck5hxkfw4ONPJwopKiuwLtUYD=j9zd7vkFpMrKb5Zv2OvGg@mail.gmail.com>

Apologies, that description is pretty lousy. A more explicit description of
the leak (the one in my test in https://github.com/openjdk/jdk/pull/26296)
would be: A class loaded by classloader 'C' statically references an
Executor created via newSingleThreadExecutor(threadFactory). The
ThreadFactory is an instance of a class also loaded by 'C'. This executor
is then shutdown via shutdownNow(). The resulting structure will pin the
classloader 'C' in memory.

Chris

On Tue, 15 Jul 2025 at 06:50, Alan Bateman <alan.bateman at oracle.com> wrote:

> On 11/07/2025 15:42, Chris Dennis wrote:
> > Hi All,
> >
> > I believe I've identified a bug in
> > Executors.AutoShutdownDelegatedExecutorService that can trigger a
> > classloader leak even in the presence of "correct" Executor
> > lifecycling. AutoShutdownDelegatedExecutorService only unlinks the
> > PhantomReference used for cleanup handling when it is shutdown via the
> > shutdown() method. If an Executor wrapped in this way is instead
> > shutdown using the shutdownNow() method and it references a
> > classloader via an injected attribute: ThreadFactory, AbortPolicy,
> > etc. then the cleanup action will reference the classloader, and the
> > classloader will remain strongly referenced. Adding an additional
> > override as shown in the attached patch is sufficient to fix the leak
> > in my testing.
> >
> It would be useful if you could say more about the scenario. The cleaner
> should execute once the executor service is eligible to be GC'ed and the
> reference is queued. Invoking shutdown just means it is early
> unregistered. So I'm wondering if your issue is more about timing in
> that it's not being GC'ed in a timely manner.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250715/377f0c74/attachment.htm>

From mbaesken at openjdk.org  Tue Jul 15 12:55:50 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 15 Jul 2025 12:55:50 GMT
Subject: RFR: 8361888: [GCC static analyzer] ProcessImpl_md.c
 Java_java_lang_ProcessImpl_forkAndExec error: use of uninitialized value
 '*(ChildStuff *)p.mode
Message-ID: <0P03-vXLWU8JpjLpa6V8XpTCx0UPsNdHEr4Qi-c4qQQ=.25239ad9-2a3e-4602-8192-3a0dd302796f@github.com>

When using GCC static analyzer (-fanalyzer), the following issue is reported.
Seems `c->mode` is initialized later in the method, but we use it already in the exception, this looks wrong.


/jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c: In function 'Java_java_lang_ProcessImpl_forkAndExec':
/jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:735:9: error: use of uninitialized value '*(ChildStuff *)p.mode' [CWE-457] [-Werror=analyzer-use-of-uninitialized-value]
  735 | throwInternalIOException(env, errno, "Bad file descriptor", c->mode);
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Commit messages:
 - JDK-8361888

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

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

From rgiulietti at openjdk.org  Tue Jul 15 13:24:45 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 15 Jul 2025 13:24:45 GMT
Subject: Integrated: 8358540: Enhance MathUtils in view of FloatingDecimal
 enhancements
In-Reply-To: <QCVtBd071dMKhosNAlY09O1LpR6G9W4pnXpxPhwvTPA=.34e14f02-699d-49d7-8fc5-8090080aa106@github.com>
References: <QCVtBd071dMKhosNAlY09O1LpR6G9W4pnXpxPhwvTPA=.34e14f02-699d-49d7-8fc5-8090080aa106@github.com>
Message-ID: <c21AHNnpeKU8zc7I_MK6WaZ2gpQvRF_n1ND-_sNflw4=.2b7daa63-ad80-44e3-b319-c69a5cf27954@github.com>

On Wed, 4 Jun 2025 14:22:43 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Another step in enhancing floating-point <-> decimal conversions.

This pull request has now been integrated.

Changeset: 563e8762
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/563e8762464fd1b291eb18f5234c1655386cc8dd
Stats:     1781 lines in 8 files changed: 343 ins; 481 del; 957 mod

8358540: Enhance MathUtils in view of FloatingDecimal enhancements

Reviewed-by: darcy

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

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

From alanb at openjdk.org  Tue Jul 15 13:31:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Jul 2025 13:31:51 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v3]
In-Reply-To: <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
Message-ID: <cO1zXItkW-dfgISgig8mEe1Aos_urlRS11MWAGXIHzw=.972adca9-cc58-4e4c-a0c4-1f884137e268@github.com>

On Mon, 14 Jul 2025 20:23:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
>> This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

src/java.base/share/classes/java/lang/System.java line 244:

> 242:      *
> 243:      * @return  The system console, if any, otherwise {@code null}.
> 244:      * @see Console

The method declaration already links to Console so I don't think we need another link in the "See also" section.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2207473872

From alanb at openjdk.org  Tue Jul 15 13:31:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Jul 2025 13:31:51 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v3]
In-Reply-To: <cO1zXItkW-dfgISgig8mEe1Aos_urlRS11MWAGXIHzw=.972adca9-cc58-4e4c-a0c4-1f884137e268@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
 <cO1zXItkW-dfgISgig8mEe1Aos_urlRS11MWAGXIHzw=.972adca9-cc58-4e4c-a0c4-1f884137e268@github.com>
Message-ID: <u4iqIEvR6AlBXRLAOXLl3W0zHxzF9-jkFbODhznu6oo=.af6bf899-7526-4920-b8e8-92ee35bcf1cb@github.com>

On Tue, 15 Jul 2025 13:25:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comments
>
> src/java.base/share/classes/java/lang/System.java line 244:
> 
>> 242:      *
>> 243:      * @return  The system console, if any, otherwise {@code null}.
>> 244:      * @see Console
> 
> The method declaration already links to Console so I don't think we need another link in the "See also" section.

Maybe I missed it, but do we have anything to make it clear that it returns null if either stdin or stdout are redirected?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2207483449

From rriggs at openjdk.org  Tue Jul 15 14:09:39 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 14:09:39 GMT
Subject: RFR: 8361888: [GCC static analyzer] ProcessImpl_md.c
 Java_java_lang_ProcessImpl_forkAndExec error: use of uninitialized value
 '*(ChildStuff *)p.mode
In-Reply-To: <0P03-vXLWU8JpjLpa6V8XpTCx0UPsNdHEr4Qi-c4qQQ=.25239ad9-2a3e-4602-8192-3a0dd302796f@github.com>
References: <0P03-vXLWU8JpjLpa6V8XpTCx0UPsNdHEr4Qi-c4qQQ=.25239ad9-2a3e-4602-8192-3a0dd302796f@github.com>
Message-ID: <2z4T1HfhaqAqzBCCQN5M2-Xhn1H_4v5v9i5h1Cb8Fo8=.f96f7eed-e134-4fca-83b7-bd5223541a33@github.com>

On Tue, 15 Jul 2025 12:51:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using GCC static analyzer (-fanalyzer), the following issue is reported.
> Seems `c->mode` is initialized later in the method, but we use it already in the exception, this looks wrong.
> 
> 
> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c: In function 'Java_java_lang_ProcessImpl_forkAndExec':
> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:735:9: error: use of uninitialized value '*(ChildStuff *)p.mode' [CWE-457] [-Werror=analyzer-use-of-uninitialized-value]
>   735 | throwInternalIOException(env, errno, "Bad file descriptor", c->mode);
>       | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

looks fine.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26316#pullrequestreview-3020544381

From rgiulietti at openjdk.org  Tue Jul 15 14:21:44 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 15 Jul 2025 14:21:44 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal [v4]
In-Reply-To: <nOyjL13Gw7c91vi9NtdXLyLpyI9VpoFTRaWzHcM9Quk=.c9ed3ca3-fe1a-4e69-a058-dcc13e5a0f4f@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
 <nOyjL13Gw7c91vi9NtdXLyLpyI9VpoFTRaWzHcM9Quk=.c9ed3ca3-fe1a-4e69-a058-dcc13e5a0f4f@github.com>
Message-ID: <gft1Ix8ByJO8jHsg66O0HC6bKoxMAB_T1MsCWW4_jl4=.65afcac6-f8fb-4b3f-afff-0b0c369aab31@github.com>

On Wed, 4 Jun 2025 13:12:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Some static final arrays of BigInteger and BigDecimal are stable and immutable. We should add `@Stable` to give the optimizer more information
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into math_stable_202505
>  - BigInteger::mag remove Stable
>  - bug fix, from @minborg
>  - BigInteger::mag add `@Stable`
>  - add stable

LGTM

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

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25437#pullrequestreview-3020634902

From rriggs at openjdk.org  Tue Jul 15 14:30:42 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 14:30:42 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: <vf6Px4zJNJrwVk66vBHdarAXon9vCnhLyf2gyxe0_fA=.009ecf72-773a-4996-83f4-2c17626003e9@github.com>

On Wed, 9 Jul 2025 05:45:01 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of the change that prevents RandomAccessFile::readLine from emitting an event per character? This leads to unnecessary overhead, both with or without JFR enabled.
> 
> Testing: tier1 + tier2 +  jdk/jdk/jfr
> 
> Thanks
> Erik

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26210#pullrequestreview-3020688621

From sherman at openjdk.org  Tue Jul 15 14:35:42 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 15 Jul 2025 14:35:42 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v3]
In-Reply-To: <u4iqIEvR6AlBXRLAOXLl3W0zHxzF9-jkFbODhznu6oo=.af6bf899-7526-4920-b8e8-92ee35bcf1cb@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
 <cO1zXItkW-dfgISgig8mEe1Aos_urlRS11MWAGXIHzw=.972adca9-cc58-4e4c-a0c4-1f884137e268@github.com>
 <u4iqIEvR6AlBXRLAOXLl3W0zHxzF9-jkFbODhznu6oo=.af6bf899-7526-4920-b8e8-92ee35bcf1cb@github.com>
Message-ID: <Ugc0-PSaFEgTqbvkKWniZ1WHULGyCLmUpqSa8VIHEaQ=.67317723-f459-43ca-a03b-52984a0fa9d2@github.com>

On Tue, 15 Jul 2025 13:29:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 244:
>> 
>>> 242:      *
>>> 243:      * @return  The system console, if any, otherwise {@code null}.
>>> 244:      * @see Console
>> 
>> The method declaration already links to Console so I don't think we need another link in the "See also" section.
>
> Maybe I missed it, but do we have anything to make it clear that it returns null if either stdin or stdout are redirected?

we do have wordings like " If the virtual machine is started from an interactive command line without redirecting the standard input AND output streams then its console will exist ..." and "If no console device is
available then an invocation of that method will return <tt>null</tt>" from the very beginning. not very "straightforward" but i think it's clear enough?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2207686213

From igraves at openjdk.org  Tue Jul 15 14:36:48 2025
From: igraves at openjdk.org (Ian Graves)
Date: Tue, 15 Jul 2025 14:36:48 GMT
Subject: Integrated: 8358768: [vectorapi] Make VectorOperators.SUADD an
 Associative
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: <IVs2iH7Hqp7OB2K856jR4CunBhZBMJag21vmIImEevI=.32a8f285-3ffd-4fd8-a2cf-548e7ccfe1d3@github.com>

On Wed, 2 Jul 2025 16:47:36 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.

This pull request has now been integrated.

Changeset: b65fdf5a
Author:    Ian Graves <igraves at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b65fdf5af0a5e1cf0d66d7551c6df63e8d07c5fa
Stats:     3158 lines in 37 files changed: 3157 ins; 0 del; 1 mod

8358768: [vectorapi] Make VectorOperators.SUADD an Associative

Reviewed-by: psandoz

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

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

From thomas.stuefe at gmail.com  Tue Jul 15 14:44:24 2025
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 15 Jul 2025 16:44:24 +0200
Subject: How important is jspawnhelper crash detection?
Message-ID: <CAA-vtUzCxv=KtGWnVCbXzBKdg5FPuYodqWmmcU2iz+t0SHdUnA@mail.gmail.com>

Hi,

I am currently working on removing (eventually) the vfork mode. Before we
can do this, we need a bit better error diagnostics. I do this by gently
improving the error handling throughout the code, so that we can generate
IOExceptions based on more exact knowledge.

While working at this, I re-examined the "send aliveness ping from
jspawnhelper to parent" logic again I introduced back in 2019 as a
workaround for an obscure glibc bug with posix_spawn (see
https://bugs.openjdk.org/browse/JDK-8223777). I found that it was not
needed anymore since the glibc was fixed, so I started removing that
workaround (https://bugs.openjdk.org/browse/JDK-8362257).

But then it occurred to me that an obscure part of the jspawnhelper
diagnostics introduced with https://bugs.openjdk.org/browse/JDK-8226242
piggy-backs on the aliveness ping for its
"detect-abnormal-process-termination-before-exec" capabilities. Works like
this:

A jspawnhelper starts
B jspawnhelper enters childProcess() and sends alivenes ping
C jspawnhelper does a bunch of other things
D jspawnhelper exec's

In the parent, we count abnormal child terminations that occur before the
aliveness ping (B) as "spawn error" and print the signal number.  Without
the aliveness ping we could not tell apart "jspawnhelper ends abnormally
due to a signal" from "jspawnhelper exec()'s the user program successfully,
user program runs and ends abnormally due to signal".

However, the question is how important or even useful this part really is:
- for externally sent abnormal termination signals (SIGTERM etc), from the
caller's point of view it probably does not matter when it comes : before
or after exec().
- it only matters for synchronous termination signals (crashes) we
ourselves cause; but here it only covers crashes in a rather small piece of
code, before the liveness ping (B). Basically, just the first part of
jspawnhelper main(). Any crashes after the liveness ping are still
unrecognised by ProcessBuilder.start, and are instead handled by the caller
calling Process.waitFor().

There are two ways to deal with this:

We could do without the crash protection in point (A), which would allow us
to remove the liveness ping. I would very much prefer that. It would
simplify the jspawnhelper protocol and make it more robust. Because we now
don't have any communication in case no error happens - there would be only
a single bit of information sent back via fail pipe, and only in case of an
error. Fail pipe would stay quiet in case of successful exec(). Abnormal
child process termination in the first part of jspawnhelper would be
covered by the same path that detects abnormal child process termination in
user programs - Process.waitFor().

If we determine we really need this crash detection, we could at least
improve it: move the liveness ping to just-before the exec() call, so that
we cover all the area from A-D. Also, do it for all modes (FORK, too), to
simplify coding.

Bottomline: remove an obscure and complex small mechanism that only helps a
bit with detecting program errors (sigsegv etc) inside the first part of
jspawnhelper main() ?

Thanks, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250715/2206bec4/attachment-0001.htm>

From rriggs at openjdk.org  Tue Jul 15 14:45:41 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 14:45:41 GMT
Subject: RFR: 8360575: java.util.Properties.list() methods trim each value
 to 37 characters in the listed output [v4]
In-Reply-To: <Jy3J4p5L8D4tpKN_-Ghr4VUdrVgnV3YLlKV00Dq-Z9w=.3bbc3090-f954-4526-95f5-0801eb5fd8b2@github.com>
References: <-dRew0C7Qw5REtfjrGiYdfY_bRcnBiUyKXok3lMF9ug=.57d81faf-4a4f-42a9-9238-539a5d0b5625@github.com>
 <Jy3J4p5L8D4tpKN_-Ghr4VUdrVgnV3YLlKV00Dq-Z9w=.3bbc3090-f954-4526-95f5-0801eb5fd8b2@github.com>
Message-ID: <N_pyK-w47wm7RQAv2qvg00nvRy8pNZKMVr4z8sMDooI=.c6a72f7a-ada0-4e63-bcfb-0bfc44b33d8f@github.com>

On Mon, 30 Jun 2025 06:01:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to clarify the current implementation of the `java.util.Properties.list(...)` methods?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8360575, the current implementation trims each value to a size of 37 when printing out the value. This behaviour isn't documented by these methods. The change in this PR adds an `@implNote` to make a mention of this current behaviour.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's review - no need to state the number of characters

The example should be updated as suggested.

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

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26018#pullrequestreview-3020755633

From roger.riggs at oracle.com  Tue Jul 15 15:04:54 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 15 Jul 2025 11:04:54 -0400
Subject: How important is jspawnhelper crash detection?
In-Reply-To: <CAA-vtUzCxv=KtGWnVCbXzBKdg5FPuYodqWmmcU2iz+t0SHdUnA@mail.gmail.com>
References: <CAA-vtUzCxv=KtGWnVCbXzBKdg5FPuYodqWmmcU2iz+t0SHdUnA@mail.gmail.com>
Message-ID: <132c3aaf-138a-44b1-8b6a-f8ac188854ce@oracle.com>

Hi Thomas,

Simpler is better on both sides of the protocol.
The version check will have happened before this part of the protocol so 
there's no confusion about matching expectations.
I agree that removing it is preferred.

Roger


On 7/15/25 10:44 AM, Thomas St?fe wrote:
> Hi,
>
> I am currently working on removing (eventually) the vfork mode. Before 
> we can do this, we need a bit better error diagnostics. I do this by 
> gently improving the error handling throughout the code, so that we 
> can generate IOExceptions based on more exact knowledge.
>
> While working at this, I re-examined the "send aliveness ping from 
> jspawnhelper to parent" logic again I introduced back in 2019 as a 
> workaround for an obscure glibc bug with posix_spawn (see 
> https://bugs.openjdk.org/browse/JDK-8223777). I found that it was not 
> needed anymore since the glibc was fixed, so I started removing that 
> workaround (https://bugs.openjdk.org/browse/JDK-8362257).
>
> But then it occurred to me that an obscure part of the jspawnhelper 
> diagnostics introduced with 
> https://bugs.openjdk.org/browse/JDK-8226242 piggy-backs on the 
> aliveness ping for its 
> "detect-abnormal-process-termination-before-exec" capabilities. Works 
> like this:
>
> A jspawnhelper starts
> B jspawnhelper enters childProcess() and sends alivenes ping
> C jspawnhelper does a bunch of other things
> D jspawnhelper exec's
>
> In the parent, we count abnormal child terminations that occur before 
> the aliveness ping (B) as "spawn error" and print the signal number.? 
> Without the aliveness ping we could not tell apart "jspawnhelper ends 
> abnormally due to a signal" from "jspawnhelper exec()'s the user 
> program successfully, user program runs and ends abnormally due to 
> signal".
>
> However, the question is how important or even useful this part really is:
> - for externally sent abnormal termination signals (SIGTERM etc), from 
> the caller's point of view it probably does not matter when it comes : 
> before or after exec().
> - it only matters for synchronous termination signals (crashes) we 
> ourselves cause; but here it only covers crashes in a rather small 
> piece of code, before the liveness ping (B). Basically, just the first 
> part of jspawnhelper main(). Any crashes after the liveness ping are 
> still unrecognised by ProcessBuilder.start, and are instead handled by 
> the caller calling Process.waitFor().
>
> There are two ways to deal with this:
>
> We could do without the crash protection in point (A), which would 
> allow us to remove the liveness ping. I would very much prefer that. 
> It would simplify the jspawnhelper protocol and make it more robust. 
> Because we now don't have any communication in case no error happens - 
> there would be only a single bit of information sent back via fail 
> pipe, and only in case of an error. Fail pipe would stay quiet in case 
> of successful exec(). Abnormal child process termination in the first 
> part of jspawnhelper would be covered by the same path that detects 
> abnormal child process termination in user programs - Process.waitFor().
>
> If we determine we really need this crash detection, we could at least 
> improve it: move the liveness ping to just-before the exec() call, so 
> that we cover all the area from A-D. Also, do it for all modes (FORK, 
> too), to simplify coding.
>
> Bottomline: remove an obscure and complex small mechanism that only 
> helps a bit with detecting program errors (sigsegv etc) inside the 
> first part of jspawnhelper main() ?
>
> Thanks, Thomas
>
>


From sherman at openjdk.org  Tue Jul 15 15:11:07 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 15 Jul 2025 15:11:07 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v5]
In-Reply-To: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
Message-ID: <jdAdeVsvHk2gdpu036xHSS5ccjw2l9lCgmTin-_0e8s=.2c9c8b1d-904d-4fc9-939d-723499c1392f@github.com>

> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
> 
> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
> 
> **RL1.5 states**: 
> 
> To meet this requirement, an implementation that supports case-sensitive matching should
> 
>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>     2. Specify which character properties or constructs are closed under the matching.
> 
> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
> 
>     1. back-refs
>     2. string slices (sequences)
>     3. single character,
>     4. character families (Unicode Properties ...), and
>     5. character class ranges
> 
> **Note**: Single characters and families may appear independently or within a character class.
> 
> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
> 
> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
> 
> For example:
> 
> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
> 
> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
> 
> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
> 
> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
> vs
> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
> 
> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
> 
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/**_i_** ? "true\n" : "false\n"'. => **_true_**
> 
> The root issue is that the ran...

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

  improve the lookup logic and test case for +00df

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26285/files
  - new: https://git.openjdk.org/jdk/pull/26285/files/c2afc42c..b85f581f

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

  Stats: 44 lines in 3 files changed: 31 ins; 3 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/26285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26285/head:pull/26285

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

From sherman at openjdk.org  Tue Jul 15 15:18:54 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 15 Jul 2025 15:18:54 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v5]
In-Reply-To: <6AFn-UzXqb_oY_XGpadyiepteLDrlHJsSqZfXrybPug=.c8454bbe-15df-463a-8e6c-53022ece337b@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <KkZbNbSXZYZ22wG-u_Qgzafv-SxHfITuIq7lNk4RFNg=.a5a9e5b6-c1a7-4e7f-983f-919fea7b97be@github.com>
 <6AFn-UzXqb_oY_XGpadyiepteLDrlHJsSqZfXrybPug=.c8454bbe-15df-463a-8e6c-53022ece337b@github.com>
Message-ID: <UxvyQqURlW9KqVg5vxbMfWRCht3dW63nOWChVDmZn6o=.55cc30b8-84e4-4fca-9a7a-9caf42bf4ea6@github.com>

On Mon, 14 Jul 2025 07:28:09 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/regex/CaseFolding.java.template line 99:
>> 
>>> 97:      */
>>> 98:     public static int[] getClassRangeClosingCharacters(int start, int end) {
>>> 99:         int[] expanded = new int[expanded_casefolding.size()];
>> 
>> Can be `Math.min(expanded_casefolding.size(), end - start)` in case the table grows large, and update the `off < expanded.length` check below too.
>
> The table itself probably isn't going to grow significantly anytime soon, and we?ll likely have enough time to adjust if CaseFolding.txt does get substantially bigger.
> 
> That said, I probably should consider reversing the lookup logic: instead of iterating through [start, end], we could iterate over the expansion table and check whether any of its code points fall within the input range, at least when the range size is larger than the size of the table, kinda O(n) vs O(1)-ish.

updated the lookup logic as discussed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2207809731

From rgiulietti at openjdk.org  Tue Jul 15 15:21:39 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 15 Jul 2025 15:21:39 GMT
Subject: RFR: 8362207: Add more test cases for possible double-rounding in
 fma
In-Reply-To: <vo6ZFgc9-NCGHZcd5ftuMzaH2aswSB6rkclyJknn7BI=.45bf8bdf-5d0f-4751-b694-a294f8820b35@github.com>
References: <vo6ZFgc9-NCGHZcd5ftuMzaH2aswSB6rkclyJknn7BI=.45bf8bdf-5d0f-4751-b694-a294f8820b35@github.com>
Message-ID: <1gm0ql7LzTUo_ESWp1_bjbYsE8G0TAYDQy1jjCsU52E=.15660be6-b702-417e-b0c4-95f61d20a1a7@github.com>

On Tue, 15 Jul 2025 01:10:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> From discussions related to IEEE 754, a few explicit test cases were identified where plausible, but incorrect, implementations of fma using higher precision. These test cases are useful to include in the regression tests of the float-precision and Float16-precision fused multiple add methods.

Looks fine

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

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26305#pullrequestreview-3020926328

From joehw at openjdk.org  Tue Jul 15 15:24:42 2025
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 15 Jul 2025 15:24:42 GMT
Subject: RFR: 8361972: Clarify the condition of System.console() about
 standard input/output [v2]
In-Reply-To: <TKnCmtTeM0-f1yunDtO8zRno4ZbVWxhiWN0kagttFns=.3f8e4e55-84f4-4eee-924a-e04e46485c12@github.com>
References: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
 <TKnCmtTeM0-f1yunDtO8zRno4ZbVWxhiWN0kagttFns=.3f8e4e55-84f4-4eee-924a-e04e46485c12@github.com>
Message-ID: <bxd1mRVqaBSG1QMxsn4FIDB3b-DtVDQTYtNI0VDvy28=.62df520c-236a-445a-9a5b-49be9341daf8@github.com>

On Mon, 14 Jul 2025 22:39:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This accompanies the fix for [JDK-8361613](https://bugs.openjdk.org/browse/JDK-8361613), which restricts `System.console()` to return a `Console` instance only when both standard input and output are connected to a terminal. The change here is solely a specification clarification and tightening of the `java.io.Console` javadoc to reflect this behavior. We are separating the spec clarification because the fix itself may be backported to prior LTS releases without requiring a Maintenance Review process.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wording modification

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26299#pullrequestreview-3020940200

From bpb at openjdk.org  Tue Jul 15 15:29:42 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Jul 2025 15:29:42 GMT
Subject: RFR: 8361587: AssertionError in File.listFiles() when path is
 empty and -esa is enabled [v7]
In-Reply-To: <T0IaW5AqoO9Ay9wbQDFzrFck0md371Mk_ztoNtmbUZ0=.0866f1f0-e089-4a60-b1e9-c15498a14044@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <FtGSJdjUsUTLJqyl5t_5HLA4-ZR-I5M5u7kHyh1cu_M=.9aa4f0e2-a7d0-4ba6-8212-5d04c4b8cb4b@github.com>
 <T0IaW5AqoO9Ay9wbQDFzrFck0md371Mk_ztoNtmbUZ0=.0866f1f0-e089-4a60-b1e9-c15498a14044@github.com>
Message-ID: <9obVSqSI_U5qVk0T-3nYLJfrEe2rpCK78xIr76zAA0g=.ff20b90e-64f0-4534-a30a-d02a9b44adda@github.com>

On Tue, 15 Jul 2025 06:36:46 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: Improve previous commit
>
> test/jdk/java/io/File/EmptyPath.java line 283:
> 
>> 281:             assertTrue(child.mkdirs());
>> 282:             assertTrue(child.delete());
>> 283:         }
> 
> The updated proposal is local to listFiles and doesn't change UnixFileSystem.resolve. Is the test update in sync with the latest change?

Yes. The OS-dependent `mkdirs` sub-tests reflect the actual behavior.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26224#discussion_r2207836400

From qamai at openjdk.org  Tue Jul 15 15:44:45 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 15 Jul 2025 15:44:45 GMT
Subject: RFR: 8358768: [vectorapi] Make VectorOperators.SUADD an
 Associative [v4]
In-Reply-To: <O67Y19Stozc98wx_PhjkjLhdpCDPkMopKsyMCvpcc30=.98af4320-04da-49b4-ad4c-eaf849fec957@github.com>
References: <EZ4_14iY5_yTqfv3ZYpfoVRQK4jjxPtpafox1FQjq5M=.046cbb01-5fe5-4cf9-a468-ed22f0b4acda@github.com>
 <O67Y19Stozc98wx_PhjkjLhdpCDPkMopKsyMCvpcc30=.98af4320-04da-49b4-ad4c-eaf849fec957@github.com>
Message-ID: <SWmSxOkr1qcZOLMW0GyJYu5GyQUkpd1m8Ol-cJL0ToI=.13699854-11c0-457b-a539-6ffa999e2387@github.com>

On Mon, 14 Jul 2025 21:43: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:
> 
>   Condensing test data

I believe this is inadequate, an `Associative` will allow reduction operation. You need to add support for `SUADD` to that, too.

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

PR Comment: https://git.openjdk.org/jdk/pull/26099#issuecomment-3074198480

From psandoz at openjdk.org  Tue Jul 15 16:04:45 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 15 Jul 2025 16:04:45 GMT
Subject: RFR: 8358768: [vectorapi] Make VectorOperators.SUADD an
 Associative [v4]
In-Reply-To: <SWmSxOkr1qcZOLMW0GyJYu5GyQUkpd1m8Ol-cJL0ToI=.13699854-11c0-457b-a539-6ffa999e2387@github.com>
References: <EZ4_14iY5_yTqfv3ZYpfoVRQK4jjxPtpafox1FQjq5M=.046cbb01-5fe5-4cf9-a468-ed22f0b4acda@github.com>
 <O67Y19Stozc98wx_PhjkjLhdpCDPkMopKsyMCvpcc30=.98af4320-04da-49b4-ad4c-eaf849fec957@github.com>
 <SWmSxOkr1qcZOLMW0GyJYu5GyQUkpd1m8Ol-cJL0ToI=.13699854-11c0-457b-a539-6ffa999e2387@github.com>
Message-ID: <EUacJJbBWn8qf3UGsI0yppuFH6--HJ20REu5K7McDXQ=.3f24817a-d2a5-4ebd-ad2c-3ab9b14496b3@github.com>

On Tue, 15 Jul 2025 15:41:59 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> I believe this is inadequate, an `Associative` will allow reduction operation. You need to add support for `SUADD` to that, too.

Grrr... yes thank you for spotting that obvious omission. We can do that in a follow on PR, but without any intrinsic implementation in the `reductionOperations` switch.

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

PR Comment: https://git.openjdk.org/jdk/pull/26099#issuecomment-3074260783

From igraves at openjdk.org  Tue Jul 15 16:07:49 2025
From: igraves at openjdk.org (Ian Graves)
Date: Tue, 15 Jul 2025 16:07:49 GMT
Subject: RFR: 8358768: [vectorapi] Make VectorOperators.SUADD an
 Associative [v4]
In-Reply-To: <SWmSxOkr1qcZOLMW0GyJYu5GyQUkpd1m8Ol-cJL0ToI=.13699854-11c0-457b-a539-6ffa999e2387@github.com>
References: <EZ4_14iY5_yTqfv3ZYpfoVRQK4jjxPtpafox1FQjq5M=.046cbb01-5fe5-4cf9-a468-ed22f0b4acda@github.com>
 <O67Y19Stozc98wx_PhjkjLhdpCDPkMopKsyMCvpcc30=.98af4320-04da-49b4-ad4c-eaf849fec957@github.com>
 <SWmSxOkr1qcZOLMW0GyJYu5GyQUkpd1m8Ol-cJL0ToI=.13699854-11c0-457b-a539-6ffa999e2387@github.com>
Message-ID: <Ccb_oXo6tLqv9iC1HfLnzoeWURothtU2HBc_T3ui-u8=.daae8cf1-fa35-4e3c-944e-ff87cd294a1c@github.com>

On Tue, 15 Jul 2025 15:41:59 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Condensing test data
>
> I believe this is inadequate, an `Associative` will allow reduction operation. You need to add support for `SUADD` to that, too.

Will create a bug. Thanks @merykitty !

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

PR Comment: https://git.openjdk.org/jdk/pull/26099#issuecomment-3074270571

From alanb at openjdk.org  Tue Jul 15 16:12:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Jul 2025 16:12:40 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: <B4c9PF2e1qev7TnGG6I0GfYcSS2u-PBimTbnPtOwEo8=.47b1f4ca-68a5-4128-b08a-b382d1340692@github.com>

On Wed, 9 Jul 2025 05:45:01 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of the change that prevents RandomAccessFile::readLine from emitting an event per character? This leads to unnecessary overhead, both with or without JFR enabled.
> 
> Testing: tier1 + tier2 +  jdk/jdk/jfr
> 
> Thanks
> Erik

src/java.base/share/classes/java/io/RandomAccessFile.java line 1039:

> 1037:     }
> 1038: 
> 1039:     private String traceImplReadLine() throws IOException {

I think it would be cleaner to have the FileReadEvent usage in readLine. That would reduce this to readLine + implReadLine, no traceImplReadLine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26210#discussion_r2207938638

From naoto at openjdk.org  Tue Jul 15 16:28:48 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Jul 2025 16:28:48 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v3]
In-Reply-To: <Ugc0-PSaFEgTqbvkKWniZ1WHULGyCLmUpqSa8VIHEaQ=.67317723-f459-43ca-a03b-52984a0fa9d2@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
 <cO1zXItkW-dfgISgig8mEe1Aos_urlRS11MWAGXIHzw=.972adca9-cc58-4e4c-a0c4-1f884137e268@github.com>
 <u4iqIEvR6AlBXRLAOXLl3W0zHxzF9-jkFbODhznu6oo=.af6bf899-7526-4920-b8e8-92ee35bcf1cb@github.com>
 <Ugc0-PSaFEgTqbvkKWniZ1WHULGyCLmUpqSa8VIHEaQ=.67317723-f459-43ca-a03b-52984a0fa9d2@github.com>
Message-ID: <2tLfcUvYvIIVvxNIZPUkRT-hVw9a4Ew1J-Vf4jNEmhQ=.23dd367a-2b1d-4934-8381-c38313ed097f@github.com>

On Tue, 15 Jul 2025 14:31:45 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> Maybe I missed it, but do we have anything to make it clear that it returns null if either stdin or stdout are redirected?
>
> we do have wordings like " If the virtual machine is started from an interactive command line without redirecting the standard input AND output streams then its console will exist ..." and "If no console device is
> available then an invocation of that method will return <tt>null</tt>" from the very beginning. not very "straightforward" but i think it's clear enough?

I think adding `@see` tag would be more helpful.

As to the spec wording wrt stdin/out, there is another issue filed to make it clearer: JDK-8361972. This PR addresses the implementation part only so that it can be backported to prior LTSes without spec change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2207973733

From naoto at openjdk.org  Tue Jul 15 16:37:43 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Jul 2025 16:37:43 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v5]
In-Reply-To: <jdAdeVsvHk2gdpu036xHSS5ccjw2l9lCgmTin-_0e8s=.2c9c8b1d-904d-4fc9-939d-723499c1392f@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <jdAdeVsvHk2gdpu036xHSS5ccjw2l9lCgmTin-_0e8s=.2c9c8b1d-904d-4fc9-939d-723499c1392f@github.com>
Message-ID: <25jigXcio1o-HB3vf2ZMDBysoPU9whhSOgKZWnMrmd0=.575c1708-5960-441c-a109-1bceb88568b1@github.com>

On Tue, 15 Jul 2025 15:11:07 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>> 
>> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
>> 
>> **RL1.5 states**: 
>> 
>> To meet this requirement, an implementation that supports case-sensitive matching should
>> 
>>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>>     2. Specify which character properties or constructs are closed under the matching.
>> 
>> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
>> 
>>     1. back-refs
>>     2. string slices (sequences)
>>     3. single character,
>>     4. character families (Unicode Properties ...), and
>>     5. character class ranges
>> 
>> **Note**: Single characters and families may appear independently or within a character class.
>> 
>> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
>> 
>> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
>> 
>> For example:
>> 
>> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
>> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
>> 
>> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
>> 
>> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
>> 
>> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
>> vs
>> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
>> 
>> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
>> 
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{0...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve the lookup logic and test case for +00df

Updates look good to me.

test/jdk/java/util/regex/CaseFoldingTest.java line 51:

> 49:         var excluded = Set.of(
> 50:             // these 'S' characters failed for known reason. they don't map to their
> 51:             // fording form with toUpperCase or toLowerCase, only map with case-folding.

nit: fording -> folding

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

PR Review: https://git.openjdk.org/jdk/pull/26285#pullrequestreview-3021193767
PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2207985998

From jlu at openjdk.org  Tue Jul 15 16:39:42 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 15 Jul 2025 16:39:42 GMT
Subject: RFR: 8358530: enhanced Properties#list javadoc
In-Reply-To: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
References: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
Message-ID: <9Wr-amACg6uZeYoPf5Qfo-UwVDVvITaxpcNksaf6xY4=.54c2ac06-5e6d-41af-a4dd-b52b31824143@github.com>

On Tue, 20 May 2025 16:03:14 GMT, cagliostro92 <duke at openjdk.org> wrote:

> Trivial PR to enhance Javadoc for the `Properties#list` method, which has cost me some debugging time.

The copyright year for this file should also be updated: `1995, 2025,`

Also, the PR title will need to be changed to,

_8358530: Properties#list should warn against non-String values_

src/java.base/share/classes/java/util/Properties.java line 78:

> 76:  * the call to the {@code propertyNames} or {@code list} method
> 77:  * will fail if it is called on a "compromised" {@code Properties}
> 78:  * object that contains a non-{@code String} key or value.

Since `propertyNames` won't throw `CCE` with a non-String value, instead of adding the "or value" wording here, we should move the `list` method to the sentence above and remove it from the current sentence.

E.g., on line 73 

> "If the {@code store}, {@code save}, or {@code list) method ...

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

PR Review: https://git.openjdk.org/jdk/pull/25334#pullrequestreview-3021183784
PR Review Comment: https://git.openjdk.org/jdk/pull/25334#discussion_r2207979374

From alanb at openjdk.org  Tue Jul 15 16:46:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Jul 2025 16:46:40 GMT
Subject: RFR: 8361587: AssertionError in File.listFiles() when path is
 empty and -esa is enabled [v7]
In-Reply-To: <9obVSqSI_U5qVk0T-3nYLJfrEe2rpCK78xIr76zAA0g=.ff20b90e-64f0-4534-a30a-d02a9b44adda@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <FtGSJdjUsUTLJqyl5t_5HLA4-ZR-I5M5u7kHyh1cu_M=.9aa4f0e2-a7d0-4ba6-8212-5d04c4b8cb4b@github.com>
 <T0IaW5AqoO9Ay9wbQDFzrFck0md371Mk_ztoNtmbUZ0=.0866f1f0-e089-4a60-b1e9-c15498a14044@github.com>
 <9obVSqSI_U5qVk0T-3nYLJfrEe2rpCK78xIr76zAA0g=.ff20b90e-64f0-4534-a30a-d02a9b44adda@github.com>
Message-ID: <sGJ1kSYTWFYghWaKzbBYo704S3VSZsO4lBpSH7Dp4Ho=.2529ed61-c94b-49e1-8cef-a53c1c997350@github.com>

On Tue, 15 Jul 2025 15:27:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/io/File/EmptyPath.java line 283:
>> 
>>> 281:             assertTrue(child.mkdirs());
>>> 282:             assertTrue(child.delete());
>>> 283:         }
>> 
>> The updated proposal is local to listFiles and doesn't change UnixFileSystem.resolve. Is the test update in sync with the latest change?
>
> Yes. The OS-dependent `mkdirs` sub-tests reflect the actual behavior.

Okay, but if I read this correctly then these methods will test mkdirs with a non-empty path as child will be "/child" or "\child".  In order to test mkdirs with an empty path then I think we need `assertFalse(f.mkdirs());`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26224#discussion_r2208011372

From sherman at openjdk.org  Tue Jul 15 16:56:44 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 15 Jul 2025 16:56:44 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v5]
In-Reply-To: <jdAdeVsvHk2gdpu036xHSS5ccjw2l9lCgmTin-_0e8s=.2c9c8b1d-904d-4fc9-939d-723499c1392f@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <jdAdeVsvHk2gdpu036xHSS5ccjw2l9lCgmTin-_0e8s=.2c9c8b1d-904d-4fc9-939d-723499c1392f@github.com>
Message-ID: <eOnRe8KERa_l5lJTa1N6awGQ4AG4_qglLL6yBbM3Vy8=.6e58d464-a3c2-48fd-ba69-50758b36cc0a@github.com>

On Tue, 15 Jul 2025 15:11:07 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>> 
>> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
>> 
>> **RL1.5 states**: 
>> 
>> To meet this requirement, an implementation that supports case-sensitive matching should
>> 
>>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>>     2. Specify which character properties or constructs are closed under the matching.
>> 
>> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
>> 
>>     1. back-refs
>>     2. string slices (sequences)
>>     3. single character,
>>     4. character families (Unicode Properties ...), and
>>     5. character class ranges
>> 
>> **Note**: Single characters and families may appear independently or within a character class.
>> 
>> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
>> 
>> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
>> 
>> For example:
>> 
>> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
>> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
>> 
>> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
>> 
>> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
>> 
>> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
>> vs
>> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
>> 
>> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
>> 
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{0...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve the lookup logic and test case for +00df

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26285#issuecomment-3074413884

From bpb at openjdk.org  Tue Jul 15 17:05:46 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Jul 2025 17:05:46 GMT
Subject: RFR: 8361587: AssertionError in File.listFiles() when path is
 empty and -esa is enabled [v5]
In-Reply-To: <xm3Bb65HoUf-pdJPtjm39wZ85Pq-LqE_XfQCmldO5r0=.3eb3ead7-fcfc-48ca-a501-3de20671cc14@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <uM6Bmm5rwcMo6PdyeZJudSBZ4eIUTpfiEsGcmBBMWYA=.21d11e7e-9b04-42ec-9381-dbed0d763a52@github.com>
 <omhJ4IRKTVIbbj1YXXysc5t5QV2VWZ5d6ZJhOWFYAeE=.30c25ad9-0d0c-4046-a125-ea0559f9e85b@github.com>
 <xm3Bb65HoUf-pdJPtjm39wZ85Pq-LqE_XfQCmldO5r0=.3eb3ead7-fcfc-48ca-a501-3de20671cc14@github.com>
Message-ID: <sLN-VMaMIXVtVGrvWbUFGWUbEXDzm2ODm-4RGaJyLes=.cf554857-3969-4fe5-8757-fcd69c5122d6@github.com>

On Fri, 11 Jul 2025 15:34:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> 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.
>
>> [...] look to special casing the empty parent in the listFiles methods [...].
> 
> Will investigate.

Done as of b055507.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26224#discussion_r2208049996

From bpb at openjdk.org  Tue Jul 15 17:05:46 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Jul 2025 17:05:46 GMT
Subject: RFR: 8361587: AssertionError in File.listFiles() when path is
 empty and -esa is enabled [v7]
In-Reply-To: <sGJ1kSYTWFYghWaKzbBYo704S3VSZsO4lBpSH7Dp4Ho=.2529ed61-c94b-49e1-8cef-a53c1c997350@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <FtGSJdjUsUTLJqyl5t_5HLA4-ZR-I5M5u7kHyh1cu_M=.9aa4f0e2-a7d0-4ba6-8212-5d04c4b8cb4b@github.com>
 <T0IaW5AqoO9Ay9wbQDFzrFck0md371Mk_ztoNtmbUZ0=.0866f1f0-e089-4a60-b1e9-c15498a14044@github.com>
 <9obVSqSI_U5qVk0T-3nYLJfrEe2rpCK78xIr76zAA0g=.ff20b90e-64f0-4534-a30a-d02a9b44adda@github.com>
 <sGJ1kSYTWFYghWaKzbBYo704S3VSZsO4lBpSH7Dp4Ho=.2529ed61-c94b-49e1-8cef-a53c1c997350@github.com>
Message-ID: <W6605tVe8YkYJOsCcg31lgrBdgclUrvYBZK7JfVbpv0=.1ef757bc-7d80-4f95-8a3b-edd620ff0d9d@github.com>

On Tue, 15 Jul 2025 16:43:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Yes. The OS-dependent `mkdirs` sub-tests reflect the actual behavior.
>
> Okay, but if I read this correctly then these methods will test mkdirs with a non-empty path as child will be "/child" or "\child".  In order to test mkdirs with an empty path then I think we need `assertFalse(f.mkdirs());`

> [I]f I read this correctly then these methods will test mkdirs with a non-empty path as child will be "/child" or "\child".

Right. Yes, I agree this needs modification. Also, I don't trust the stability of the `mkdirs` sub-test on Windows as conceivably it could fail with no permission to create a folder `C:\folder`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26224#discussion_r2208057888

From egahlin at openjdk.org  Tue Jul 15 17:09:23 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 15 Jul 2025 17:09:23 GMT
Subject: RFR: 8361640: JFR: RandomAccessFile::readLine emits events for
 each character [v2]
In-Reply-To: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
References: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
Message-ID: <hpkOkElHxTJn9I5Fe0NO3yvmLeisxqBx_sX7wyjVSe0=.4e29605c-e82d-4f6a-ac6b-dfe1c855109f@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 + tier2 +  jdk/jdk/jfr
> 
> Thanks
> Erik

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

  Remove traceImplReadLine

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26210/files
  - new: https://git.openjdk.org/jdk/pull/26210/files/027093ed..37b10a17

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

  Stats: 21 lines in 1 file changed: 8 ins; 12 del; 1 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 bpb at openjdk.org  Tue Jul 15 17:36:22 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Jul 2025 17:36:22 GMT
Subject: RFR: 8361587: AssertionError in File.listFiles() when path is
 empty and -esa is enabled [v8]
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: <CZboh0l2JIXaw4kzPpiVVZCKM4Ic_EMbwni0XKaVrTA=.6f5b4655-2456-416d-a4ba-f32d4be6361d@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: Fix mkdirs sub-test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26224/files
  - new: https://git.openjdk.org/jdk/pull/26224/files/b0555078..8272cdb7

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

  Stats: 22 lines in 1 file changed: 0 ins; 20 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  Tue Jul 15 17:36:22 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Jul 2025 17:36:22 GMT
Subject: RFR: 8361587: AssertionError in File.listFiles() when path is
 empty and -esa is enabled [v7]
In-Reply-To: <W6605tVe8YkYJOsCcg31lgrBdgclUrvYBZK7JfVbpv0=.1ef757bc-7d80-4f95-8a3b-edd620ff0d9d@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <FtGSJdjUsUTLJqyl5t_5HLA4-ZR-I5M5u7kHyh1cu_M=.9aa4f0e2-a7d0-4ba6-8212-5d04c4b8cb4b@github.com>
 <T0IaW5AqoO9Ay9wbQDFzrFck0md371Mk_ztoNtmbUZ0=.0866f1f0-e089-4a60-b1e9-c15498a14044@github.com>
 <9obVSqSI_U5qVk0T-3nYLJfrEe2rpCK78xIr76zAA0g=.ff20b90e-64f0-4534-a30a-d02a9b44adda@github.com>
 <sGJ1kSYTWFYghWaKzbBYo704S3VSZsO4lBpSH7Dp4Ho=.2529ed61-c94b-49e1-8cef-a53c1c997350@github.com>
 <W6605tVe8YkYJOsCcg31lgrBdgclUrvYBZK7JfVbpv0=.1ef757bc-7d80-4f95-8a3b-edd620ff0d9d@github.com>
Message-ID: <VP031EqfhiNivPmOgrAXavwjYIzWvG3LBw_K6y-JZ8k=.30212fd7-5d6f-49c2-8bcc-7e543d29b051@github.com>

On Tue, 15 Jul 2025 17:03:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Okay, but if I read this correctly then these methods will test mkdirs with a non-empty path as child will be "/child" or "\child".  In order to test mkdirs with an empty path then I think we need `assertFalse(f.mkdirs());`
>
>> [I]f I read this correctly then these methods will test mkdirs with a non-empty path as child will be "/child" or "\child".
> 
> Right. Yes, I agree this needs modification. Also, I don't trust the stability of the `mkdirs` sub-test on Windows as conceivably it could fail with no permission to create a folder `C:\folder`.

Changed in 8272cdb.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26224#discussion_r2208149145

From sherman at openjdk.org  Tue Jul 15 17:47:29 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 15 Jul 2025 17:47:29 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v6]
In-Reply-To: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
Message-ID: <5E6oBo3DXqhtFDuwQJTinQxlb0J14QjaXxbKvj5JK0Q=.64180f86-6b61-4383-8f5a-dfb71d1cbd8d@github.com>

> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
> 
> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
> 
> **RL1.5 states**: 
> 
> To meet this requirement, an implementation that supports case-sensitive matching should
> 
>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>     2. Specify which character properties or constructs are closed under the matching.
> 
> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
> 
>     1. back-refs
>     2. string slices (sequences)
>     3. single character,
>     4. character families (Unicode Properties ...), and
>     5. character class ranges
> 
> **Note**: Single characters and families may appear independently or within a character class.
> 
> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
> 
> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
> 
> For example:
> 
> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
> 
> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
> 
> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
> 
> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
> vs
> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
> 
> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
> 
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/**_i_** ? "true\n" : "false\n"'. => **_true_**
> 
> The root issue is that the ran...

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

  update to fix the typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26285/files
  - new: https://git.openjdk.org/jdk/pull/26285/files/b85f581f..a090888f

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

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

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

From naoto at openjdk.org  Tue Jul 15 17:47:30 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Jul 2025 17:47:30 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v6]
In-Reply-To: <5E6oBo3DXqhtFDuwQJTinQxlb0J14QjaXxbKvj5JK0Q=.64180f86-6b61-4383-8f5a-dfb71d1cbd8d@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <5E6oBo3DXqhtFDuwQJTinQxlb0J14QjaXxbKvj5JK0Q=.64180f86-6b61-4383-8f5a-dfb71d1cbd8d@github.com>
Message-ID: <AX9t_TZdtI02sf6-86bGPTZEmws3Oq1Nk_YovUYkAo8=.19cc69de-1703-4ca8-abd2-5514c57df6af@github.com>

On Tue, 15 Jul 2025 17:44:00 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>> 
>> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
>> 
>> **RL1.5 states**: 
>> 
>> To meet this requirement, an implementation that supports case-sensitive matching should
>> 
>>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>>     2. Specify which character properties or constructs are closed under the matching.
>> 
>> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
>> 
>>     1. back-refs
>>     2. string slices (sequences)
>>     3. single character,
>>     4. character families (Unicode Properties ...), and
>>     5. character class ranges
>> 
>> **Note**: Single characters and families may appear independently or within a character class.
>> 
>> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
>> 
>> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
>> 
>> For example:
>> 
>> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
>> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
>> 
>> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
>> 
>> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
>> 
>> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
>> vs
>> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
>> 
>> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
>> 
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{0...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to fix the typo

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26285#pullrequestreview-3021537588

From egahlin at openjdk.org  Tue Jul 15 17:48:39 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 15 Jul 2025 17:48:39 GMT
Subject: RFR: 8361640: JFR: RandomAccessFile::readLine emits events for
 each character [v2]
In-Reply-To: <B4c9PF2e1qev7TnGG6I0GfYcSS2u-PBimTbnPtOwEo8=.47b1f4ca-68a5-4128-b08a-b382d1340692@github.com>
References: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
 <B4c9PF2e1qev7TnGG6I0GfYcSS2u-PBimTbnPtOwEo8=.47b1f4ca-68a5-4128-b08a-b382d1340692@github.com>
Message-ID: <_nyotsEtXqR_QscsRsAUKa4Apk6zEgKQy8xpkvoPpKg=.ea911c7d-b6c9-4a6c-9ac4-e327a91a7412@github.com>

On Tue, 15 Jul 2025 16:09:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove traceImplReadLine
>
> src/java.base/share/classes/java/io/RandomAccessFile.java line 1039:
> 
>> 1037:     }
>> 1038: 
>> 1039:     private String traceImplReadLine() throws IOException {
> 
> I think it would be cleaner to have the FileReadEvent usage in readLine. That would reduce this to readLine + implReadLine, no traceImplReadLine.

Refactored the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26210#discussion_r2208195842

From sherman at openjdk.org  Tue Jul 15 17:59:47 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 15 Jul 2025 17:59:47 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v6]
In-Reply-To: <5E6oBo3DXqhtFDuwQJTinQxlb0J14QjaXxbKvj5JK0Q=.64180f86-6b61-4383-8f5a-dfb71d1cbd8d@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <5E6oBo3DXqhtFDuwQJTinQxlb0J14QjaXxbKvj5JK0Q=.64180f86-6b61-4383-8f5a-dfb71d1cbd8d@github.com>
Message-ID: <xCTA4BbJR5c3eiy7XH3SJ_aKMXBvH6QTfJz_3asx49U=.b2cb538c-abb6-44db-89aa-80ba4fada9fb@github.com>

On Tue, 15 Jul 2025 17:47:29 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>> 
>> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
>> 
>> **RL1.5 states**: 
>> 
>> To meet this requirement, an implementation that supports case-sensitive matching should
>> 
>>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>>     2. Specify which character properties or constructs are closed under the matching.
>> 
>> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
>> 
>>     1. back-refs
>>     2. string slices (sequences)
>>     3. single character,
>>     4. character families (Unicode Properties ...), and
>>     5. character class ranges
>> 
>> **Note**: Single characters and families may appear independently or within a character class.
>> 
>> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
>> 
>> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
>> 
>> For example:
>> 
>> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
>> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
>> 
>> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
>> 
>> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
>> 
>> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
>> vs
>> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
>> 
>> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
>> 
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{0...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to fix the typo

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26285#issuecomment-3074710596

From sherman at openjdk.org  Tue Jul 15 17:59:50 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 15 Jul 2025 17:59:50 GMT
Subject: Integrated: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char
In-Reply-To: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
Message-ID: <14NDWi0xfcZsPdfzJDeupxOHKnKJVUJ6tl4jphrJT_s=.29adb663-fc33-4b19-91c1-a264ad2288c5@github.com>

On Mon, 14 Jul 2025 04:53:13 GMT, Xueming Shen <sherman at openjdk.org> wrote:

> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
> 
> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
> 
> **RL1.5 states**: 
> 
> To meet this requirement, an implementation that supports case-sensitive matching should
> 
>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>     2. Specify which character properties or constructs are closed under the matching.
> 
> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
> 
>     1. back-refs
>     2. string slices (sequences)
>     3. single character,
>     4. character families (Unicode Properties ...), and
>     5. character class ranges
> 
> **Note**: Single characters and families may appear independently or within a character class.
> 
> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
> 
> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
> 
> For example:
> 
> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
> 
> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
> 
> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
> 
> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
> vs
> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
> 
> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
> 
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/**_i_** ? "true\n" : "false\n"'. => **_true_**
> 
> The root issue is that the ran...

This pull request has now been integrated.

Changeset: 401af27b
Author:    Xueming Shen <sherman at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/401af27b9dbc701eb48e5bc685d3ad058e0de3bc
Stats:     2084 lines in 9 files changed: 2079 ins; 0 del; 5 mod

8360459: UNICODE_CASE and character class with non-ASCII range does not match ASCII char

Reviewed-by: naoto

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

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

From alanb at openjdk.org  Tue Jul 15 18:02:42 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Jul 2025 18:02:42 GMT
Subject: RFR: 8361587: AssertionError in File.listFiles() when path is
 empty and -esa is enabled [v8]
In-Reply-To: <CZboh0l2JIXaw4kzPpiVVZCKM4Ic_EMbwni0XKaVrTA=.6f5b4655-2456-416d-a4ba-f32d4be6361d@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <CZboh0l2JIXaw4kzPpiVVZCKM4Ic_EMbwni0XKaVrTA=.6f5b4655-2456-416d-a4ba-f32d4be6361d@github.com>
Message-ID: <FUInH8xe1bXPH2t4qWdJhVkkEluoQlC7ddAxrp5_K_Q=.a09f18a4-a3fe-4a39-9094-e1436e42417c@github.com>

On Tue, 15 Jul 2025 17:36:22 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: Fix mkdirs sub-test

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26224#pullrequestreview-3021641188

From alanb at openjdk.org  Tue Jul 15 18:04:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Jul 2025 18:04:46 GMT
Subject: RFR: 8361640: JFR: RandomAccessFile::readLine emits events for
 each character [v2]
In-Reply-To: <hpkOkElHxTJn9I5Fe0NO3yvmLeisxqBx_sX7wyjVSe0=.4e29605c-e82d-4f6a-ac6b-dfe1c855109f@github.com>
References: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
 <hpkOkElHxTJn9I5Fe0NO3yvmLeisxqBx_sX7wyjVSe0=.4e29605c-e82d-4f6a-ac6b-dfe1c855109f@github.com>
Message-ID: <ctSg4w8ax-XJltYQvmzghoY5ZYkgyOZgkuRaRWDPKJo=.5b2d1f60-b609-4962-95c2-a4e01140a22e@github.com>

On Tue, 15 Jul 2025 17:09:23 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of the change that prevents RandomAccessFile::readLine from emitting an event per character? This leads to unnecessary overhead, both with or without JFR enabled.
>> 
>> Testing: tier1 + tier2 +  jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove traceImplReadLine

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26210#pullrequestreview-3021653358

From bpb at openjdk.org  Tue Jul 15 18:17:45 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Jul 2025 18:17:45 GMT
Subject: Integrated: 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: <58hD_fmDu_aVmHkZookSgh9cXB-oVmkR3kYQJL1Dzdo=.3327a831-48b2-48f7-948f-409c514620b9@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.

This pull request has now been integrated.

Changeset: eefbfdce
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eefbfdce315237eeec4aceceb476d86314304e81
Stats:     84 lines in 2 files changed: 80 ins; 1 del; 3 mod

8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled

Reviewed-by: alanb

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

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

From bpb at openjdk.org  Tue Jul 15 18:25:52 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Jul 2025 18:25:52 GMT
Subject: [jdk25] RFR: 8361587: AssertionError in File.listFiles() when path is
 empty and -esa is enabled
Message-ID: <hHrBHeN228ckHTQIXzKiGU6XiUX76kjt6GNi4wxFG6w=.c3541c21-9091-43da-86ed-4af5b38c1bd1@github.com>

Hi all,

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

The commit being backported was authored by Brian Burkhalter on 15 Jul 2025 and was reviewed by Alan Bateman.

Thanks!

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

Commit messages:
 - Backport eefbfdce315237eeec4aceceb476d86314304e81

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

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

From rriggs at openjdk.org  Tue Jul 15 18:56:42 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 18:56:42 GMT
Subject: RFR: 8361640: JFR: RandomAccessFile::readLine emits events for
 each character [v2]
In-Reply-To: <hpkOkElHxTJn9I5Fe0NO3yvmLeisxqBx_sX7wyjVSe0=.4e29605c-e82d-4f6a-ac6b-dfe1c855109f@github.com>
References: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
 <hpkOkElHxTJn9I5Fe0NO3yvmLeisxqBx_sX7wyjVSe0=.4e29605c-e82d-4f6a-ac6b-dfe1c855109f@github.com>
Message-ID: <u9H4VLcYH6iG7tL6LIbnpNsnMvVsn9o01xIUJfsAQlU=.df285b11-60d4-452c-b167-d179d20af10b@github.com>

On Tue, 15 Jul 2025 17:09:23 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of the change that prevents RandomAccessFile::readLine from emitting an event per character? This leads to unnecessary overhead, both with or without JFR enabled.
>> 
>> Testing: tier1 + tier2 +  jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove traceImplReadLine

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26210#pullrequestreview-3021883229

From rriggs at openjdk.org  Tue Jul 15 19:17:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 19:17:50 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v7]
In-Reply-To: <J9qJNoyWJQ-AdrOXsIv_FMto4c7ZKeiT-aZNXdoQr-M=.8b254e28-4410-4f39-a7ff-653f5bb709f3@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <C3aAwHxenLIEswZqQg-pjqjWQWbyTHD-5yvAIpbTCUU=.4a1620c8-b794-427c-ba39-1c0133174847@github.com>
 <3rpHvyWtHhdZJs90s9eu7YIWmDX2kC7ycM9UptH0zxk=.8bd18955-a5cb-4ea8-8769-40209d2867f7@github.com>
 <J9qJNoyWJQ-AdrOXsIv_FMto4c7ZKeiT-aZNXdoQr-M=.8b254e28-4410-4f39-a7ff-653f5bb709f3@github.com>
Message-ID: <-Gsx-rwD0X0FgzjQoI7e3wgNCt3PSxLmcrRFrBgXPlk=.24e376da-791e-4cfe-9a8a-ef054bf6962c@github.com>

On Tue, 15 Jul 2025 10:22:08 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 182:
>> 
>>> 180: 
>>> 181:     private static final class SharedImageReader extends BasicImageReader {
>>> 182:         // TODO: Should this be OPEN_FILES or openFiles (it's not constant).
>> 
>> All caps is good for final statics.
>
> Even if mutable? I've seen both in the codebase so wasn't sure what the style should be. I'll remove the TODO.

The Map is mutable but the static field is constant after initialization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2208450981

From rriggs at openjdk.org  Tue Jul 15 19:17:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 19:17:52 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v9]
In-Reply-To: <kxhjZFUvpTxJpaPh5_zgtJSa4C1dZ3Qyu2ycSRuKzhc=.6dfc8e6d-ca19-4b6c-8532-627af04ea680@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <kxhjZFUvpTxJpaPh5_zgtJSa4C1dZ3Qyu2ycSRuKzhc=.6dfc8e6d-ca19-4b6c-8532-627af04ea680@github.com>
Message-ID: <pEyeuha3gaHXhxEDe86CPnFDdhBQNr2BuAQxfYEdPlo=.f62f81bc-469c-4752-b948-b8d853b29de4@github.com>

On Tue, 15 Jul 2025 11:05:27 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 changes.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 623:

> 621:         }
> 622: 
> 623:         // TODO (review note): Could/should this be IllegalStateException?

IllegalStateException would be fine.  It can't/should not occur.
The exception message might more helpfully return the type of the Node, not just the node's name.
It could also be an InternalError, since a subclass of Node should have overridden getChildNames() and didn't.
But this is a tight little subclass tree so it doesn't matter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2208441052

From rriggs at openjdk.org  Tue Jul 15 19:20:46 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 19:20:46 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v9]
In-Reply-To: <kxhjZFUvpTxJpaPh5_zgtJSa4C1dZ3Qyu2ycSRuKzhc=.6dfc8e6d-ca19-4b6c-8532-627af04ea680@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <kxhjZFUvpTxJpaPh5_zgtJSa4C1dZ3Qyu2ycSRuKzhc=.6dfc8e6d-ca19-4b6c-8532-627af04ea680@github.com>
Message-ID: <6iOgwx__WR_YggaY9gn12nPEhepQAIRkFo0ZzwfxqN8=.126274a5-d78c-42c5-9008-8737d0c455a2@github.com>

On Tue, 15 Jul 2025 11:05:27 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 changes.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26054#pullrequestreview-3021983438

From vyazici at openjdk.org  Tue Jul 15 19:21:28 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 19:21:28 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <3ySadb4ljhHpenFOP9xRX2su1JyWBXWlRv09x--NnBc=.ea4de36e-403b-4cd9-831a-a80aacfcfde5@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` 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");
>         }
>     }
> }
> ...

Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:

 - Minimize the number of touched lines in `vmIntrinsics.hpp`
 - Remove Markdown-styling in comments
 - Improve wording of the `VerifyIntrinsicChecks` flag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/6af98646..7c042b35

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

  Stats: 14 lines in 5 files changed: 0 ins; 0 del; 14 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 vyazici at openjdk.org  Tue Jul 15 19:21:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 19:21:29 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
Message-ID: <Jx0DTrwcRbgYJzQ0rbfBGQhVy1OEVU2gFJDAh32YpcQ=.07327b3c-e0b0-4a93-9d9e-03416abde256@github.com>

On Mon, 14 Jul 2025 08:49:44 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>
> src/hotspot/share/opto/c2_globals.hpp line 666:
> 
>> 664:                                                                             \
>> 665:   develop(bool, VerifyIntrinsicChecks, false,                               \
>> 666:           "Verify that Java level checks in intrinsics work as expected")   \
> 
> To make it clearer I think we might want to move "in intrinsic" after "Verify" or at the end.

Changed as suggested in c331fbfa.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208455093

From vyazici at openjdk.org  Tue Jul 15 19:27:44 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 19:27:44 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
Message-ID: <pnD36-qHKsrbrg38-Znz4lP8Erb06nrjkamauxQ8PPw=.d9f91fbe-d4de-499e-8b39-4e5283456ba8@github.com>

On Mon, 14 Jul 2025 10:27:45 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>
> src/hotspot/share/classfile/vmIntrinsics.hpp line 417:
> 
>> 415:                                                                                                                         \
>> 416:   do_class(java_lang_StringCoding,        "java/lang/StringCoding")                                                     \
>> 417:   do_intrinsic(_countPositives,           java_lang_StringCoding, countPositives_name, countPositives_signature,   F_S) \
> 
> It is a matter of taste but it might be better not to change the whitespaces (it might make searching for changes (and possibly backports) harder. The rest of the file is not too consistent anyway).

Fixed in 7c042b35.

I completely agree with your point. In fact, I'm opposed to _"vertical alignment"_ due to its obvious maintainability and version control hygiene issues. Alas, that is the existing style, and I tried to adhere to it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208469532

From vyazici at openjdk.org  Tue Jul 15 19:31:42 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 19:31:42 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
Message-ID: <wgs1GVG69QfKChew9MwaIrJQx4aVaEXnhs1P0rqa3FE=.60f3724b-d34e-4604-9b2b-86352e4c5049@github.com>

On Mon, 14 Jul 2025 09:11:08 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 6014:
> 
>> 6012: }
>> 6013: 
>> 6014: // Encode given `char[]`/`byte[]` to `byte[]` in ISO_8859_1 or ASCII
> 
> Thanks for updating the comments! Do we need the markdown back quotes here (and in other `macroAssembler-*` file comments)?

No, we don't. Since Markdown has become ubiquitous in text-based typesetting, I find it easier to read and, whenever needed, share it in other mediums; Slack, GitHub, JIRA, Javadoc, Microsoft Office 365, Google Docs, etc. I presume you prefer without backticks ? removed them in b60ff457.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208477825

From vyazici at openjdk.org  Tue Jul 15 19:34:42 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 19:34:42 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <ocFbRK-j58EsQmSMwfEsm9q7KbUXtnhYtRA83_AghGc=.b1e13e1e-c613-4000-8565-422b362aa30e@github.com>
Message-ID: <0Rbm6JuupxK9iYkXljWRpmdCAg_fmf_92FUckntpQ3A=.7c633679-c46c-4395-8431-8564301b0dbb@github.com>

On Mon, 14 Jul 2025 10:32:24 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> I left a couple of minor comments. I also noticed that you haven't yet added the benchmark results to the description: do you want to run them again after the reviews?

@dafedafe, thanks so much for the review! I've implemented the changes you requested, and shared some benchmark figures in the associated ticket. I am still actively working on evaluating the performance impact.

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

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3075223785

From rriggs at openjdk.org  Tue Jul 15 19:50:43 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 19:50:43 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <3ySadb4ljhHpenFOP9xRX2su1JyWBXWlRv09x--NnBc=.ea4de36e-403b-4cd9-831a-a80aacfcfde5@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <3ySadb4ljhHpenFOP9xRX2su1JyWBXWlRv09x--NnBc=.ea4de36e-403b-4cd9-831a-a80aacfcfde5@github.com>
Message-ID: <uMdZTwppO7EQl5tj8ltFV0HDcIG41gHH2fRo7yQN_MI=.fdfeac6b-dd29-4580-aec0-8a9d4933c26f@github.com>

On Tue, 15 Jul 2025 19:21:28 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 IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` 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...
>
> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>  - Remove Markdown-styling in comments
>  - Improve wording of the `VerifyIntrinsicChecks` flag

src/java.base/share/classes/java/lang/StringCoding.java line 36:

> 34: import static java.util.Objects.requireNonNull;
> 35: import static jdk.internal.util.Preconditions.AIOOBE_FORMATTER;
> 36: import static jdk.internal.util.Preconditions.checkFromIndexSize;

Avoid import static of methods, it makes the code harder to read and understand where the methods come from.
Just import Preconditions.

src/java.base/share/classes/java/lang/StringCoding.java line 162:

> 160:             if (c > '\u00FF')
> 161:                 break;
> 162:             da[dp++] = (byte) c;

Revert: Omit the space after (byte); there many more usages of "(byte)c" and this file does not need to drift from the prevailing style in StringUTF16.java AbstractStringBuilder, etc.
Here and at line 195:

src/java.base/share/classes/java/lang/StringCoding.java line 189:

> 187: 
> 188:     @IntrinsicCandidate
> 189:     private static int encodeAsciiArray0(char[] sa, int sp, byte[] da, int dp, int len) {

I rather prefer the readability of the src and dest parameters being on separate lines. (but not "{" by itself
Suggestion:

    private static int encodeAsciiArray0(char[] sa, int sp, 
                                         byte[] da, int dp, int len) {

src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 43:

> 41: import static java.util.Objects.requireNonNull;
> 42: import static jdk.internal.util.Preconditions.AIOOBE_FORMATTER;
> 43: import static jdk.internal.util.Preconditions.checkFromIndexSize;

Avoid static imports of methods, it makes it harder to read and know where the methods are especially when crossing package boundaries.

src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 177:

> 175:                 if (c > '\u00FF')
> 176:                     break;
> 177:                 da[dp++] = (byte) c;

Revert extra space.

src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 201:

> 199:             int len  = (dlen < slen) ? dlen : slen;
> 200:             try {
> 201:                 int ret = len <= 0 ? 0 : encodeISOArray(sa, sp, da, dp, len);

Moving the length correction into `encodeISOArray` would help other callers too.  (There's only 1 at the moment).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208470957
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208491363
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208494207
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208503099
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208504829
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208510343

From vyazici at openjdk.org  Tue Jul 15 20:24:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 20:24:04 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v3]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` 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");
>         }
>     }
> }
> ...

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

 - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
 - Apply review feedback (styling changes)
 - Minimize the number of touched lines in `vmIntrinsics.hpp`
 - Remove Markdown-styling in comments
 - Improve wording of the `VerifyIntrinsicChecks` flag
 - 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
   
   This reverts commit 196fc5d406851b8e7070c97ac53ca59c4615aad9.
 - Improve intrinsics in `StringCoding`
 - Add `StringCodingCountPositives` benchmark
 - ... and 2 more: https://git.openjdk.org/jdk/compare/b424f31d...85f19864

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/7c042b35..85f19864

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

  Stats: 7104 lines in 199 files changed: 2886 ins; 3418 del; 800 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 vyazici at openjdk.org  Tue Jul 15 20:24:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 20:24:04 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <uMdZTwppO7EQl5tj8ltFV0HDcIG41gHH2fRo7yQN_MI=.fdfeac6b-dd29-4580-aec0-8a9d4933c26f@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <3ySadb4ljhHpenFOP9xRX2su1JyWBXWlRv09x--NnBc=.ea4de36e-403b-4cd9-831a-a80aacfcfde5@github.com>
 <uMdZTwppO7EQl5tj8ltFV0HDcIG41gHH2fRo7yQN_MI=.fdfeac6b-dd29-4580-aec0-8a9d4933c26f@github.com>
Message-ID: <ugG_C0UBIiUOJV2vcib89uno7vn292iwp3rvVwMfQA4=.e30be329-5eee-4587-961d-8453bf1b3ce3@github.com>

On Tue, 15 Jul 2025 19:25:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>
> src/java.base/share/classes/java/lang/StringCoding.java line 36:
> 
>> 34: import static java.util.Objects.requireNonNull;
>> 35: import static jdk.internal.util.Preconditions.AIOOBE_FORMATTER;
>> 36: import static jdk.internal.util.Preconditions.checkFromIndexSize;
> 
> Avoid import static of methods, it makes the code harder to read and understand where the methods come from.
> Just import Preconditions.

Fixed in 2672f7c1ada.

> src/java.base/share/classes/java/lang/StringCoding.java line 162:
> 
>> 160:             if (c > '\u00FF')
>> 161:                 break;
>> 162:             da[dp++] = (byte) c;
> 
> Revert: Omit the space after (byte); there many more usages of "(byte)c" and this file does not need to drift from the prevailing style in StringUTF16.java AbstractStringBuilder, etc.
> Here and at line 195:

I've actually made these changes to match the code shared in intrinsics, e.g., `macroAssembler_x86.cpp`. Reverted them in 2672f7c1ada as you requested.

> src/java.base/share/classes/java/lang/StringCoding.java line 189:
> 
>> 187: 
>> 188:     @IntrinsicCandidate
>> 189:     private static int encodeAsciiArray0(char[] sa, int sp, byte[] da, int dp, int len) {
> 
> I rather prefer the readability of the src and dest parameters being on separate lines. (but not "{" by itself
> Suggestion:
> 
>     private static int encodeAsciiArray0(char[] sa, int sp, 
>                                          byte[] da, int dp, int len) {

Changed as requested in 2672f7c1ada.

> src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 43:
> 
>> 41: import static java.util.Objects.requireNonNull;
>> 42: import static jdk.internal.util.Preconditions.AIOOBE_FORMATTER;
>> 43: import static jdk.internal.util.Preconditions.checkFromIndexSize;
> 
> Avoid static imports of methods, it makes it harder to read and know where the methods are especially when crossing package boundaries.

Changed as requested in 2672f7c1ada.

> src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 177:
> 
>> 175:                 if (c > '\u00FF')
>> 176:                     break;
>> 177:                 da[dp++] = (byte) c;
> 
> Revert extra space.

Changed as requested in 2672f7c1ada.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208575103
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208578241
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208579144
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208579489
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208579689

From vyazici at openjdk.org  Tue Jul 15 20:26:41 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 20:26:41 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <uMdZTwppO7EQl5tj8ltFV0HDcIG41gHH2fRo7yQN_MI=.fdfeac6b-dd29-4580-aec0-8a9d4933c26f@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <3ySadb4ljhHpenFOP9xRX2su1JyWBXWlRv09x--NnBc=.ea4de36e-403b-4cd9-831a-a80aacfcfde5@github.com>
 <uMdZTwppO7EQl5tj8ltFV0HDcIG41gHH2fRo7yQN_MI=.fdfeac6b-dd29-4580-aec0-8a9d4933c26f@github.com>
Message-ID: <r4Jq9gM2GkBVZaTpjsTiRtmfYDqFbG5vfZB73pm4di0=.9a8b2793-b82f-49a8-a395-6986d7be2d25@github.com>

On Tue, 15 Jul 2025 19:45:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>
> src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 201:
> 
>> 199:             int len  = (dlen < slen) ? dlen : slen;
>> 200:             try {
>> 201:                 int ret = len <= 0 ? 0 : encodeISOArray(sa, sp, da, dp, len);
> 
> Moving the length correction into `encodeISOArray` would help other callers too.  (There's only 1 at the moment).

I've tried to make the code such that wrapper functions contain nothing but argument checks. Moving `if (len <= 0) { return 0; }` logic to the wrapper function will introduce a behavior different than the one implemented by the intrinsic. @RogerRiggs, do you still prefer me to carry out this change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208585771

From rriggs at openjdk.org  Tue Jul 15 20:32:43 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 20:32:43 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v2]
In-Reply-To: <r4Jq9gM2GkBVZaTpjsTiRtmfYDqFbG5vfZB73pm4di0=.9a8b2793-b82f-49a8-a395-6986d7be2d25@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <3ySadb4ljhHpenFOP9xRX2su1JyWBXWlRv09x--NnBc=.ea4de36e-403b-4cd9-831a-a80aacfcfde5@github.com>
 <uMdZTwppO7EQl5tj8ltFV0HDcIG41gHH2fRo7yQN_MI=.fdfeac6b-dd29-4580-aec0-8a9d4933c26f@github.com>
 <r4Jq9gM2GkBVZaTpjsTiRtmfYDqFbG5vfZB73pm4di0=.9a8b2793-b82f-49a8-a395-6986d7be2d25@github.com>
Message-ID: <97fQvq2H2iV-UmT7CnECiBAza6fhFXdexNzkyPOaThc=.482af2ba-78a5-4201-b1b5-476d24c93f39@github.com>

On Tue, 15 Jul 2025 20:24:22 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java line 201:
>> 
>>> 199:             int len  = (dlen < slen) ? dlen : slen;
>>> 200:             try {
>>> 201:                 int ret = len <= 0 ? 0 : encodeISOArray(sa, sp, da, dp, len);
>> 
>> Moving the length correction into `encodeISOArray` would help other callers too.  (There's only 1 at the moment).
>
> I've tried to make the code such that wrapper functions contain nothing but argument checks. Moving `if (len <= 0) { return 0; }` logic to the wrapper function will introduce a behavior different than the one implemented by the intrinsic. @RogerRiggs, do you still prefer me to carry out this change?

The wrapper is the method actually called, the intrinsic `encodeISOArray0` intrinsic would be inlined into it.
I don't have a compelling reason to change it, given the solitary caller.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2208599130

From egahlin at openjdk.org  Tue Jul 15 20:35:45 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 15 Jul 2025 20:35:45 GMT
Subject: Integrated: 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: <gnX4s9rhD01m4-BYhQKzBIy26ePjOdM1D-0ZoRSK67c=.48fe9e58-60a5-4618-be89-85ad8e71e796@github.com>

On Wed, 9 Jul 2025 05:45:01 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of the change that prevents RandomAccessFile::readLine from emitting an event per character? This leads to unnecessary overhead, both with or without JFR enabled.
> 
> Testing: tier1 + tier2 +  jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 9bef2d16
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9bef2d1610647dec18f9e81cbac3dddbbf99dd6d
Stats:     17 lines in 1 file changed: 15 ins; 0 del; 2 mod

8361640: JFR: RandomAccessFile::readLine emits events for each character

Reviewed-by: rriggs, alanb, mgronlun

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

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

From duke at openjdk.org  Tue Jul 15 21:23:06 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 15 Jul 2025 21:23:06 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v10]
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: <oRx0k_8dCipIoeiCurWb5cYDjKhYW5v4yvcX9sEoHzI=.3a358254-397a-4c5e-bbc7-68837c991307@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:

  Dealing with remaining review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26054/files
  - new: https://git.openjdk.org/jdk/pull/26054/files/332a1c84..5ca0a147

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

  Stats: 50 lines in 1 file changed: 11 ins; 28 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 duke at openjdk.org  Tue Jul 15 21:29:41 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 15 Jul 2025 21:29:41 GMT
Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes [v4]
In-Reply-To: <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
 <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>
Message-ID: <Jgc8MwUte58wkGpNFe9kLavUVHPUXKqpWOmmFvGIR3o=.cb9db67b-2c87-4894-b0c9-21eb4d37d1be@github.com>

On Tue, 1 Jul 2025 17:02:27 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:
> 
>   Adding comment about maintainability.

Oddly while the status at the bottom of the conversation says it has "2 approvals", the tickbox:


Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author


is not checked. I can try to integrate, but it might not work.

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

PR Comment: https://git.openjdk.org/jdk/pull/26044#issuecomment-3075753460

From rriggs at openjdk.org  Tue Jul 15 21:40:42 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 21:40:42 GMT
Subject: RFR: 8360575: java.util.Properties.list() methods trim each value
 to 37 characters in the listed output [v4]
In-Reply-To: <Jy3J4p5L8D4tpKN_-Ghr4VUdrVgnV3YLlKV00Dq-Z9w=.3bbc3090-f954-4526-95f5-0801eb5fd8b2@github.com>
References: <-dRew0C7Qw5REtfjrGiYdfY_bRcnBiUyKXok3lMF9ug=.57d81faf-4a4f-42a9-9238-539a5d0b5625@github.com>
 <Jy3J4p5L8D4tpKN_-Ghr4VUdrVgnV3YLlKV00Dq-Z9w=.3bbc3090-f954-4526-95f5-0801eb5fd8b2@github.com>
Message-ID: <HZtfbwcLWLPdmK_TDUwVzRGec0Y8A4SThOS0CbFlAjk=.9c6fa895-7e14-44c6-8f09-48e83288eefa@github.com>

On Mon, 30 Jun 2025 06:01:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to clarify the current implementation of the `java.util.Properties.list(...)` methods?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8360575, the current implementation trims each value to a size of 37 when printing out the value. This behaviour isn't documented by these methods. The change in this PR adds an `@implNote` to make a mention of this current behaviour.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's review - no need to state the number of characters

The example could get complicated; depending on what output is desired.  The existence of a separate "default" Properties object adds complexity.  
For simplicity, I'd print the direct map elements and then recursively print the default Propertys.
No flattening of the property names and no sorting. 
Keep the example simple, leave the embellishments to whoever copies the example.
Don't try to exactly reproduce the existing method.

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

PR Comment: https://git.openjdk.org/jdk/pull/26018#issuecomment-3075791482

From rriggs at openjdk.org  Tue Jul 15 21:52:45 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 21:52:45 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v3]
In-Reply-To: <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>
Message-ID: <K5Vuk4SylBZ50flNAkTaUQp6fkTGYVcxiK5ZUuo9pxE=.7ecf49f9-00d0-4052-82ec-898125113034@github.com>

On Tue, 15 Jul 2025 20:24:04 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 IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` 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...
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Apply review feedback (styling changes)
>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>  - Remove Markdown-styling in comments
>  - Improve wording of the `VerifyIntrinsicChecks` flag
>  - 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
>    
>    This reverts commit 196fc5d406851b8e7070c97ac53ca59c4615aad9.
>  - Improve intrinsics in `StringCoding`
>  - Add `StringCodingCountPositives` benchmark
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/611f6cea...85f19864

Looks good, thanks for the updates.
A Hotspot reviewer should approve also.

/Reviewers 2 reviewer

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3022453251
PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3075835741

From cjplummer at openjdk.org  Tue Jul 15 22:55:48 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 15 Jul 2025 22:55:48 GMT
Subject: RFR: 8362304: Fix JDWP spec w.r.t. OPAQUE_FRAME and INVALID_SLOT
 errors
Message-ID: <7AfNhcIuQyu2_RsHWcqupjsQ8WnT_eJRvnfI4seyCnQ=.55dfbd37-d226-4ee9-a53f-ee4a3b611a09@github.com>

StackFrame.SetValues, StackFrame.GetValues, ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn all need updated language related to OPAQUE_FRAME error.

(1) The spec for JVMTI says the following for GetLocalsXXX and SetLocalsXXX

  The implementation is unable to set the frame locals
  (e.g. the frame at depth is executing a native method).

However, the JDWP StackFrame.SetValues and GetValues commands only mention OPAQUE_FRAME for SetValues when not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this.

(1) The spec for JVMTI says the following for PopFrame and ForceEarlyReturn:

  The implementation is unable to force the current frame to return
  (e.g. current frame is executing a native method).

However, the JDWP ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn commands only mention OPAQUE_FRAME when this commands are not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this.

(3) Another issue is that INVALID_SLOT is missing in the JDWP spec for SetValues, but is there for GetValues. It should be mentioned for both commands.

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

Commit messages:
 - Update spec w.r.t. OPAQUE_FRAME errors

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

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

From liach at openjdk.org  Tue Jul 15 23:55:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Jul 2025 23:55:41 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v6]
In-Reply-To: <JdxWpCBHtTssvz1lu08gRSrJr3So7vxoi5hiopLlxLo=.3931a767-c13c-455a-b631-616cbbd250ff@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <JdxWpCBHtTssvz1lu08gRSrJr3So7vxoi5hiopLlxLo=.3931a767-c13c-455a-b631-616cbbd250ff@github.com>
Message-ID: <GP7yIpTdkZPm-p9_b-rXfastw-RzAGZcNimha75d-88=.674ea830-847d-40a7-beb3-2aa024929a99@github.com>

On Mon, 16 Jun 2025 21:19:45 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>> 
>> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
>> 
>> Testing:
>> - GHA
>> - Local run of tier 2 and jtreg:jdk/java/text
>> - New benchmark: DecimalFormatParseBench
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

Looks reasonable from a code cleanup point of view.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25644#pullrequestreview-3022646136

From almatvee at openjdk.org  Wed Jul 16 02:01:57 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 16 Jul 2025 02:01:57 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v5]
In-Reply-To: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
Message-ID: <A5Xm9sbnXEnmTomhAE3c2x60fEVuDB2fLAhk2tNOQxw=.2f1f95b3-613e-46dc-a547-49e3f56406d7@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 [v4]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26173/files
  - new: https://git.openjdk.org/jdk/pull/26173/files/5ace4034..9e492cb7

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

  Stats: 101 lines in 14 files changed: 13 ins; 34 del; 54 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  Wed Jul 16 02:01:57 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 16 Jul 2025 02:01:57 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v4]
In-Reply-To: <2yrhjotF9K5jqUS7jYObkTxgvNmP7-fKlfitnJt7F4I=.0597991e-7474-400e-9d84-7f65424d47c8@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <2yrhjotF9K5jqUS7jYObkTxgvNmP7-fKlfitnJt7F4I=.0597991e-7474-400e-9d84-7f65424d47c8@github.com>
Message-ID: <qNtx2cUh-3D3fouGoBYPP5gD7A-yjXhoAizNA8jlRFg=.78bffce3-7de1-42d1-8d0a-234a91c7b1ed@github.com>

On Fri, 11 Jul 2025 16:44:05 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 [v3]

8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v4]
 - Fixed all comments except `RuntimeLayout.DEFAULT`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26173#issuecomment-3076467081

From almatvee at openjdk.org  Wed Jul 16 02:01:57 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 16 Jul 2025 02:01:57 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v2]
In-Reply-To: <hUH_cVzi0fFwFfrhHjhHQ31_i9hmWZVh-Z9iDslfXzE=.3190be50-b48f-4d9a-9131-5dfa7bb98563@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>
 <YugxvKu8OSSx0JLzZoEutLfGJHpHCYtSIEeV5mHyD9Q=.b12b2e72-6ac3-4346-9be0-04c72404f418@github.com>
 <hUH_cVzi0fFwFfrhHjhHQ31_i9hmWZVh-Z9iDslfXzE=.3190be50-b48f-4d9a-9131-5dfa7bb98563@github.com>
Message-ID: <3A4ZUDviK5WDSkj7YsBmk7lhu_gatXv3GvCZsnSZXEM=.28c456f9-b085-4403-9b78-715d17305e13@github.com>

On Mon, 14 Jul 2025 23:08:53 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> I need it inside `createMacApplication()` before `MacApplication` instance is created.
>
> If you need a property of a `MacApplication` instance, create it and get the property.
> `MacApplicationBuilder.validatedBundleIdentifier()` function is internal and should not be used outside of `MacApplicationBuilder`.
> 
> It is OK to call `MacApplicationBuilder.create()` multiple times. See how this is done in [LinuxPackageBuilder.java](https://github.com/openjdk/jdk/blob/f36147b3263662229e9a0ec712b9748711d2d85d/src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBuilder.java#L48)

Fixed.

>> 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?
>
> Please file a bug to address the hardcoded value of the `CFBundleDevelopmentRegion`. We may decide later what to do with it: change it to `en-US`, remove it, or add a new cli option to set it.

Done. [JDK-8362335](https://bugs.openjdk.org/browse/JDK-8362335).

>> Copy-paste. Forgot to update description. I fixed it. `runtimeImageDir` is a value of `--runtime-image` in case of runtime installer.
>
>> runtimeImageDir is a value of --runtime-image in case of runtime installer.
> 
> This duplicates `Package.predefinedAppImage()` function. In case of runtime packaging, the "predefined app image" should be the value of `--runtime-image`. Can you evaluate if you can use `Package.predefinedAppImage()` function instead of adding a new one?

`predefinedAppImage(): Optional.empty` - it is empty. I updated code to re-use it for runtime installers and renamed to `predefinedAppOrRuntimeImage ()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2208825286
PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2208876258
PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2208936239

From almatvee at openjdk.org  Wed Jul 16 02:01:57 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 16 Jul 2025 02:01:57 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v4]
In-Reply-To: <LKaTQFnvBSfVGI3bzRhI3FhvwelWBOhOONZOnSh4p6c=.f4827965-0db6-4ac6-8649-8daf7e684795@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <2yrhjotF9K5jqUS7jYObkTxgvNmP7-fKlfitnJt7F4I=.0597991e-7474-400e-9d84-7f65424d47c8@github.com>
 <LKaTQFnvBSfVGI3bzRhI3FhvwelWBOhOONZOnSh4p6c=.f4827965-0db6-4ac6-8649-8daf7e684795@github.com>
Message-ID: <dh_2zxHcVIR6zTbQ77Nm3mmZyNq158oAT9OZjFyRWDk=.51535bb9-93cc-4d59-902c-293d90131716@github.com>

On Mon, 14 Jul 2025 23:25:58 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 [v3]
>
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacFromParams.java line 221:
> 
>> 219:         return IOUtils.exists(path1)
>> 220:                 && path1.toFile().list() != null
>> 221:                 && path1.toFile().list().length > 0
> 
> This will result in reading the directory contents twice.
> Do this instead:
> 
> Optional.ofNullable(path1.toFile().list()).map(list -> list.length > 0).orElse(false)

Fixed.

> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacFromParams.java line 223:
> 
>> 221:                 && path1.toFile().list().length > 0
>> 222:                 && IOUtils.exists(path2)
>> 223:                 && IOUtils.exists(path3);
> 
> Please don't use `IOUtils.exists()` and other redundant wrappers over the `Files` class in the new code. Use `Files.exists()` instead.

Fixed.

> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacFromParams.java line 238:
> 
>> 236:             return false;
>> 237:         } catch (IOException ex) {
>> 238:             throw new RuntimeException(ex);
> 
> Should be either
> 
> ExceptionBox.rethrowUnchecked(ex);
> 
> 
> or
> 
> throw new UncheckedIOException(ex);

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2208832222
PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2208832346
PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2208860884

From almatvee at openjdk.org  Wed Jul 16 02:01:57 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 16 Jul 2025 02:01:57 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v5]
In-Reply-To: <uRcsfxSIZZqqLhEmU4Pi2DBkLlMuzcOzf34ACGVT1B4=.9ef2af43-8c56-4e0b-a02d-46002db16de3@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>
 <Rqjl9y0pqY-kiAV0BA9ik-vBIahRO5jn7Wg4QoMYn0s=.7a39146b-3e54-4595-b7c8-0d09e9904d88@github.com>
 <XMtc8TtESzI62lRz8QIwj_Ry-S1uYQbe1bm-bWFy3ug=.30fd8e4d-2484-4596-9478-74e8c10e19d5@github.com>
 <RIBt4nBLrafRvEf1RMOYnlK_gXuqz9XAZ9XEv9knBQQ=.1c516030-9e0f-426e-8bdf-fe466231ac61@github.com>
 <zyMhnDNFA2fBmFNLw8YQ13CmfgTqUbJkLWywrUxbOHM=.7c4dd792-7ff9-4397-8f4a-1eb00f64f939@github.com>
 <qf6nbCdHaeeu4X-t4B2JBRngl6ttgZVuoO5d1wohnJU=.e00038d7-03c5-462f-be2d-2ef35d961083@github.com>
 <YzJ8yWN3aOGiV3QJ9FECKdWJQJKL3XvWl1FQylq_cSM=.65e4c40a-7293-4c3a-8c69-1ad69beeeea0@github.com>
 <5UAfUJRT3rIO5twWDl7kY37boUoh5bN4z20PBEoR-sw=.e3db1531-931c-4373-800a-81408da99de2@github.com>
 <uRcsfxSIZZqqLhEmU4Pi2DBkLlMuzcOzf34
 ACGVT1B4=.9ef2af43-8c56-4e0b-a02d-46002db16de3@github.com>
Message-ID: <FwscVPlII0DW9YfjrPKY5EZBJITGTxXmulSzo9OqeGM=.dbaa8abe-6572-4594-8b42-ba70afd3a2d0@github.com>

On Tue, 15 Jul 2025 02:31:03 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> [19:14:45.620] jdk.jpackage.internal.model.PackagerException: java.lang.ClassCastException: class com.sun.proxy.jdk.proxy1.$Proxy0 cannot be cast to class jdk.jpackage.internal.MacApplicationLayout (com.sun.proxy.jdk.proxy1.$Proxy0 is in module jdk.proxy1 of loader 'app'; jdk.jpackage.internal.MacApplicationLayout is in module jdk.jpackage of loader 'app')
>> 	at jdk.jpackage/jdk.jpackage.internal.PackagingPipeline.execute(PackagingPipeline.java:487)
>> 	at jdk.jpackage/jdk.jpackage.internal.PackagingPipeline.execute(PackagingPipeline.java:68)
>> 	at jdk.jpackage/jdk.jpackage.internal.PackagerBuilder.execute(PackagerBuilder.java:67)
>> 	at jdk.jpackage/jdk.jpackage.internal.MacDmgPackager$Builder.execute(MacDmgPackager.java:81)
>> 	at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:80)
>> 	at jdk.jpackage/jdk.jpackage.internal.Arguments.executeBundler(Arguments.java:741)
>> 	at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:702)
>> 	at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:553)
>> 	at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:93)
>> 	at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:54)
>> Caused by: java.lang.ClassCastException: class com.sun.proxy.jdk.proxy1.$Proxy0 cannot be cast to class jdk.jpackage.internal.MacApplicationLayout (com.sun.proxy.jdk.proxy1.$Proxy0 is in module jdk.proxy1 of loader 'app'; jdk.jpackage.internal.MacApplicationLayout is in module jdk.jpackage of loader 'app')
>> 	at jdk.jpackage/jdk.jpackage.internal.MacPackagingPipeline.signApplicationBundle(MacPackagingPipeline.java:367)
>> 	at jdk.jpackage/jdk.jpackage.internal.PackagingPipeline$DefaultTaskContext.execute(PackagingPipeline.java:571)
>> 	at jdk.jpackage/jdk.jpackage.internal.MacPackagingPipeline$TaskContextProxy.execute(MacPackagingPipeline.java:541)
>> 	at jdk.jpackage/jdk.jpackage.internal.PackagingPipeline.lambda$createTask$0(PackagingPipeline.java:604)
>> 	at jdk.jpackage/jdk.jpackage.internal.pipeline.TaskPipelineBuilder$SequentialWrapperTask.call(TaskPipelineBuilder.java:130)
>> 	at jdk.jpackage/jdk.jpackage.internal.pipeline.TaskPipelineBuilder$SequentialWrapperTask.call(TaskPipelineBuilder.java:121)
>> 	at jdk.jpackage/jdk.jpackage.internal.PackagingPipeline.execute(PackagingPipeline.java:480)
>> 	... 9 more
>> java.lang.ClassCastException: class com.sun.proxy.jdk.proxy1.$Proxy0 cannot be cast to class jdk.jpackage.internal.MacApplicationLayout (com.sun.proxy.jdk.proxy1.$P...
>
> Try to change the signature from
> 
> private static void signApplicationBundle(AppImageBuildEnv<MacApplication, MacApplicationLayout> env) throws IOException
> 
> 
> to
> 
> private static void signApplicationBundle(AppImageBuildEnv<MacApplication, AppImageLayout> env) throws IOException
> 
> 
> I guess if you change the signature or the original `sign()` from:
> 
> void sign(AppImageBuildEnv<MacApplication, MacApplicationLayout> env) throws IOException
> 
> to
> 
> void sign(AppImageBuildEnv<MacApplication, AppImageLayout> env) throws IOException
> 
> and use it instead of `signRuntimeBundle()` and `signApplicationBundle()` it will work too.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2208795140

From liach at openjdk.org  Wed Jul 16 03:47:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Jul 2025 03:47:47 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v3]
In-Reply-To: <tCyx-XkttQoAnJcEOtC8SITb9NaurEROV_OjT-E3Imc=.320d74bc-5aa1-4d8a-9867-c767dea379c5@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <tCyx-XkttQoAnJcEOtC8SITb9NaurEROV_OjT-E3Imc=.320d74bc-5aa1-4d8a-9867-c767dea379c5@github.com>
Message-ID: <HqvVuIWQebPbrUO4vmzPa7GKBNsED6VFDMj91n9F8Is=.6d578cbf-a588-400e-b6a4-8f6b2347d027@github.com>

On Fri, 11 Jul 2025 19:02:31 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
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   "may be non-atomic"

I think @mcimadamore and @JornVernee still disagree with this - they think "atomic" can mean a CAS operation as a whole is atomic, or an individual memory access (read, write) in the CAS is. This atomicity here is lacking for the individual memory access, which is the weaker form of atomicity.

On another look, I think another way to address this problem could be to move this "potential lack of atomicity in memory access" to "get" and "set" themselves - which also applies to unaligned access and other var handles. Then, for aligned access through VH, the VH just specify it implements all access modes and upholds all atomicity guarantees of those modes (with respect to other threads)

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

PR Comment: https://git.openjdk.org/jdk/pull/26258#issuecomment-3076627776

From xgong at openjdk.org  Wed Jul 16 03:50:48 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 16 Jul 2025 03:50:48 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: <RiH-f1jWdv6b1MofV0nkX75meE6Y5dQBWhueyr5BEuA=.4b6be574-3140-47c5-9939-680bda41a624@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

Ping again! 
Hi, may I have another approval? Thanks in advance! 
Hi @theRealAph , would you mind taking another looking at the latest commit please? Thanks a lot!

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

PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3076631092

From darcy at openjdk.org  Wed Jul 16 04:57:49 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 16 Jul 2025 04:57:49 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
Message-ID: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>

Add `@Stable` to the static final arrays used in the Java port of FDLIBM.

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

Commit messages:
 - JDK-8362376: Use @Stable annotation in Java FDLIBM implementation

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

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

From darcy at openjdk.org  Wed Jul 16 04:57:49 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 16 Jul 2025 04:57:49 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
In-Reply-To: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
Message-ID: <1GGHiXbVpQ_zLCbn8NFfgLytv2sIugdpmRZ2rcD_wMQ=.2b81a821-aae3-4492-9953-769300308577@github.com>

On Wed, 16 Jul 2025 04:53:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.

Some small refactorings could be used to make a few non-static arrays static.

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

PR Comment: https://git.openjdk.org/jdk/pull/26341#issuecomment-3076738696

From thomas.stuefe at gmail.com  Wed Jul 16 05:26:19 2025
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 16 Jul 2025 07:26:19 +0200
Subject: How important is jspawnhelper crash detection?
In-Reply-To: <132c3aaf-138a-44b1-8b6a-f8ac188854ce@oracle.com>
References: <CAA-vtUzCxv=KtGWnVCbXzBKdg5FPuYodqWmmcU2iz+t0SHdUnA@mail.gmail.com>
 <132c3aaf-138a-44b1-8b6a-f8ac188854ce@oracle.com>
Message-ID: <CAA-vtUxSob-rEnYk=XDH37-0n6sEOkr7BzTSDkehNetJ6qRfzw@mail.gmail.com>

Thanks, Roger, I will proceed with removing the old workaround then.

On Tue, Jul 15, 2025 at 5:05?PM Roger Riggs <roger.riggs at oracle.com> wrote:

> Hi Thomas,
>
> Simpler is better on both sides of the protocol.
> The version check will have happened before this part of the protocol so
> there's no confusion about matching expectations.
> I agree that removing it is preferred.
>
> Roger
>
>
> On 7/15/25 10:44 AM, Thomas St?fe wrote:
> > Hi,
> >
> > I am currently working on removing (eventually) the vfork mode. Before
> > we can do this, we need a bit better error diagnostics. I do this by
> > gently improving the error handling throughout the code, so that we
> > can generate IOExceptions based on more exact knowledge.
> >
> > While working at this, I re-examined the "send aliveness ping from
> > jspawnhelper to parent" logic again I introduced back in 2019 as a
> > workaround for an obscure glibc bug with posix_spawn (see
> > https://bugs.openjdk.org/browse/JDK-8223777). I found that it was not
> > needed anymore since the glibc was fixed, so I started removing that
> > workaround (https://bugs.openjdk.org/browse/JDK-8362257).
> >
> > But then it occurred to me that an obscure part of the jspawnhelper
> > diagnostics introduced with
> > https://bugs.openjdk.org/browse/JDK-8226242 piggy-backs on the
> > aliveness ping for its
> > "detect-abnormal-process-termination-before-exec" capabilities. Works
> > like this:
> >
> > A jspawnhelper starts
> > B jspawnhelper enters childProcess() and sends alivenes ping
> > C jspawnhelper does a bunch of other things
> > D jspawnhelper exec's
> >
> > In the parent, we count abnormal child terminations that occur before
> > the aliveness ping (B) as "spawn error" and print the signal number.
> > Without the aliveness ping we could not tell apart "jspawnhelper ends
> > abnormally due to a signal" from "jspawnhelper exec()'s the user
> > program successfully, user program runs and ends abnormally due to
> > signal".
> >
> > However, the question is how important or even useful this part really
> is:
> > - for externally sent abnormal termination signals (SIGTERM etc), from
> > the caller's point of view it probably does not matter when it comes :
> > before or after exec().
> > - it only matters for synchronous termination signals (crashes) we
> > ourselves cause; but here it only covers crashes in a rather small
> > piece of code, before the liveness ping (B). Basically, just the first
> > part of jspawnhelper main(). Any crashes after the liveness ping are
> > still unrecognised by ProcessBuilder.start, and are instead handled by
> > the caller calling Process.waitFor().
> >
> > There are two ways to deal with this:
> >
> > We could do without the crash protection in point (A), which would
> > allow us to remove the liveness ping. I would very much prefer that.
> > It would simplify the jspawnhelper protocol and make it more robust.
> > Because we now don't have any communication in case no error happens -
> > there would be only a single bit of information sent back via fail
> > pipe, and only in case of an error. Fail pipe would stay quiet in case
> > of successful exec(). Abnormal child process termination in the first
> > part of jspawnhelper would be covered by the same path that detects
> > abnormal child process termination in user programs - Process.waitFor().
> >
> > If we determine we really need this crash detection, we could at least
> > improve it: move the liveness ping to just-before the exec() call, so
> > that we cover all the area from A-D. Also, do it for all modes (FORK,
> > too), to simplify coding.
> >
> > Bottomline: remove an obscure and complex small mechanism that only
> > helps a bit with detecting program errors (sigsegv etc) inside the
> > first part of jspawnhelper main() ?
> >
> > Thanks, Thomas
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250716/78d446ef/attachment.htm>

From thartmann at openjdk.org  Wed Jul 16 05:32:45 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 16 Jul 2025 05:32:45 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v3]
In-Reply-To: <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>
Message-ID: <4zqK_rAHpX2bdDGf_kw2TOXtdOgONZykPs7mlR-rDrA=.d7d2bcd4-1e48-40ed-9628-46a681a5c4bb@github.com>

On Tue, 15 Jul 2025 20:24:04 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 IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` 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...
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Apply review feedback (styling changes)
>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>  - Remove Markdown-styling in comments
>  - Improve wording of the `VerifyIntrinsicChecks` flag
>  - 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
>    
>    This reverts commit 196fc5d406851b8e7070c97ac53ca59c4615aad9.
>  - Improve intrinsics in `StringCoding`
>  - Add `StringCodingCountPositives` benchmark
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/32d96877...85f19864

Thanks a lot for working on this, Volkan! The changes look good to me, I just added two comments.

src/hotspot/share/opto/c2_globals.hpp line 665:

> 663:           "prints attempted and successful inlining of intrinsics")         \
> 664:                                                                             \
> 665:   develop(bool, VerifyIntrinsicChecks, false,                               \

We should add testing that uses this new flag. Maybe we could add a run to the tests that check the affected intrinsics? We could also add it to our (Oracle internal) stress test jobs at higher tiers.

src/hotspot/share/opto/library_call.cpp line 971:

> 969:     } else {
> 970:       PreserveJVMState pjvms(this);
> 971:       set_control(_gvn.transform(bailout));

Suggestion:

    bailout = _gvn.transform(bailout);
    if (halt) {
      Node* frame = _gvn.transform(new ParmNode(C->start(), TypeFunc::FramePtr));
      Node* halt = _gvn.transform(new HaltNode(bailout, frame, "unexpected guard failure in intrinsic"));
      C->root()->add_req(halt);
    } else {
      PreserveJVMState pjvms(this);
      set_control(bailout);

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3023137214
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2209259866
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2209245394

From alanb at openjdk.org  Wed Jul 16 05:46:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Jul 2025 05:46:44 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v10]
In-Reply-To: <oRx0k_8dCipIoeiCurWb5cYDjKhYW5v4yvcX9sEoHzI=.3a358254-397a-4c5e-bbc7-68837c991307@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <oRx0k_8dCipIoeiCurWb5cYDjKhYW5v4yvcX9sEoHzI=.3a358254-397a-4c5e-bbc7-68837c991307@github.com>
Message-ID: <F5V9Ah0_tc3jn2-fgCLGUynhZxbDETPkMQ6__r1E6Co=.9d7c85d5-1d83-493f-ba01-46cf435f5820@github.com>

On Tue, 15 Jul 2025 21:23:06 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:
> 
>   Dealing with remaining review comments.

Would it be possible to sync up the PR as it is a few weeks behind main line and there are merge conflicts.

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

PR Comment: https://git.openjdk.org/jdk/pull/26054#issuecomment-3076870489

From syan at openjdk.org  Wed Jul 16 05:50:42 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 16 Jul 2025 05:50:42 GMT
Subject: RFR: 8362207: Add more test cases for possible double-rounding in
 fma
In-Reply-To: <vo6ZFgc9-NCGHZcd5ftuMzaH2aswSB6rkclyJknn7BI=.45bf8bdf-5d0f-4751-b694-a294f8820b35@github.com>
References: <vo6ZFgc9-NCGHZcd5ftuMzaH2aswSB6rkclyJknn7BI=.45bf8bdf-5d0f-4751-b694-a294f8820b35@github.com>
Message-ID: <4ME1-2rbZ2AGLlVarLHHuHdWQwlZdr1h0EVeCfeh1wo=.892087fc-5579-45a9-a0fb-f29de7a5f80b@github.com>

On Tue, 15 Jul 2025 01:10:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> From discussions related to IEEE 754, a few explicit test cases were identified where plausible, but incorrect, implementations of fma using higher precision. These test cases are useful to include in the regression tests of the float-precision and Float16-precision fused multiple add methods.

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26305#pullrequestreview-3023212253

From darcy at openjdk.org  Wed Jul 16 05:50:43 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 16 Jul 2025 05:50:43 GMT
Subject: Integrated: 8362207: Add more test cases for possible double-rounding
 in fma
In-Reply-To: <vo6ZFgc9-NCGHZcd5ftuMzaH2aswSB6rkclyJknn7BI=.45bf8bdf-5d0f-4751-b694-a294f8820b35@github.com>
References: <vo6ZFgc9-NCGHZcd5ftuMzaH2aswSB6rkclyJknn7BI=.45bf8bdf-5d0f-4751-b694-a294f8820b35@github.com>
Message-ID: <4gNg0u1S994R1_JHUNsZvt3Zo4-5KDPfJLNV3KLLiYU=.4a7c2388-eee3-4b02-9630-78ffb4b50a35@github.com>

On Tue, 15 Jul 2025 01:10:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> From discussions related to IEEE 754, a few explicit test cases were identified where plausible, but incorrect, implementations of fma using higher precision. These test cases are useful to include in the regression tests of the float-precision and Float16-precision fused multiple add methods.

This pull request has now been integrated.

Changeset: 6e368e0c
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6e368e0c696bc9b2118014937aa2e091ea662985
Stats:     12 lines in 2 files changed: 6 ins; 0 del; 6 mod

8362207: Add more test cases for possible double-rounding in fma

Reviewed-by: rgiulietti, syan

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

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

From alanb at openjdk.org  Wed Jul 16 06:05:39 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Jul 2025 06:05:39 GMT
Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes [v3]
In-Reply-To: <E4dW0zQJNkVozaAP9rjlBDv-wTEtRKMl0OotVJY-9Tg=.d96625fd-17be-4418-96ad-6de5746ea9b7@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>
 <E4dW0zQJNkVozaAP9rjlBDv-wTEtRKMl0OotVJY-9Tg=.d96625fd-17be-4418-96ad-6de5746ea9b7@github.com>
Message-ID: <wvZd3CoYrWXVH3oxRnrShgse8MQFTXdVlI0nXML1dbY=.a7a23b3c-e9d9-42fb-9248-4271b79d1785@github.com>

On Tue, 1 Jul 2025 16:50:09 GMT, David Beaumont <duke at openjdk.org> wrote:

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

lib/classlist is used to generate the AOT archive, I wonder if a `@Setup` could be used to consume that to create the INIT_CLASSES.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26044#discussion_r2209331471

From syan at openjdk.org  Wed Jul 16 06:13:39 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 16 Jul 2025 06:13:39 GMT
Subject: RFR: 8361888: [GCC static analyzer] ProcessImpl_md.c
 Java_java_lang_ProcessImpl_forkAndExec error: use of uninitialized value
 '*(ChildStuff *)p.mode
In-Reply-To: <0P03-vXLWU8JpjLpa6V8XpTCx0UPsNdHEr4Qi-c4qQQ=.25239ad9-2a3e-4602-8192-3a0dd302796f@github.com>
References: <0P03-vXLWU8JpjLpa6V8XpTCx0UPsNdHEr4Qi-c4qQQ=.25239ad9-2a3e-4602-8192-3a0dd302796f@github.com>
Message-ID: <3LpSs8J2M4Squi9XJlW53CygCBIQ8G4j7bl4-7f1P8o=.94b6aded-ae28-410d-a1aa-76bfa19fe1d2@github.com>

On Tue, 15 Jul 2025 12:51:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using GCC static analyzer (-fanalyzer), the following issue is reported.
> Seems `c->mode` is initialized later in the method, but we use it already in the exception, this looks wrong.
> 
> 
> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c: In function 'Java_java_lang_ProcessImpl_forkAndExec':
> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:735:9: error: use of uninitialized value '*(ChildStuff *)p.mode' [CWE-457] [-Werror=analyzer-use-of-uninitialized-value]
>   735 | throwInternalIOException(env, errno, "Bad file descriptor", c->mode);
>       | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26316#pullrequestreview-3023289329

From mbaesken at openjdk.org  Wed Jul 16 07:24:45 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Jul 2025 07:24:45 GMT
Subject: RFR: 8361888: [GCC static analyzer] ProcessImpl_md.c
 Java_java_lang_ProcessImpl_forkAndExec error: use of uninitialized value
 '*(ChildStuff *)p.mode
In-Reply-To: <0P03-vXLWU8JpjLpa6V8XpTCx0UPsNdHEr4Qi-c4qQQ=.25239ad9-2a3e-4602-8192-3a0dd302796f@github.com>
References: <0P03-vXLWU8JpjLpa6V8XpTCx0UPsNdHEr4Qi-c4qQQ=.25239ad9-2a3e-4602-8192-3a0dd302796f@github.com>
Message-ID: <Ckpu4v2WX0yW-yFlK1NY7FIUJhL7Shsy80knh4a2ItQ=.a3f237b4-96e3-4296-846c-462b7877cad9@github.com>

On Tue, 15 Jul 2025 12:51:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using GCC static analyzer (-fanalyzer), the following issue is reported.
> Seems `c->mode` is initialized later in the method, but we use it already in the exception, this looks wrong.
> 
> 
> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c: In function 'Java_java_lang_ProcessImpl_forkAndExec':
> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:735:9: error: use of uninitialized value '*(ChildStuff *)p.mode' [CWE-457] [-Werror=analyzer-use-of-uninitialized-value]
>   735 | throwInternalIOException(env, errno, "Bad file descriptor", c->mode);
>       | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/26316#issuecomment-3077280423

From mbaesken at openjdk.org  Wed Jul 16 07:24:46 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Jul 2025 07:24:46 GMT
Subject: Integrated: 8361888: [GCC static analyzer] ProcessImpl_md.c
 Java_java_lang_ProcessImpl_forkAndExec error: use of uninitialized value
 '*(ChildStuff *)p.mode
In-Reply-To: <0P03-vXLWU8JpjLpa6V8XpTCx0UPsNdHEr4Qi-c4qQQ=.25239ad9-2a3e-4602-8192-3a0dd302796f@github.com>
References: <0P03-vXLWU8JpjLpa6V8XpTCx0UPsNdHEr4Qi-c4qQQ=.25239ad9-2a3e-4602-8192-3a0dd302796f@github.com>
Message-ID: <39-6DJxf38IS2bC2HG8v_o2BVuuS19CS7DgfBE2qzFM=.b21e71d9-51fa-4f3a-84c1-9d3ed2588958@github.com>

On Tue, 15 Jul 2025 12:51:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using GCC static analyzer (-fanalyzer), the following issue is reported.
> Seems `c->mode` is initialized later in the method, but we use it already in the exception, this looks wrong.
> 
> 
> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c: In function 'Java_java_lang_ProcessImpl_forkAndExec':
> /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:735:9: error: use of uninitialized value '*(ChildStuff *)p.mode' [CWE-457] [-Werror=analyzer-use-of-uninitialized-value]
>   735 | throwInternalIOException(env, errno, "Bad file descriptor", c->mode);
>       | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This pull request has now been integrated.

Changeset: b85440d0
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b85440d085e8f17908d2e8bd0fee87fce84a74a0
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8361888: [GCC static analyzer] ProcessImpl_md.c Java_java_lang_ProcessImpl_forkAndExec error: use of uninitialized value '*(ChildStuff *)p.mode

Reviewed-by: rriggs, syan

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

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

From alanb at openjdk.org  Wed Jul 16 07:31:41 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Jul 2025 07:31:41 GMT
Subject: [jdk25] RFR: 8361587: AssertionError in File.listFiles() when path
 is empty and -esa is enabled
In-Reply-To: <hHrBHeN228ckHTQIXzKiGU6XiUX76kjt6GNi4wxFG6w=.c3541c21-9091-43da-86ed-4af5b38c1bd1@github.com>
References: <hHrBHeN228ckHTQIXzKiGU6XiUX76kjt6GNi4wxFG6w=.c3541c21-9091-43da-86ed-4af5b38c1bd1@github.com>
Message-ID: <hphb1mtCZGGrQ2ZTJKle5zD2dxHQV40wTl1B-CRTPpo=.4f89b4ae-a2c5-47e3-af5e-b4d2214f2c48@github.com>

On Tue, 15 Jul 2025 18:21:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [eefbfdce](https://github.com/openjdk/jdk/commit/eefbfdce315237eeec4aceceb476d86314304e81) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Brian Burkhalter on 15 Jul 2025 and was reviewed by Alan Bateman.
> 
> Thanks!

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26327#pullrequestreview-3023555090

From vyazici at openjdk.org  Wed Jul 16 07:51:26 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 16 Jul 2025 07:51:26 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v4]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <3L2KmYco1fW5Or9Lzhp17mW-Pk-ANOp5UYQ6sL3gZfs=.d7560969-8b3f-478f-a89d-2c34cf875ec9@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` 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");
>         }
>     }
> }
> ...

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

  Improve `generate_string_range_check` changes
  
  Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/85f19864..2b89e880

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

  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 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 rgiulietti at openjdk.org  Wed Jul 16 09:31:41 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 16 Jul 2025 09:31:41 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v3]
In-Reply-To: <tCyx-XkttQoAnJcEOtC8SITb9NaurEROV_OjT-E3Imc=.320d74bc-5aa1-4d8a-9867-c767dea379c5@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <tCyx-XkttQoAnJcEOtC8SITb9NaurEROV_OjT-E3Imc=.320d74bc-5aa1-4d8a-9867-c767dea379c5@github.com>
Message-ID: <KPkEWeFIcUBE3Xw611x9c2LDSucL0gO3BBQNS9tcd5w=.6302fefc-3bc0-48c7-aac4-83676ce7cd66@github.com>

On Fri, 11 Jul 2025 19:02:31 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
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   "may be non-atomic"

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 281:

> 279:  * <li>read write access modes for all {@code T}. On 32-bit platforms, access modes
> 280:  *     {@code get} and {@code set} for {@code long}, {@code double} and {@code MemorySegment}
> 281:  *     are supported but may be non-atomic, as described in Section {@jls 17.7}

Suggestion:

 *     are supported but may be non-atomic in the sense of Section {@jls 17.7}


A useful taxonomy has atomic _read-modify-write_ operations (atomic updates, numeric atomic updates, bitwise atomic updates, like CASes, etc.), and atomic _access_ operations, that is, atomic loads and stores (atomic reads and writes).

But the reference to the JLS section here should clarify what is meant in this specific context, namely access operation, not read-modify-write operations.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4310:

> 4308:      * <li>read write access modes for all {@code T}. On 32-bit platforms,
> 4309:      *     access modes {@code get} and {@code set} for {@code long}, {@code
> 4310:      *     double} are supported but may be non-atomic, as described in Section

Suggestion:

     *     double} are supported but may be non-atomic in the sense of Section

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26258#discussion_r2209793287
PR Review Comment: https://git.openjdk.org/jdk/pull/26258#discussion_r2209793415

From jpai at openjdk.org  Wed Jul 16 09:31:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Jul 2025 09:31:46 GMT
Subject: RFR: 8361587: AssertionError in File.listFiles() when path is
 empty and -esa is enabled [v8]
In-Reply-To: <CZboh0l2JIXaw4kzPpiVVZCKM4Ic_EMbwni0XKaVrTA=.6f5b4655-2456-416d-a4ba-f32d4be6361d@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <CZboh0l2JIXaw4kzPpiVVZCKM4Ic_EMbwni0XKaVrTA=.6f5b4655-2456-416d-a4ba-f32d4be6361d@github.com>
Message-ID: <wPphAluu7QpZpUlLbvLqeLjSB1tpoYkyq1Wt5zcV174=.239e046f-27b2-4ba9-85a1-ba153abb6f4c@github.com>

On Tue, 15 Jul 2025 17:36:22 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: Fix mkdirs sub-test

Hello Brian, I'm late to this discussion. I think there are a couple of more places in this code which need attention. The private `File` constructor which has this `assert` gets invoked from 3 different `File.listFiles()` methods. One of them has now been fixed in this PR. However, 2 other `listFiles()` methods continue to exhibit this issue.

I updated the `test/jdk/java/io/File/EmptyPath.java` with a couple of more test methods:


diff --git a/test/jdk/java/io/File/EmptyPath.java b/test/jdk/java/io/File/EmptyPath.java
index d0c9beddc08..b747c61f5d1 100644
--- a/test/jdk/java/io/File/EmptyPath.java
+++ b/test/jdk/java/io/File/EmptyPath.java
@@ -28,8 +28,10 @@
  */
 
 import java.io.File;
+import java.io.FileFilter;
 import java.io.FileInputStream;
 import java.io.FileNotFoundException;
+import java.io.FilenameFilter;
 import java.io.IOException;
 import java.nio.file.Files;
 import java.nio.file.FileStore;
@@ -242,6 +244,19 @@ public void listFiles() throws IOException {
         assertEquals(nioSet, ioSet);
     }
 
+
+    @Test
+    public void listFiles2() throws IOException {
+        final File f = new File("");
+        final File[] files = f.listFiles((FileFilter) null);
+    }
+
+    @Test
+    public void listFiles3() throws IOException {
+        final File f = new File("");
+        final File[] files = f.listFiles((FilenameFilter) null);
+    }
+



These 2 new test methods continue to fail against mainline master which has the changes integrated from this PR:


java.lang.AssertionError
    at java.base/java.io.File.<init>(File.java:267)
    at java.base/java.io.File.listFiles(File.java:1212)
    at EmptyPath.listFiles2(EmptyPath.java:251)
    at java.base/java.lang.reflect.Method.invoke(Method.java:565)
    at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
    at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
FAILED     EmptyPath::listFiles2 'listFiles2()' [2ms]
java.lang.AssertionError
    at java.base/java.io.File.<init>(File.java:267)
    at java.base/java.io.File.listFiles(File.java:1180)
    at EmptyPath.listFiles3(EmptyPath.java:257)
    at java.base/java.lang.reflect.Method.invoke(Method.java:565)
    at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
    at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
FAILED     EmptyPath::listFiles3 'listFiles3()' [0ms]

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

PR Comment: https://git.openjdk.org/jdk/pull/26224#issuecomment-3077737570

From rgiulietti at openjdk.org  Wed Jul 16 10:04:48 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 16 Jul 2025 10:04:48 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
Message-ID: <B8rouVL6Ecjm0lIqzwSjvhICoV_QonD06LqMZ853tFw=.575fe02c-f7b5-4f46-857a-c591a62a1bcd@github.com>

On Sat, 12 Jul 2025 09:18:27 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed useless instruction

src/java.base/share/classes/java/math/BigInteger.java line 2755:

> 2753:      * is even and this BigInteger is negative, an {@code ArithmeticException} will be
> 2754:      * thrown.
> 2755:      *

I think this specification is a bit confusing.
For example, when x = -10 and n = 2, then y = -3 has the same sign of x and its magnitude r = 3 is the largest integer meeting r^n ? |x|. However, y is not a solution. Sure, there's the note about negative x and even n, but that should emerge as a property from the definition, not as an additional condition.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2209865612

From duke at openjdk.org  Wed Jul 16 10:11:41 2025
From: duke at openjdk.org (Pooja-DP)
Date: Wed, 16 Jul 2025 10:11:41 GMT
Subject: RFR: 8361697: Remove duplicate message in MainResources.properties
In-Reply-To: <apRAelAuEvvGzVSK4_pllZvS9hloXO3UE6_2CRuCX28=.0d98fffe-f426-4523-b03d-a9d9bda81799@github.com>
References: <apRAelAuEvvGzVSK4_pllZvS9hloXO3UE6_2CRuCX28=.0d98fffe-f426-4523-b03d-a9d9bda81799@github.com>
Message-ID: <264rIiKsolPEmvZ5ul_R34TzDy_NA0O6LLpjLIvS71Y=.3c0b7232-af6c-4586-b962-80e56c3911b5@github.com>

On Wed, 9 Jul 2025 10:32:47 GMT, Pooja-DP <duke at openjdk.org> wrote:

> Bug reference: https://bugs.openjdk.org/browse/JDK-8361697
> 
> The following message is removed:
> 
> `
> MSG_BundlerFailed=Error: Bundler "{1}" ({0}) failed to produce a package`
> 
> Signed-off-by: Pooja.D.P1 <Pooja.D.P1 at ibm.com>

core-libs

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

PR Comment: https://git.openjdk.org/jdk/pull/26215#issuecomment-3077871174

From duke at openjdk.org  Wed Jul 16 10:35:43 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 16 Jul 2025 10:35:43 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <B8rouVL6Ecjm0lIqzwSjvhICoV_QonD06LqMZ853tFw=.575fe02c-f7b5-4f46-857a-c591a62a1bcd@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <B8rouVL6Ecjm0lIqzwSjvhICoV_QonD06LqMZ853tFw=.575fe02c-f7b5-4f46-857a-c591a62a1bcd@github.com>
Message-ID: <pU242ecdIxZSk-uXlfSiXjMX-xNZFq_R6H4kklT1Klw=.27929cce-dcb4-4dab-93d7-cbfb36284c36@github.com>

On Wed, 16 Jul 2025 10:01:00 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed useless instruction
>
> src/java.base/share/classes/java/math/BigInteger.java line 2755:
> 
>> 2753:      * is even and this BigInteger is negative, an {@code ArithmeticException} will be
>> 2754:      * thrown.
>> 2755:      *
> 
> I think this specification is a bit confusing.
> For example, when x = -10 and n = 2, then y = -3 has the same sign of x and its magnitude r = 3 is the largest integer meeting r^n ? |x|. However, y is not a solution. Sure, there's the note about negative x and even n, but that should emerge as a property from the definition, not as an additional condition.

I don't know other ways to define it that don't involve the clause `!(x < 0 && n % 2 == 0)`. If the first definition is confusing, the only solution I see is to remove it, and leave only the formula `(x.signum() * floor(abs(nthRoot(x, n))))`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2209939998

From duke at openjdk.org  Wed Jul 16 11:22:38 2025
From: duke at openjdk.org (serhiysachkov)
Date: Wed, 16 Jul 2025 11:22:38 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: <gY6K1g0MuHzK1M4wtSCw32OCATZiUyZemQACagR8m3E=.07ca376e-ba6a-4846-858f-afbc271cac2e@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

LGTM

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

PR Comment: https://git.openjdk.org/jdk/pull/26193#issuecomment-3078122822

From jpai at openjdk.org  Wed Jul 16 11:30:02 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Jul 2025 11:30:02 GMT
Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP
 replies if Connection is subsequently closed [v3]
In-Reply-To: <VTKn99Us3UFmdorIHejMcIiqSL_Q_ma5Ju25cRbiOeQ=.e7655703-6c7c-487a-a98e-64339edd0197@github.com>
References: <VTKn99Us3UFmdorIHejMcIiqSL_Q_ma5Ju25cRbiOeQ=.e7655703-6c7c-487a-a98e-64339edd0197@github.com>
Message-ID: <3srnJrm0Np7t0RzwkM2lKK9SuMWyQ1EeAR5m65EaD8I=.e1d7ae14-9117-437c-a3a6-027a76146a84@github.com>

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708?
> 
> As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen.
> 
> The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`.
> 
> A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces.
> 
> tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25.

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

 - merge latest from master branch
 - merge latest from master branch
 - add test
 - 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25449/files
  - new: https://git.openjdk.org/jdk/pull/25449/files/5a6012e6..545c41a1

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

  Stats: 33523 lines in 1055 files changed: 19874 ins; 7276 del; 6373 mod
  Patch: https://git.openjdk.org/jdk/pull/25449.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25449/head:pull/25449

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

From duke at openjdk.org  Wed Jul 16 12:03:43 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 16 Jul 2025 12:03:43 GMT
Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes [v3]
In-Reply-To: <wvZd3CoYrWXVH3oxRnrShgse8MQFTXdVlI0nXML1dbY=.a7a23b3c-e9d9-42fb-9248-4271b79d1785@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>
 <E4dW0zQJNkVozaAP9rjlBDv-wTEtRKMl0OotVJY-9Tg=.d96625fd-17be-4418-96ad-6de5746ea9b7@github.com>
 <wvZd3CoYrWXVH3oxRnrShgse8MQFTXdVlI0nXML1dbY=.a7a23b3c-e9d9-42fb-9248-4271b79d1785@github.com>
Message-ID: <eZ9krxtY-kK_m_CVUBJw4MTZsdyAqQD93XTIjSR836A=.8eb895a7-45fc-4d9c-af08-57ce95831ce5@github.com>

On Wed, 16 Jul 2025 06:03:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 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.
>
> lib/classlist is used to generate the AOT archive, I wonder if a `@Setup` could be used to consume that to create the INIT_CLASSES.

I will look at that as a followup action. I'd rather get this in to unblock the main ImageReader refactoring.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26044#discussion_r2210172307

From alanb at openjdk.org  Wed Jul 16 13:32:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Jul 2025 13:32:52 GMT
Subject: RFR: 8361587: AssertionError in File.listFiles() when path is
 empty and -esa is enabled [v8]
In-Reply-To: <wPphAluu7QpZpUlLbvLqeLjSB1tpoYkyq1Wt5zcV174=.239e046f-27b2-4ba9-85a1-ba153abb6f4c@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <CZboh0l2JIXaw4kzPpiVVZCKM4Ic_EMbwni0XKaVrTA=.6f5b4655-2456-416d-a4ba-f32d4be6361d@github.com>
 <wPphAluu7QpZpUlLbvLqeLjSB1tpoYkyq1Wt5zcV174=.239e046f-27b2-4ba9-85a1-ba153abb6f4c@github.com>
Message-ID: <klJ8pNhM7Otr222yfOIM42fjb1UGMNHPan5skF3nxWE=.28bf2472-e4fe-4da9-bf2a-90b664efb31d@github.com>

On Wed, 16 Jul 2025 09:28:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Brian, I'm late to this discussion. I think there are a couple of more places in this code which need attention. The private `File` constructor which has this `assert` gets invoked from 3 different `File.listFiles()` methods. One of them has now been fixed in this PR. However, 2 other `listFiles()` methods continue to exhibit this issue.

@bplb Can you check the test coverage again? Its important that EmptyTest exercises every method.

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

PR Comment: https://git.openjdk.org/jdk/pull/26224#issuecomment-3078633637

From egahlin at openjdk.org  Wed Jul 16 13:34:21 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 16 Jul 2025 13:34:21 GMT
Subject: [jdk25] RFR: 8361640: JFR: RandomAccessFile::readLine emits events for
 each character
Message-ID: <yjEvgVLAHJAL5nN4ZYBLdHacbzsu8MZ7YZE88rtiXYo=.7a42b635-549c-437a-bf32-81dd9f4d494b@github.com>

8361640: JFR: RandomAccessFile::readLine emits events for each character

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

Commit messages:
 - Backport 9bef2d1610647dec18f9e81cbac3dddbbf99dd6d

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

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

From rriggs at openjdk.org  Wed Jul 16 13:37:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 16 Jul 2025 13:37:40 GMT
Subject: RFR: 8361697: Remove duplicate message in MainResources.properties
In-Reply-To: <apRAelAuEvvGzVSK4_pllZvS9hloXO3UE6_2CRuCX28=.0d98fffe-f426-4523-b03d-a9d9bda81799@github.com>
References: <apRAelAuEvvGzVSK4_pllZvS9hloXO3UE6_2CRuCX28=.0d98fffe-f426-4523-b03d-a9d9bda81799@github.com>
Message-ID: <D8ORDX3MugAFDf8yDq39KCJIlCNuJuDnwZzVb0e73NU=.43ca5db4-9727-4771-ba12-0805674dbcca@github.com>

On Wed, 9 Jul 2025 10:32:47 GMT, Pooja-DP <duke at openjdk.org> wrote:

> Bug reference: https://bugs.openjdk.org/browse/JDK-8361697
> 
> The following message is removed:
> 
> `
> MSG_BundlerFailed=Error: Bundler "{1}" ({0}) failed to produce a package`
> 
> Signed-off-by: Pooja.D.P1 <Pooja.D.P1 at ibm.com>

Looks good.  Trivial duplicate removal.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26215#pullrequestreview-3025070264

From mgronlun at openjdk.org  Wed Jul 16 13:41:40 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 16 Jul 2025 13:41:40 GMT
Subject: [jdk25] RFR: 8361640: JFR: RandomAccessFile::readLine emits events
 for each character
In-Reply-To: <yjEvgVLAHJAL5nN4ZYBLdHacbzsu8MZ7YZE88rtiXYo=.7a42b635-549c-437a-bf32-81dd9f4d494b@github.com>
References: <yjEvgVLAHJAL5nN4ZYBLdHacbzsu8MZ7YZE88rtiXYo=.7a42b635-549c-437a-bf32-81dd9f4d494b@github.com>
Message-ID: <is2NJHsYoaGZ16XbUghGsmcZA7VbCsSFikuH1Ua4c_c=.c01ab818-dc43-4c27-af37-143342b7e479@github.com>

On Wed, 16 Jul 2025 13:24:35 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8361640: JFR: RandomAccessFile::readLine emits events for each character

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26349#pullrequestreview-3025094693

From asemenyuk at openjdk.org  Wed Jul 16 13:42:42 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 16 Jul 2025 13:42:42 GMT
Subject: RFR: 8361697: Remove duplicate message in MainResources.properties
In-Reply-To: <apRAelAuEvvGzVSK4_pllZvS9hloXO3UE6_2CRuCX28=.0d98fffe-f426-4523-b03d-a9d9bda81799@github.com>
References: <apRAelAuEvvGzVSK4_pllZvS9hloXO3UE6_2CRuCX28=.0d98fffe-f426-4523-b03d-a9d9bda81799@github.com>
Message-ID: <mmmhi9JoaQuog1O6_RR1LCMCm_qfxovuita5MDrC3Vc=.709f1c18-93ad-4c86-a794-6c2e54371d6a@github.com>

On Wed, 9 Jul 2025 10:32:47 GMT, Pooja-DP <duke at openjdk.org> wrote:

> Bug reference: https://bugs.openjdk.org/browse/JDK-8361697
> 
> The following message is removed:
> 
> `
> MSG_BundlerFailed=Error: Bundler "{1}" ({0}) failed to produce a package`
> 
> Signed-off-by: Pooja.D.P1 <Pooja.D.P1 at ibm.com>

Marked as reviewed by asemenyuk (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26215#pullrequestreview-3025099149

From duke at openjdk.org  Wed Jul 16 13:46:29 2025
From: duke at openjdk.org (cagliostro92)
Date: Wed, 16 Jul 2025 13:46:29 GMT
Subject: RFR: 8358530: Properties#list should warn against non-String
 values [v2]
In-Reply-To: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
References: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
Message-ID: <MEqZG66bQ0oSPbth-RR1GMM5VkF88FxlflfALk9cbmg=.0064a409-df95-44da-baac-3368b7346c21@github.com>

> Trivial PR to enhance Javadoc for the `Properties#list` method, which has cost me some debugging time.

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

  8358530: adds warnings against non-String values in Properties class documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25334/files
  - new: https://git.openjdk.org/jdk/pull/25334/files/7e28926d..8d7e3d2f

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

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

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

From duke at openjdk.org  Wed Jul 16 13:46:29 2025
From: duke at openjdk.org (cagliostro92)
Date: Wed, 16 Jul 2025 13:46:29 GMT
Subject: RFR: 8358530: Properties#list should warn against non-String
 values [v2]
In-Reply-To: <9Wr-amACg6uZeYoPf5Qfo-UwVDVvITaxpcNksaf6xY4=.54c2ac06-5e6d-41af-a4dd-b52b31824143@github.com>
References: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
 <9Wr-amACg6uZeYoPf5Qfo-UwVDVvITaxpcNksaf6xY4=.54c2ac06-5e6d-41af-a4dd-b52b31824143@github.com>
Message-ID: <sn5U00RQ3hVAIuwPMPKcWtbmuwFZNy2hLcgGOleXqFc=.9288a26a-41bf-49ce-9129-63d4a4786470@github.com>

On Tue, 15 Jul 2025 16:29:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> cagliostro92 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8358530: adds warnings against non-String values in Properties class documentation
>
> src/java.base/share/classes/java/util/Properties.java line 78:
> 
>> 76:  * the call to the {@code propertyNames} or {@code list} method
>> 77:  * will fail if it is called on a "compromised" {@code Properties}
>> 78:  * object that contains a non-{@code String} key or value.
> 
> Since `propertyNames` won't throw `CCE` with a non-String value, instead of adding the "or value" wording here, we should move the `list` method to the sentence above and remove it from the current sentence.
> 
> E.g., on line 73 
> 
>> "If the {@code store}, {@code save}, or {@code list) method ...

My bad, sorry. Fixed with 8d7e3d2fde65bd1e4ad85eca5ea93a430e2e8238

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25334#discussion_r2210484938

From alanb at openjdk.org  Wed Jul 16 13:59:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Jul 2025 13:59:40 GMT
Subject: [jdk25] RFR: 8361640: JFR: RandomAccessFile::readLine emits events
 for each character
In-Reply-To: <yjEvgVLAHJAL5nN4ZYBLdHacbzsu8MZ7YZE88rtiXYo=.7a42b635-549c-437a-bf32-81dd9f4d494b@github.com>
References: <yjEvgVLAHJAL5nN4ZYBLdHacbzsu8MZ7YZE88rtiXYo=.7a42b635-549c-437a-bf32-81dd9f4d494b@github.com>
Message-ID: <TanDP2YG961-Qd9yQV_Im-ovYQo8xtpSURiCCCViB7w=.8a6ecee5-6800-4b84-86ad-708290e931d3@github.com>

On Wed, 16 Jul 2025 13:24:35 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8361640: JFR: RandomAccessFile::readLine emits events for each character

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26349#pullrequestreview-3025177849

From sgehwolf at openjdk.org  Wed Jul 16 14:04:40 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 16 Jul 2025 14:04:40 GMT
Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes [v4]
In-Reply-To: <Jgc8MwUte58wkGpNFe9kLavUVHPUXKqpWOmmFvGIR3o=.cb9db67b-2c87-4894-b0c9-21eb4d37d1be@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
 <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>
 <Jgc8MwUte58wkGpNFe9kLavUVHPUXKqpWOmmFvGIR3o=.cb9db67b-2c87-4894-b0c9-21eb4d37d1be@github.com>
Message-ID: <aJrygKMlIXPFhSFDGIwenmdaUr9bgQ1H0tvQ9ZDTTNM=.5d2d1b22-d062-4783-9243-cbe528a9b865@github.com>

On Tue, 15 Jul 2025 21:27:16 GMT, David Beaumont <duke at openjdk.org> wrote:

> Oddly while the status at the bottom of the conversation says it has "2 approvals", the tickbox:
> 
> ```
> Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author
> ```
> 
> is not checked. I can try to integrate, but it might not work.

I believe the review of @magicus no longer counts since he reviewed an old version of the patch. Once he acks again it should work.

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

PR Comment: https://git.openjdk.org/jdk/pull/26044#issuecomment-3078764090

From liach at openjdk.org  Wed Jul 16 14:17:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Jul 2025 14:17:41 GMT
Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes [v4]
In-Reply-To: <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
 <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>
Message-ID: <o0aNsebj6x73mui6Wlrl32TAjTL8cGfNOnxW4olRcIE=.05427e7a-8247-41ba-8fcf-a783655e0185@github.com>

On Tue, 1 Jul 2025 17:02:27 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:
> 
>   Adding comment about maintainability.

Looks reasonable.

As much as this bench is susceptible to JDK changes, many other benchmarks are similarly not robust. We can wait until we run into errors in the benchmarks.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26044#pullrequestreview-3025247133

From asemenyuk at openjdk.org  Wed Jul 16 14:24:07 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 16 Jul 2025 14:24:07 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v5]
In-Reply-To: <A5Xm9sbnXEnmTomhAE3c2x60fEVuDB2fLAhk2tNOQxw=.2f1f95b3-613e-46dc-a547-49e3f56406d7@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <A5Xm9sbnXEnmTomhAE3c2x60fEVuDB2fLAhk2tNOQxw=.2f1f95b3-613e-46dc-a547-49e3f56406d7@github.com>
Message-ID: <Jp3ys6VAqxNGsRiv9qfZT5H2XVdUwDr7uqM4Kgw4zj0=.5b459575-6303-4e42-833b-17b63c72d402@github.com>

On Wed, 16 Jul 2025 02:01:57 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 [v4]

test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/AppImageFileTest.java line 120:

> 118: 
> 119:             final var app = new Application.Stub(null, null, version, null, null,
> 120:                     Optional.empty(), Optional.empty(), List.of(), null, Optional.empty(),

Why is this change? The `Application` interface has not changed. How does it compile? Am I missing something?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2210582711

From asemenyuk at openjdk.org  Wed Jul 16 14:34:10 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 16 Jul 2025 14:34:10 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v5]
In-Reply-To: <A5Xm9sbnXEnmTomhAE3c2x60fEVuDB2fLAhk2tNOQxw=.2f1f95b3-613e-46dc-a547-49e3f56406d7@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <A5Xm9sbnXEnmTomhAE3c2x60fEVuDB2fLAhk2tNOQxw=.2f1f95b3-613e-46dc-a547-49e3f56406d7@github.com>
Message-ID: <ann8XVHeLWtL7-_994qhMgVeQglFmJWFry8hHsHnR34=.8782389b-0ee5-4329-9237-2d8dd7e33232@github.com>

On Wed, 16 Jul 2025 02:01:57 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 [v4]

src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/Package.java line 158:

> 156:      *         package
> 157:      */
> 158:     Optional<Path> predefinedAppOrRuntimeImage();

Let's keep the name unchanged. It fits both application and runtime packaging. If it were `predefinedApplicationImage()`, I would suggest changing it to `predefinedAppImage()` anyway :).

Let's just update the javadoc:

/**
     * Gets the path to a directory with the predefined app image of this package if
     * available or an empty {@link Optional} instance otherwise.
     * <p>
     * If {@link #isRuntimeInstaller()} returns {@code true}, the method returns the
     * path to a directory with the predefined runtime. The layout of this directory
     * should be of {@link RuntimeLayout} type.
     * <p>
     * If {@link #isRuntimeInstaller()} returns {@code false}, the method returns
     * the path to a directory with the predefined application image. The layout of
     * this directory should be of {@link ApplicationLayout} type.
     *
     * @return the path to a directory with the application app image of this
     *         package
     */

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2210608592

From liach at openjdk.org  Wed Jul 16 14:36:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Jul 2025 14:36:48 GMT
Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes [v4]
In-Reply-To: <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
 <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>
Message-ID: <R6Yy3Z5kqYyd2n2Ub6AVhCkVb_p624KWFeUfDDRC3os=.702a22a8-557d-4ab9-9cf1-243ed91cef0d@github.com>

On Tue, 1 Jul 2025 17:02:27 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:
> 
>   Adding comment about maintainability.

Thanks David!

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

PR Comment: https://git.openjdk.org/jdk/pull/26044#issuecomment-3078873326

From duke at openjdk.org  Wed Jul 16 14:36:49 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 16 Jul 2025 14:36:49 GMT
Subject: Integrated: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes
In-Reply-To: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
Message-ID: <kLCLEUNGkcR0ZkGSJXrgCzUh2k817bFVxSjo634hrAY=.1641ba7b-b128-4ac2-b404-0b573cd82506@github.com>

On Mon, 30 Jun 2025 12:27:40 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.

This pull request has now been integrated.

Changeset: 770d2b41
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/770d2b41d13a8a5815735c355187a476eeb9de22
Stats:     1080 lines in 2 files changed: 1080 ins; 0 del; 0 mod

8361076: Add benchmark for ImageReader in preparation for Valhalla changes

Reviewed-by: rriggs, liach, ihse

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

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

From rgiulietti at openjdk.org  Wed Jul 16 14:43:46 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 16 Jul 2025 14:43:46 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <pU242ecdIxZSk-uXlfSiXjMX-xNZFq_R6H4kklT1Klw=.27929cce-dcb4-4dab-93d7-cbfb36284c36@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <B8rouVL6Ecjm0lIqzwSjvhICoV_QonD06LqMZ853tFw=.575fe02c-f7b5-4f46-857a-c591a62a1bcd@github.com>
 <pU242ecdIxZSk-uXlfSiXjMX-xNZFq_R6H4kklT1Klw=.27929cce-dcb4-4dab-93d7-cbfb36284c36@github.com>
Message-ID: <i8xz8qX-FNCtYM1uGqNb63t0MBTYEwlX20dfbq8HLL0=.0734d880-6cc9-41ea-a18d-0b287388e73b@github.com>

On Wed, 16 Jul 2025 10:32:41 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigInteger.java line 2755:
>> 
>>> 2753:      * is even and this BigInteger is negative, an {@code ArithmeticException} will be
>>> 2754:      * thrown.
>>> 2755:      *
>> 
>> I think this specification is a bit confusing.
>> For example, when x = -10 and n = 2, then y = -3 has the same sign of x and its magnitude r = 3 is the largest integer meeting r^n ? |x|. However, y is not a solution. Sure, there's the note about negative x and even n, but that should emerge as a property from the definition, not as an additional condition.
>
> I don't know other ways to define it that don't involve the clause `!(x < 0 && n % 2 == 0)`. If the first definition is confusing, the only solution I see is to remove it, and leave only the formula `(x.signum() * floor(abs(nthRoot(x, n))))`.

I think this is probably what you are searching for.

If x ? 0 there's at most one integer y ? 0 meeting y^n ? x < (y+1)^n.
If x < 0 there's at most one integer y ? 0 meeting y^n ? x > (y-1)^n.
The method returns y if it exists, and throws otherwise.
As a consequence, it throws when n ? 0, or when x < 0 and n is even, and returns a result otherwise.

Can you please check?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2210634845

From thomas.stuefe at gmail.com  Wed Jul 16 14:52:52 2025
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 16 Jul 2025 16:52:52 +0200
Subject: How important is jspawnhelper crash detection?
In-Reply-To: <CAA-vtUxSob-rEnYk=XDH37-0n6sEOkr7BzTSDkehNetJ6qRfzw@mail.gmail.com>
References: <CAA-vtUzCxv=KtGWnVCbXzBKdg5FPuYodqWmmcU2iz+t0SHdUnA@mail.gmail.com>
 <132c3aaf-138a-44b1-8b6a-f8ac188854ce@oracle.com>
 <CAA-vtUxSob-rEnYk=XDH37-0n6sEOkr7BzTSDkehNetJ6qRfzw@mail.gmail.com>
Message-ID: <CAA-vtUwzLsfrGu5140QmF3jjph4hFnCY1LGnbfcAE9AxdExkhQ@mail.gmail.com>

Unfortunately, after diving into this, I found that the jspawnhelper
version checks (JDK-8325621) that guard against JDK in-place-updates also
rely on the liveness signal. See comment in
https://bugs.openjdk.org/browse/JDK-8362257.

I find the check itself quite questionable, but I did not want to break
that one too, so I decided to not remove the liveness check.

On Wed, Jul 16, 2025 at 7:26?AM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Thanks, Roger, I will proceed with removing the old workaround then.
>
> On Tue, Jul 15, 2025 at 5:05?PM Roger Riggs <roger.riggs at oracle.com>
> wrote:
>
>> Hi Thomas,
>>
>> Simpler is better on both sides of the protocol.
>> The version check will have happened before this part of the protocol so
>> there's no confusion about matching expectations.
>> I agree that removing it is preferred.
>>
>> Roger
>>
>>
>> On 7/15/25 10:44 AM, Thomas St?fe wrote:
>> > Hi,
>> >
>> > I am currently working on removing (eventually) the vfork mode. Before
>> > we can do this, we need a bit better error diagnostics. I do this by
>> > gently improving the error handling throughout the code, so that we
>> > can generate IOExceptions based on more exact knowledge.
>> >
>> > While working at this, I re-examined the "send aliveness ping from
>> > jspawnhelper to parent" logic again I introduced back in 2019 as a
>> > workaround for an obscure glibc bug with posix_spawn (see
>> > https://bugs.openjdk.org/browse/JDK-8223777). I found that it was not
>> > needed anymore since the glibc was fixed, so I started removing that
>> > workaround (https://bugs.openjdk.org/browse/JDK-8362257).
>> >
>> > But then it occurred to me that an obscure part of the jspawnhelper
>> > diagnostics introduced with
>> > https://bugs.openjdk.org/browse/JDK-8226242 piggy-backs on the
>> > aliveness ping for its
>> > "detect-abnormal-process-termination-before-exec" capabilities. Works
>> > like this:
>> >
>> > A jspawnhelper starts
>> > B jspawnhelper enters childProcess() and sends alivenes ping
>> > C jspawnhelper does a bunch of other things
>> > D jspawnhelper exec's
>> >
>> > In the parent, we count abnormal child terminations that occur before
>> > the aliveness ping (B) as "spawn error" and print the signal number.
>> > Without the aliveness ping we could not tell apart "jspawnhelper ends
>> > abnormally due to a signal" from "jspawnhelper exec()'s the user
>> > program successfully, user program runs and ends abnormally due to
>> > signal".
>> >
>> > However, the question is how important or even useful this part really
>> is:
>> > - for externally sent abnormal termination signals (SIGTERM etc), from
>> > the caller's point of view it probably does not matter when it comes :
>> > before or after exec().
>> > - it only matters for synchronous termination signals (crashes) we
>> > ourselves cause; but here it only covers crashes in a rather small
>> > piece of code, before the liveness ping (B). Basically, just the first
>> > part of jspawnhelper main(). Any crashes after the liveness ping are
>> > still unrecognised by ProcessBuilder.start, and are instead handled by
>> > the caller calling Process.waitFor().
>> >
>> > There are two ways to deal with this:
>> >
>> > We could do without the crash protection in point (A), which would
>> > allow us to remove the liveness ping. I would very much prefer that.
>> > It would simplify the jspawnhelper protocol and make it more robust.
>> > Because we now don't have any communication in case no error happens -
>> > there would be only a single bit of information sent back via fail
>> > pipe, and only in case of an error. Fail pipe would stay quiet in case
>> > of successful exec(). Abnormal child process termination in the first
>> > part of jspawnhelper would be covered by the same path that detects
>> > abnormal child process termination in user programs - Process.waitFor().
>> >
>> > If we determine we really need this crash detection, we could at least
>> > improve it: move the liveness ping to just-before the exec() call, so
>> > that we cover all the area from A-D. Also, do it for all modes (FORK,
>> > too), to simplify coding.
>> >
>> > Bottomline: remove an obscure and complex small mechanism that only
>> > helps a bit with detecting program errors (sigsegv etc) inside the
>> > first part of jspawnhelper main() ?
>> >
>> > Thanks, Thomas
>> >
>> >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250716/e5afa0dd/attachment-0001.htm>

From asemenyuk at openjdk.org  Wed Jul 16 15:06:06 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 16 Jul 2025 15:06:06 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v5]
In-Reply-To: <A5Xm9sbnXEnmTomhAE3c2x60fEVuDB2fLAhk2tNOQxw=.2f1f95b3-613e-46dc-a547-49e3f56406d7@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <A5Xm9sbnXEnmTomhAE3c2x60fEVuDB2fLAhk2tNOQxw=.2f1f95b3-613e-46dc-a547-49e3f56406d7@github.com>
Message-ID: <nERlaPxJOH2wGoD01k34L8MmlL55h9IveOvixe2fx5o=.70de0d93-8f97-4285-a0d8-b7969bb62af9@github.com>

On Wed, 16 Jul 2025 02:01:57 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 [v4]

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPackagingPipeline.java line 316:

> 314: 
> 315:         final var codesignConfigBuilder = CodesignConfig.build();
> 316:         app.signingConfig().ifPresent(codesignConfigBuilder::from);

Changes to the `sign()` method look redundant to me. There are no functional changes, just reformatting and replacing `app` with `env.app()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2210691280

From duke at openjdk.org  Wed Jul 16 15:19:38 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 16 Jul 2025 15:19:38 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v11]
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: <03wbWpFf0lpNFjj6juDsHLlSriqvEseQo_9w_tr_faA=.96f52a14-56f0-4c0c-88f5-10bcc3fa3def@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:

  Ready to merge changes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26054/files
  - new: https://git.openjdk.org/jdk/pull/26054/files/5ca0a147..e9f6a27b

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

  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 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 16 15:31:07 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 16 Jul 2025 15:31:07 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v12]
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: <eRJU5NDSnIIlE9ssz_zq_CrbyGAvaaWf7W6bzI0uDiU=.f4b4907c-ae6b-431d-81fd-bd97c1f81231@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 with a new target base due to a merge or a rebase. The pull request now contains one commit:

  Resync after benchmark.

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

Changes: https://git.openjdk.org/jdk/pull/26054/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=11
  Stats: 1156 lines in 10 files changed: 539 ins; 327 del; 290 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 16 15:34:51 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 16 Jul 2025 15:34:51 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v12]
In-Reply-To: <eRJU5NDSnIIlE9ssz_zq_CrbyGAvaaWf7W6bzI0uDiU=.f4b4907c-ae6b-431d-81fd-bd97c1f81231@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <eRJU5NDSnIIlE9ssz_zq_CrbyGAvaaWf7W6bzI0uDiU=.f4b4907c-ae6b-431d-81fd-bd97c1f81231@github.com>
Message-ID: <XB7ccuTLjiCdiNAe89hChShnwJlKkOZOU7uURHyetj8=.edc5527e-a56a-41ec-b392-4797b0dfa8ab@github.com>

On Wed, 16 Jul 2025 15:31:07 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 with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Resync after benchmark.

Sadly it was much easier to force push here then jump through a lot of hoops (dependent PRs are a pain).
This is now the same code minus the ImageReaderBenchmark PR (though there are still 2 lines of changes in the benchmark to update to the changed Node API). Other than that it's identical to before the push.

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

PR Comment: https://git.openjdk.org/jdk/pull/26054#issuecomment-3079163652

From egahlin at openjdk.org  Wed Jul 16 15:38:47 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 16 Jul 2025 15:38:47 GMT
Subject: [jdk25] Integrated: 8361640: JFR: RandomAccessFile::readLine emits
 events for each character
In-Reply-To: <yjEvgVLAHJAL5nN4ZYBLdHacbzsu8MZ7YZE88rtiXYo=.7a42b635-549c-437a-bf32-81dd9f4d494b@github.com>
References: <yjEvgVLAHJAL5nN4ZYBLdHacbzsu8MZ7YZE88rtiXYo=.7a42b635-549c-437a-bf32-81dd9f4d494b@github.com>
Message-ID: <Eny4xh9s5QilT7syhumZxy7lcTKjjWVSoLvACFBV024=.6a8a38a6-5a7a-4298-bc60-d5fb17e0ef4a@github.com>

On Wed, 16 Jul 2025 13:24:35 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8361640: JFR: RandomAccessFile::readLine emits events for each character

This pull request has now been integrated.

Changeset: 93260d63
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/93260d639e5204a35de4f574dee773302bb1969f
Stats:     17 lines in 1 file changed: 15 ins; 0 del; 2 mod

8361640: JFR: RandomAccessFile::readLine emits events for each character

Reviewed-by: mgronlun, alanb
Backport-of: 9bef2d1610647dec18f9e81cbac3dddbbf99dd6d

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

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

From bpb at openjdk.org  Wed Jul 16 15:38:46 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Jul 2025 15:38:46 GMT
Subject: [jdk25] Integrated: 8361587: AssertionError in File.listFiles() when
 path is empty and -esa is enabled
In-Reply-To: <hHrBHeN228ckHTQIXzKiGU6XiUX76kjt6GNi4wxFG6w=.c3541c21-9091-43da-86ed-4af5b38c1bd1@github.com>
References: <hHrBHeN228ckHTQIXzKiGU6XiUX76kjt6GNi4wxFG6w=.c3541c21-9091-43da-86ed-4af5b38c1bd1@github.com>
Message-ID: <ea7-GG8aTr-GXp6icA3SNcSfSwBbeVHEO1gjLsVPMn4=.4c5a9792-9109-4b2d-bc0d-3a8378509e3f@github.com>

On Tue, 15 Jul 2025 18:21:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [eefbfdce](https://github.com/openjdk/jdk/commit/eefbfdce315237eeec4aceceb476d86314304e81) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Brian Burkhalter on 15 Jul 2025 and was reviewed by Alan Bateman.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 69ea85ee
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/69ea85ee1205422189e9fc225a69e93d6456c217
Stats:     84 lines in 2 files changed: 80 ins; 1 del; 3 mod

8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled

Reviewed-by: alanb
Backport-of: eefbfdce315237eeec4aceceb476d86314304e81

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

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

From duke at openjdk.org  Wed Jul 16 15:52:46 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 16 Jul 2025 15:52:46 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v12]
In-Reply-To: <eRJU5NDSnIIlE9ssz_zq_CrbyGAvaaWf7W6bzI0uDiU=.f4b4907c-ae6b-431d-81fd-bd97c1f81231@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <eRJU5NDSnIIlE9ssz_zq_CrbyGAvaaWf7W6bzI0uDiU=.f4b4907c-ae6b-431d-81fd-bd97c1f81231@github.com>
Message-ID: <LatJ9HL7bfm76hhH3X1cT27uwSWMiiuUvdjQ9J4xhDA=.a56102b8-c715-4234-9ba8-367933151e20@github.com>

On Wed, 16 Jul 2025 15:31:07 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 with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Resync after benchmark.

Latest benchmarks from my laptop.


Benchmark                                            Mode  Cnt   Score   Error  Units
ImageReaderBenchmark.warmCache_CountAllNodes         avgt    5   0.866 ? 0.103  ms/op
ImageReaderBenchmark.coldStart_CountOnly               ss    5  14.785 ? 2.346  ms/op
ImageReaderBenchmark.coldStart_InitAndCount            ss    5  16.028 ? 9.811  ms/op
ImageReaderBenchmark.coldStart_LoadJavacInitClasses    ss    5   3.780 ? 6.129  ms/op
Finished running test 'micro:jdk.internal.jrtfs.ImageReaderBenchmark'


Comparable with the original results in the PR description.

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

PR Comment: https://git.openjdk.org/jdk/pull/26054#issuecomment-3079234348

From bpb at openjdk.org  Wed Jul 16 16:08:46 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Jul 2025 16:08:46 GMT
Subject: RFR: 8361587: AssertionError in File.listFiles() when path is
 empty and -esa is enabled [v8]
In-Reply-To: <klJ8pNhM7Otr222yfOIM42fjb1UGMNHPan5skF3nxWE=.28bf2472-e4fe-4da9-bf2a-90b664efb31d@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <CZboh0l2JIXaw4kzPpiVVZCKM4Ic_EMbwni0XKaVrTA=.6f5b4655-2456-416d-a4ba-f32d4be6361d@github.com>
 <wPphAluu7QpZpUlLbvLqeLjSB1tpoYkyq1Wt5zcV174=.239e046f-27b2-4ba9-85a1-ba153abb6f4c@github.com>
 <klJ8pNhM7Otr222yfOIM42fjb1UGMNHPan5skF3nxWE=.28bf2472-e4fe-4da9-bf2a-90b664efb31d@github.com>
Message-ID: <e0u7UZ6XkLRLMq3fsOnTSCgfJI9Vqz0mZ6utGC5HrF0=.43d2dedc-43bb-4ab1-9504-2a70ae538c6c@github.com>

On Wed, 16 Jul 2025 13:30:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> @bplb Can you check the test coverage again? Its important that EmptyTest exercises every method.

Yes.

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

PR Comment: https://git.openjdk.org/jdk/pull/26224#issuecomment-3079290576

From bpb at openjdk.org  Wed Jul 16 17:00:23 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Jul 2025 17:00:23 GMT
Subject: RFR: 8362429: AssertionError in File.listFiles(FileFilter |
 FilenameFilter)
Message-ID: <OPuc1ZEzj9kjPtMofqaRCv6ib7YLRD5cGGUlpdAZN_E=.8b468dcc-e3fb-4788-96ca-0fe6b29b2d9f@github.com>

Address the same problem as in #26224 but for the `listFiles` variants with a filter parameter.

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

Commit messages:
 - 8362429: AssertionError in File.listFiles(FileFilter | FilenameFilter)

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

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

From jlu at openjdk.org  Wed Jul 16 17:45:44 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 16 Jul 2025 17:45:44 GMT
Subject: RFR: 8358530: Properties#list should warn against non-String
 values [v2]
In-Reply-To: <sn5U00RQ3hVAIuwPMPKcWtbmuwFZNy2hLcgGOleXqFc=.9288a26a-41bf-49ce-9129-63d4a4786470@github.com>
References: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
 <9Wr-amACg6uZeYoPf5Qfo-UwVDVvITaxpcNksaf6xY4=.54c2ac06-5e6d-41af-a4dd-b52b31824143@github.com>
 <sn5U00RQ3hVAIuwPMPKcWtbmuwFZNy2hLcgGOleXqFc=.9288a26a-41bf-49ce-9129-63d4a4786470@github.com>
Message-ID: <t_VofOPyeSdmQ0YggdCmaG07qvCtWXpA-kDYfITJWq4=.9811444e-4bdf-44db-9144-24c3b7fc63d2@github.com>

On Wed, 16 Jul 2025 13:42:45 GMT, cagliostro92 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Properties.java line 78:
>> 
>>> 76:  * the call to the {@code propertyNames} or {@code list} method
>>> 77:  * will fail if it is called on a "compromised" {@code Properties}
>>> 78:  * object that contains a non-{@code String} key or value.
>> 
>> Since `propertyNames` won't throw `CCE` with a non-String value, instead of adding the "or value" wording here, we should move the `list` method to the sentence above and remove it from the current sentence.
>> 
>> E.g., on line 73 
>> 
>>> "If the {@code store}, {@code save}, or {@code list) method ...
>
> My bad, sorry. Fixed with 8d7e3d2fde65bd1e4ad85eca5ea93a430e2e8238

Thanks for the changes. The current form seems reasonable to me, although others might have comments. I created the following CSR, [JDK-8362447](https://bugs.openjdk.org/browse/JDK-8362447) for you. We will need a reviewer to take a look at these changes as well. (Nit: we could use the oxford comma in the class description changes.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25334#discussion_r2211098105

From bpb at openjdk.org  Wed Jul 16 17:46:33 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Jul 2025 17:46:33 GMT
Subject: RFR: 8362429: AssertionError in File.listFiles(FileFilter |
 FilenameFilter) [v2]
In-Reply-To: <OPuc1ZEzj9kjPtMofqaRCv6ib7YLRD5cGGUlpdAZN_E=.8b468dcc-e3fb-4788-96ca-0fe6b29b2d9f@github.com>
References: <OPuc1ZEzj9kjPtMofqaRCv6ib7YLRD5cGGUlpdAZN_E=.8b468dcc-e3fb-4788-96ca-0fe6b29b2d9f@github.com>
Message-ID: <qJ3BmHGQSOvFSy6j93TPYrMUKeQQu8-eHVYByb9Px50=.427b6d0f-5e89-4d87-844b-60a1d1214226@github.com>

> Address the same problem as in #26224 but for the `listFiles` variants with a filter parameter.

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

  8362429: Add list(FilenameFilter) and toURL()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26353/files
  - new: https://git.openjdk.org/jdk/pull/26353/files/f10f3960..1c61743a

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

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

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

From iklam at openjdk.org  Wed Jul 16 17:52:05 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Jul 2025 17:52:05 GMT
Subject: RFR: 8345836: Stable annotation documentation is incomplete
Message-ID: <5MPznGbnl6jsZ-og3SMtakdoHRjfRf8xZTKUUCCFqvk=.6e785ddf-cb06-48a1-ad40-70faaa7e8ee4@github.com>

Please review this documentation update, authored by @rose00 and originally pushed to the Leyden repo in [this PR](https://github.com/openjdk/leyden/pull/26), where more comments can be found regarding this update.

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

Commit messages:
 - 8345836: stable annotation documentation is incomplete

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

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

From alanb at openjdk.org  Wed Jul 16 18:29:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Jul 2025 18:29:50 GMT
Subject: RFR: 8362429: AssertionError in File.listFiles(FileFilter |
 FilenameFilter) [v2]
In-Reply-To: <qJ3BmHGQSOvFSy6j93TPYrMUKeQQu8-eHVYByb9Px50=.427b6d0f-5e89-4d87-844b-60a1d1214226@github.com>
References: <OPuc1ZEzj9kjPtMofqaRCv6ib7YLRD5cGGUlpdAZN_E=.8b468dcc-e3fb-4788-96ca-0fe6b29b2d9f@github.com>
 <qJ3BmHGQSOvFSy6j93TPYrMUKeQQu8-eHVYByb9Px50=.427b6d0f-5e89-4d87-844b-60a1d1214226@github.com>
Message-ID: <1MK-b6o4QlHW4K7iXDptI3Rmje9XJ5dsUdzeF20rI6U=.58fbd87d-1032-4f36-9e75-7d73f7c6426e@github.com>

On Wed, 16 Jul 2025 17:46:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Address the same problem as in #26224 but for the `listFiles` variants with a filter parameter.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8362429: Add list(FilenameFilter) and toURL()

src/java.base/share/classes/java/io/File.java line 1227:

> 1225:                 File f = new File(s, this);
> 1226:                 if ((filter == null) || filter.accept(f))
> 1227:                     files.add(f);

Rather than duplicating the loop, it could be changed to introduce `boolean isEmpty = path.isEmpty` and then the `f` can be created with `File f = isEmpty ? new File(s) : new File(this, s);`  It should be a bit cleaner.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26353#discussion_r2211253666

From alanb at openjdk.org  Wed Jul 16 18:34:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Jul 2025 18:34:40 GMT
Subject: RFR: 8362429: AssertionError in File.listFiles(FileFilter |
 FilenameFilter) [v2]
In-Reply-To: <qJ3BmHGQSOvFSy6j93TPYrMUKeQQu8-eHVYByb9Px50=.427b6d0f-5e89-4d87-844b-60a1d1214226@github.com>
References: <OPuc1ZEzj9kjPtMofqaRCv6ib7YLRD5cGGUlpdAZN_E=.8b468dcc-e3fb-4788-96ca-0fe6b29b2d9f@github.com>
 <qJ3BmHGQSOvFSy6j93TPYrMUKeQQu8-eHVYByb9Px50=.427b6d0f-5e89-4d87-844b-60a1d1214226@github.com>
Message-ID: <rzfkzNJ_hGcdPo-1b-syVdoAmL_haKRySLjgBbssLAI=.ad43132c-b5de-4566-9546-c19ef8545b27@github.com>

On Wed, 16 Jul 2025 17:46:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Address the same problem as in #26224 but for the `listFiles` variants with a filter parameter.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8362429: Add list(FilenameFilter) and toURL()

test/jdk/java/io/File/EmptyPath.java line 248:

> 246:         listFiles(x -> x.listFiles((FilenameFilter)null));
> 247:     }
> 248: 

What would you think about test a non-null filter too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26353#discussion_r2211264084

From jrose at openjdk.org  Wed Jul 16 18:34:39 2025
From: jrose at openjdk.org (John R Rose)
Date: Wed, 16 Jul 2025 18:34:39 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
In-Reply-To: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
Message-ID: <XBr9U774HN0HOFDYHIEfFZZ07FOruH_ntu-sQCqPa0c=.62f0965b-e4a2-46e1-b251-e947137f5cf5@github.com>

On Wed, 16 Jul 2025 04:53:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.

The effect of this PR is to make the affected array elements eligible for constant-folding by the JIT.

The contract of `@Stable` is private to the JDK, since it is a trusted annotation.  The trusted user promises not to change the array elements after the JIT might have observed them.

If we had a frozen (immutable) array feature in the JVM this PR could be formulated using frozen array constants.  But we are not there yet.

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

PR Comment: https://git.openjdk.org/jdk/pull/26341#issuecomment-3079816223

From darcy at openjdk.org  Wed Jul 16 18:46:40 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 16 Jul 2025 18:46:40 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
In-Reply-To: <XBr9U774HN0HOFDYHIEfFZZ07FOruH_ntu-sQCqPa0c=.62f0965b-e4a2-46e1-b251-e947137f5cf5@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
 <XBr9U774HN0HOFDYHIEfFZZ07FOruH_ntu-sQCqPa0c=.62f0965b-e4a2-46e1-b251-e947137f5cf5@github.com>
Message-ID: <6N5jPfQ4uqojTLziwlAYzQgmzpEJtKZSL715CP-Stew=.7ce4c253-bf74-4df0-937e-697a8dcd3382@github.com>

On Wed, 16 Jul 2025 18:32:13 GMT, John R Rose <jrose at openjdk.org> wrote:

> The effect of this PR is to make the affected array elements eligible for constant-folding by the JIT.
> 
> The contract of `@Stable` is private to the JDK, since it is a trusted annotation. The trusted user promises not to change the array elements after the JIT might have observed them.
> 
> If we had a frozen (immutable) array feature in the JVM this PR could be formulated using frozen array constants. But we are not there yet.

Yes; my intention was to allow HotSpot greater leeway to optimize the FDLIBM code. Under my limited performance testing, the change seemed to be performance neutral, but if it shouldn't cause a regression, I'd be comfortable pushing the change.

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

PR Comment: https://git.openjdk.org/jdk/pull/26341#issuecomment-3079867240

From darcy at openjdk.org  Wed Jul 16 18:54:38 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 16 Jul 2025 18:54:38 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
In-Reply-To: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
Message-ID: <76CdiCuDBq45d6ke6zQnX_xdS3kQisxveFvPzKI_zLw=.40b46ae1-4560-426d-9ce6-5cd6de6a604c@github.com>

On Wed, 16 Jul 2025 04:53:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.

The methods directly affected by this update are atan, exp, and sin, cos, tan. The sin, cos, and tan method are affected by the updates to KernelRemPio2 and tan is also directly affected by its own updates.

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

PR Comment: https://git.openjdk.org/jdk/pull/26341#issuecomment-3079890902

From bpb at openjdk.org  Wed Jul 16 19:08:40 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Jul 2025 19:08:40 GMT
Subject: RFR: 8362429: AssertionError in File.listFiles(FileFilter |
 FilenameFilter) [v2]
In-Reply-To: <1MK-b6o4QlHW4K7iXDptI3Rmje9XJ5dsUdzeF20rI6U=.58fbd87d-1032-4f36-9e75-7d73f7c6426e@github.com>
References: <OPuc1ZEzj9kjPtMofqaRCv6ib7YLRD5cGGUlpdAZN_E=.8b468dcc-e3fb-4788-96ca-0fe6b29b2d9f@github.com>
 <qJ3BmHGQSOvFSy6j93TPYrMUKeQQu8-eHVYByb9Px50=.427b6d0f-5e89-4d87-844b-60a1d1214226@github.com>
 <1MK-b6o4QlHW4K7iXDptI3Rmje9XJ5dsUdzeF20rI6U=.58fbd87d-1032-4f36-9e75-7d73f7c6426e@github.com>
Message-ID: <LeYtOFLj_FgcbROWbxyZbQV-wWA7Vv0g26w7JW_bTJA=.a2620d28-c508-4b8e-8c97-68da95c81859@github.com>

On Wed, 16 Jul 2025 18:26:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8362429: Add list(FilenameFilter) and toURL()
>
> src/java.base/share/classes/java/io/File.java line 1227:
> 
>> 1225:                 File f = new File(s, this);
>> 1226:                 if ((filter == null) || filter.accept(f))
>> 1227:                     files.add(f);
> 
> Rather than duplicating the loop, it could be changed to introduce `boolean isEmpty = path.isEmpty` and then the `f` can be created with `File f = isEmpty ? new File(s) : new File(this, s);`  It should be a bit cleaner.

I had rejected that in the case of the parameter-less `listFiles` to avoid a ternary operator in each loop iteration but it _is_ cleaner. Will update.

> What would you think about test a non-null filter too?

Okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26353#discussion_r2211324685
PR Review Comment: https://git.openjdk.org/jdk/pull/26353#discussion_r2211325168

From bpb at openjdk.org  Wed Jul 16 19:31:26 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Jul 2025 19:31:26 GMT
Subject: RFR: 8362429: AssertionError in File.listFiles(FileFilter |
 FilenameFilter) [v3]
In-Reply-To: <OPuc1ZEzj9kjPtMofqaRCv6ib7YLRD5cGGUlpdAZN_E=.8b468dcc-e3fb-4788-96ca-0fe6b29b2d9f@github.com>
References: <OPuc1ZEzj9kjPtMofqaRCv6ib7YLRD5cGGUlpdAZN_E=.8b468dcc-e3fb-4788-96ca-0fe6b29b2d9f@github.com>
Message-ID: <J3UfI5u-2zriVjb7jom57hIFxTjr28qnH4D5-skD7P0=.1eb2246b-8d78-4064-aa77-e212145eab62@github.com>

> Address the same problem as in #26224 but for the `listFiles` variants with a filter parameter.

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

  8362429: Simplify listFile loops; add non-null filter tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26353/files
  - new: https://git.openjdk.org/jdk/pull/26353/files/1c61743a..cfd494f8

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

  Stats: 46 lines in 2 files changed: 16 ins; 18 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/26353.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26353/head:pull/26353

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

From bpb at openjdk.org  Wed Jul 16 19:31:26 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Jul 2025 19:31:26 GMT
Subject: RFR: 8362429: AssertionError in File.listFiles(FileFilter |
 FilenameFilter) [v2]
In-Reply-To: <LeYtOFLj_FgcbROWbxyZbQV-wWA7Vv0g26w7JW_bTJA=.a2620d28-c508-4b8e-8c97-68da95c81859@github.com>
References: <OPuc1ZEzj9kjPtMofqaRCv6ib7YLRD5cGGUlpdAZN_E=.8b468dcc-e3fb-4788-96ca-0fe6b29b2d9f@github.com>
 <qJ3BmHGQSOvFSy6j93TPYrMUKeQQu8-eHVYByb9Px50=.427b6d0f-5e89-4d87-844b-60a1d1214226@github.com>
 <1MK-b6o4QlHW4K7iXDptI3Rmje9XJ5dsUdzeF20rI6U=.58fbd87d-1032-4f36-9e75-7d73f7c6426e@github.com>
 <LeYtOFLj_FgcbROWbxyZbQV-wWA7Vv0g26w7JW_bTJA=.a2620d28-c508-4b8e-8c97-68da95c81859@github.com>
Message-ID: <siVkErGyiQggY8A4qWmMAKUXOqxSkFLy6xv9h2MnO18=.3e3b6dc9-d15b-413a-bcda-a90bc0631faf@github.com>

On Wed, 16 Jul 2025 19:05:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/File.java line 1227:
>> 
>>> 1225:                 File f = new File(s, this);
>>> 1226:                 if ((filter == null) || filter.accept(f))
>>> 1227:                     files.add(f);
>> 
>> Rather than duplicating the loop, it could be changed to introduce `boolean isEmpty = path.isEmpty` and then the `f` can be created with `File f = isEmpty ? new File(s) : new File(this, s);`  It should be a bit cleaner.
>
> I had rejected that in the case of the parameter-less `listFiles` to avoid a ternary operator in each loop iteration but it _is_ cleaner. Will update.

So changed in cfd494f.

>> test/jdk/java/io/File/EmptyPath.java line 248:
>> 
>>> 246:         listFiles(x -> x.listFiles((FilenameFilter)null));
>>> 247:     }
>>> 248: 
>> 
>> What would you think about test a non-null filter too?
>
>> What would you think about test a non-null filter too?
> 
> Okay.

Add `listFiles` tests for non-null `FileFilter` and `FilenameFilter` in cfd494f.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26353#discussion_r2211361076
PR Review Comment: https://git.openjdk.org/jdk/pull/26353#discussion_r2211364676

From vyazici at openjdk.org  Wed Jul 16 19:38:02 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 16 Jul 2025 19:38:02 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v5]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <hqDqiIGVA7b4bjOO-QUsL-_7tB-3-MxUZoGZ1tBPozY=.3ca0eefe-80a1-4f1e-b01f-196f9770d51e@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` 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");
>         }
>     }
> }
> ...

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

  Add test verifying the effectiveness of `VerifyIntrinsicChecks`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/2b89e880..8941e6b6

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

  Stats: 110 lines in 3 files changed: 108 ins; 0 del; 2 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 vyazici at openjdk.org  Wed Jul 16 19:42:32 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 16 Jul 2025 19:42:32 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v6]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <pozYBtbEcYQCqynctIMGBY_G3HJFLYXL8DOjrUudzsk=.ec4d7f03-938c-4728-a2c1-60f8fc549b69@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` 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");
>         }
>     }
> }
> ...

Volkan Yazici has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Add test verifying the effectiveness of `VerifyIntrinsicChecks`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/8941e6b6..bcb073cb

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 almatvee at openjdk.org  Wed Jul 16 20:05:51 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 16 Jul 2025 20:05:51 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v6]
In-Reply-To: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
Message-ID: <EWYCk4Nk0vCpUbhwYv3KAn6GWw6XE36ACrKeQVFKaFQ=.3e09d6a9-e820-4d53-a7dd-db80ebf6de98@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 [v5]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26173/files
  - new: https://git.openjdk.org/jdk/pull/26173/files/9e492cb7..9473613f

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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  Wed Jul 16 20:05:52 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 16 Jul 2025 20:05:52 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v5]
In-Reply-To: <A5Xm9sbnXEnmTomhAE3c2x60fEVuDB2fLAhk2tNOQxw=.2f1f95b3-613e-46dc-a547-49e3f56406d7@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <A5Xm9sbnXEnmTomhAE3c2x60fEVuDB2fLAhk2tNOQxw=.2f1f95b3-613e-46dc-a547-49e3f56406d7@github.com>
Message-ID: <MqdGMbErkccgFA2KPUUjpYBaiJvu0VBIZ31WenqLIDc=.677efb2a-6e6e-4d06-87e1-2dc42bee6719@github.com>

On Wed, 16 Jul 2025 02:01:57 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 [v4]

8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v5]
 - Fixed unit test compilation issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/26173#issuecomment-3080158694

From mcimadamore at openjdk.org  Wed Jul 16 21:13:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 16 Jul 2025 21:13:51 GMT
Subject: RFR: 8362169: Pointer passed to upcall may get wrong scope
In-Reply-To: <p9Ykd_mrk9HP9goCgtwnry5CJEzhtSpIblLZUZLIl0w=.73dae209-8b94-4e5b-9001-bf8c3861a2b5@github.com>
References: <p9Ykd_mrk9HP9goCgtwnry5CJEzhtSpIblLZUZLIl0w=.73dae209-8b94-4e5b-9001-bf8c3861a2b5@github.com>
Message-ID: <A5Ig3Cb5xddzMjEv7DdZwkRin9NLIPQruqlQC15xzTE=.747dbe84-82bd-4e61-ab57-9560ad239c2d@github.com>

On Mon, 14 Jul 2025 15:33:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Issue copied from the JBS issue:
> 
> When an upcall stub accepts a by-value struct, and the struct is passed by the underlying ABI as a pointer to a temporary copy on the caller's stack (for instance on Windows when the struct doesn't fit into a single register), a scope is created for the duration of the upcall, to which the memory segment for this struct is attached.
> 
> However, if such a scope is created for the upcall, any other unrelated pointer argument will _also_ be attached to the same scope. This is incorrect, as unrelated pointer arguments should be attached to the global scope. The underlying issue is that, when deciding whether a particular argument needs to be attached to the scope, we check if _any_ of the argument needs to be attached to the created scope.
> 
> This PR fixes the issue by calling `boxAddress.needsScope()` in `BindingSpecializer::emitBoxAddress`, which checks only if that particular argument needs to be attached to the upcall scope.
> 
> I've also renamed the 'global' `needsScope` method, which checks whether _any_ of the arguments need a scope, to `anyArgNeedsScope` for clarity.
> 
> Testing: `jdk_foreign` test suite on Mac/Windows/Linux x64, and Mac/Linux aarch64

Looks good!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26295#pullrequestreview-3026916106

From almatvee at openjdk.org  Wed Jul 16 21:26:11 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 16 Jul 2025 21:26:11 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v5]
In-Reply-To: <Jp3ys6VAqxNGsRiv9qfZT5H2XVdUwDr7uqM4Kgw4zj0=.5b459575-6303-4e42-833b-17b63c72d402@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <A5Xm9sbnXEnmTomhAE3c2x60fEVuDB2fLAhk2tNOQxw=.2f1f95b3-613e-46dc-a547-49e3f56406d7@github.com>
 <Jp3ys6VAqxNGsRiv9qfZT5H2XVdUwDr7uqM4Kgw4zj0=.5b459575-6303-4e42-833b-17b63c72d402@github.com>
Message-ID: <OI9eGz08y7MBOZ9yyoX8u75lqzRVfAd69NDWhLKBAdo=.bdffa06e-c3ee-4940-a3d3-0c7f26d785c0@github.com>

On Wed, 16 Jul 2025 14:20:47 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 [v4]
>
> test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/AppImageFileTest.java line 120:
> 
>> 118: 
>> 119:             final var app = new Application.Stub(null, null, version, null, null,
>> 120:                     Optional.empty(), Optional.empty(), List.of(), null, Optional.empty(),
> 
> Why is this change? The `Application` interface has not changed. How does it compile? Am I missing something?

It did not compiled when I added `runtimeImageDir` to `Application` interface. It was removed in v4, so I reverted this change in v5.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2211640221

From almatvee at openjdk.org  Wed Jul 16 22:26:51 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 16 Jul 2025 22:26:51 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v7]
In-Reply-To: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
Message-ID: <1alrEItE8VTiorSu-uXu3l10Dppe5ZFLND0LG3EBy7A=.d9fcfe97-df70-45ec-93eb-2e3ca0494940@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 [v6]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26173/files
  - new: https://git.openjdk.org/jdk/pull/26173/files/9473613f..72e47ddd

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

  Stats: 49 lines in 9 files changed: 9 ins; 6 del; 34 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  Wed Jul 16 22:26:51 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 16 Jul 2025 22:26:51 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v6]
In-Reply-To: <EWYCk4Nk0vCpUbhwYv3KAn6GWw6XE36ACrKeQVFKaFQ=.3e09d6a9-e820-4d53-a7dd-db80ebf6de98@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <EWYCk4Nk0vCpUbhwYv3KAn6GWw6XE36ACrKeQVFKaFQ=.3e09d6a9-e820-4d53-a7dd-db80ebf6de98@github.com>
Message-ID: <AMs7N8EQcIGNViFwGTmtyMXYlboBeByEVv2I1B--_U4=.f01511e8-465c-411e-89b8-0c89686c6991@github.com>

On Wed, 16 Jul 2025 20:05:51 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 [v5]

8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v6]
- `sign()` is reverted to original version.
- Renamed `predefinedAppOrRuntimeImage()` back.

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

PR Comment: https://git.openjdk.org/jdk/pull/26173#issuecomment-3081428926

From almatvee at openjdk.org  Wed Jul 16 22:26:53 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 16 Jul 2025 22:26:53 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v4]
In-Reply-To: <nERlaPxJOH2wGoD01k34L8MmlL55h9IveOvixe2fx5o=.70de0d93-8f97-4285-a0d8-b7969bb62af9@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <A5Xm9sbnXEnmTomhAE3c2x60fEVuDB2fLAhk2tNOQxw=.2f1f95b3-613e-46dc-a547-49e3f56406d7@github.com>
 <nERlaPxJOH2wGoD01k34L8MmlL55h9IveOvixe2fx5o=.70de0d93-8f97-4285-a0d8-b7969bb62af9@github.com>
Message-ID: <xlecb-_WqCipPC98UUpE790TJOyfUr8RNf1ZdDx9LcA=.7ff4746e-3490-44a2-8519-db140b0db12b@github.com>

On Wed, 16 Jul 2025 15:03:05 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 [v3]
>
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPackagingPipeline.java line 316:
> 
>> 314:         String category = isRuntimeBundle ?
>> 315:             "resource.runtime-bundle-info-plist" : "resource.runtime-info-plist";
>> 316: 
> 
> Changes to the `sign()` method look redundant to me. There are no functional changes, just reformatting and replacing `app` with `env.app()`.

sign() changes reverted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2211719037

From almatvee at openjdk.org  Wed Jul 16 22:26:54 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 16 Jul 2025 22:26:54 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v5]
In-Reply-To: <ann8XVHeLWtL7-_994qhMgVeQglFmJWFry8hHsHnR34=.8782389b-0ee5-4329-9237-2d8dd7e33232@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <A5Xm9sbnXEnmTomhAE3c2x60fEVuDB2fLAhk2tNOQxw=.2f1f95b3-613e-46dc-a547-49e3f56406d7@github.com>
 <ann8XVHeLWtL7-_994qhMgVeQglFmJWFry8hHsHnR34=.8782389b-0ee5-4329-9237-2d8dd7e33232@github.com>
Message-ID: <_7MNI-KFyMlB_jEqVeo7PZLrth7TJa1iqS1qSMDt36o=.d44e84da-064f-4f4b-942e-a2680fc22605@github.com>

On Wed, 16 Jul 2025 14:30:44 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 [v4]
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/Package.java line 158:
> 
>> 156:      *         package
>> 157:      */
>> 158:     Optional<Path> predefinedAppOrRuntimeImage();
> 
> Let's keep the name unchanged. It fits both application and runtime packaging. If it were `predefinedApplicationImage()`, I would suggest changing it to `predefinedAppImage()` anyway :).
> 
> Let's just update the javadoc:
> 
> /**
>      * Gets the path to a directory with the predefined app image of this package if
>      * available or an empty {@link Optional} instance otherwise.
>      * <p>
>      * If {@link #isRuntimeInstaller()} returns {@code true}, the method returns the
>      * path to a directory with the predefined runtime. The layout of this directory
>      * should be of {@link RuntimeLayout} type.
>      * <p>
>      * If {@link #isRuntimeInstaller()} returns {@code false}, the method returns
>      * the path to a directory with the predefined application image. The layout of
>      * this directory should be of {@link ApplicationLayout} type.
>      *
>      * @return the path to a directory with the application app image of this
>      *         package
>      */

Comment added and function renamed back.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2211719421

From vyazici at openjdk.org  Thu Jul 17 04:37:49 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 04:37:49 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v6]
In-Reply-To: <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
Message-ID: <ILpxTnU0Qknj87AlZ_HHK8HYIV-WECfOxZefu3ep_ZQ=.50c5c37e-c79d-4d62-a917-b7ac5ec11290@github.com>

On Thu, 10 Jul 2025 12:23:06 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Volkan Yazici has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Add test verifying the effectiveness of `VerifyIntrinsicChecks`
>
> 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.

@TobiHartmann, this change results in the following compiler error:


/home/vy/.../src/hotspot/share/opto/library_call.cpp:958:35: error: invalid conversion from 'Node*' to 'RegionNode*' [-fpermissive]
  958 |   generate_negative_guard(offset, bailout);
      |                                   ^~~~~~~
      |                                   |
      |                                   Node*


That is, `bailout` is supposed to be of type `RegionNode*`, but `_gvn.transform()` returns a value of type `Node*`. I will locally amend this change as


bailout = (RegionNode*) _gvn.transform(bailout);


Let me know if you disagree.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2212232094

From vyazici at openjdk.org  Thu Jul 17 06:13:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 06:13:30 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v7]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <Qr8CjovOTF-nAV5xLI7xVROedV1m8dRbXkznFN5qPnQ=.42fa7507-8a95-48bd-ad57-021438c3e219@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` 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");
>         }
>     }
> }
> ...

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

 - Duplicate affected tests with `-XX:+VerifyIntrinsicChecks` variants
 - Fix compiler error in `generate_string_range_check`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/bcb073cb..abc0eeb3

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

  Stats: 61 lines in 4 files changed: 53 ins; 2 del; 6 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 vyazici at openjdk.org  Thu Jul 17 06:15:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 06:15:53 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v3]
In-Reply-To: <4zqK_rAHpX2bdDGf_kw2TOXtdOgONZykPs7mlR-rDrA=.d7d2bcd4-1e48-40ed-9628-46a681a5c4bb@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>
 <4zqK_rAHpX2bdDGf_kw2TOXtdOgONZykPs7mlR-rDrA=.d7d2bcd4-1e48-40ed-9628-46a681a5c4bb@github.com>
Message-ID: <tiD2-tEG9GB_6qJJuxMzR2V0qcrcEGjHaVme-D7fiUY=.404f5ff5-26d6-47ed-8315-532619554663@github.com>

On Wed, 16 Jul 2025 05:28:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>>  - Apply review feedback (styling changes)
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>>  - 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
>>    
>>    This reverts commit 196fc5d406851b8e7070c97ac53ca59c4615aad9.
>>  - Improve intrinsics in `StringCoding`
>>  - Add `StringCodingCountPositives` benchmark
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/921f85ab...85f19864
>
> src/hotspot/share/opto/c2_globals.hpp line 665:
> 
>> 663:           "prints attempted and successful inlining of intrinsics")         \
>> 664:                                                                             \
>> 665:   develop(bool, VerifyIntrinsicChecks, false,                               \
> 
> We should add testing that uses this new flag. Maybe we could add a run to the tests that check the affected intrinsics? We could also add it to our (Oracle internal) stress test jobs at higher tiers.

@TobiHartmann, agreed. I've pushed two commits:

1. bcb073cbb41 adds `TestVerifyIntrinsicChecks` to verify the effectiveness of the `VerifyIntrinsicChecks` VM flag. That is, does VM indeed crash if intrinsic Java wrapper fails to properly validate the input?
2. abc0eeb3bfc adds a separate `/* @test ... @run ... -XX:+VerifyIntrinsicChecks` block to the tests using `StringCoding` intrinsics

Please let me know if these two address your remarks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2212371103

From vyazici at openjdk.org  Thu Jul 17 06:21:56 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 06:21:56 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v7]
In-Reply-To: <Qr8CjovOTF-nAV5xLI7xVROedV1m8dRbXkznFN5qPnQ=.42fa7507-8a95-48bd-ad57-021438c3e219@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <Qr8CjovOTF-nAV5xLI7xVROedV1m8dRbXkznFN5qPnQ=.42fa7507-8a95-48bd-ad57-021438c3e219@github.com>
Message-ID: <66HgANGbmZLWZpH-g9ChFl_VX3WRq_WgYlq4edeVAIg=.7e3f06ab-ba80-4952-9ff5-168d64025783@github.com>

On Thu, 17 Jul 2025 06:13:30 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 IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` 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...
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Duplicate affected tests with `-XX:+VerifyIntrinsicChecks` variants
>  - Fix compiler error in `generate_string_range_check`

test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 84:

> 82:         char[] buffer = new char[length];
> 83:         for (int i = 0; i < length; i++) {
> 84:             buffer[i] = (char) (i % '\u0080');

ASCII (<= 0x7F) production

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2212379110

From alanb at openjdk.org  Thu Jul 17 06:31:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Jul 2025 06:31:48 GMT
Subject: RFR: 8362429: AssertionError in File.listFiles(FileFilter |
 FilenameFilter) [v3]
In-Reply-To: <J3UfI5u-2zriVjb7jom57hIFxTjr28qnH4D5-skD7P0=.1eb2246b-8d78-4064-aa77-e212145eab62@github.com>
References: <OPuc1ZEzj9kjPtMofqaRCv6ib7YLRD5cGGUlpdAZN_E=.8b468dcc-e3fb-4788-96ca-0fe6b29b2d9f@github.com>
 <J3UfI5u-2zriVjb7jom57hIFxTjr28qnH4D5-skD7P0=.1eb2246b-8d78-4064-aa77-e212145eab62@github.com>
Message-ID: <EB0KuMC0FxZGc1ieHk-G2bQZLDezUHz_FezD1bI4bWg=.176b7d30-69a6-4e0d-b0a6-5d6282cba9ec@github.com>

On Wed, 16 Jul 2025 19:31:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Address the same problem as in #26224 but for the `listFiles` variants with a filter parameter.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8362429: Simplify listFile loops; add non-null filter tests

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26353#pullrequestreview-3028086725

From vyazici at openjdk.org  Thu Jul 17 06:31:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 06:31:55 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v7]
In-Reply-To: <Qr8CjovOTF-nAV5xLI7xVROedV1m8dRbXkznFN5qPnQ=.42fa7507-8a95-48bd-ad57-021438c3e219@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <Qr8CjovOTF-nAV5xLI7xVROedV1m8dRbXkznFN5qPnQ=.42fa7507-8a95-48bd-ad57-021438c3e219@github.com>
Message-ID: <oS4jbFRoOs0Gk7rzDmHCW3j0HJVv8ETSkiJuyS_ocCo=.4fc13412-aba3-4884-bbed-6c9dea3bdd29@github.com>

On Thu, 17 Jul 2025 06:13:30 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 IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` 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...
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Duplicate affected tests with `-XX:+VerifyIntrinsicChecks` variants
>  - Fix compiler error in `generate_string_range_check`

test/hotspot/jtreg/compiler/patches/java.base/java/lang/Helper.java line 44:

> 42:     @jdk.internal.vm.annotation.ForceInline
> 43:     public static int StringCodingEncodeAsciiArray0(char[] sa, int sp, byte[] da, int dp, int len) {
> 44:         return StringCoding.encodeAsciiArray0(sa, sp, da, dp, len);

`TestVerifyIntrinsicChecks` needs to have access to an intrinsic that uses the `VerifyIntrinsicChecks` VM flag. For that purpose, I chose `StringCoding::encodeAsciiArray`, which is the guarded public door to `@IntrinsicCandidate encodeAsciiArray0()` ? note the `0` suffix! `TestVerifyIntrinsicChecks` needs to feed invalid input to `encodeAsciiArray0()` to trip the checks in the compiler intrinsic. Though, `encodeAsciiArray0()` is, as is one of the main motivations of this PR, private. In `TestVerifyIntrinsicChecks`, I first tried accessing to `encodeAsciiArray0()` using reflection, but this blocked the method get inlined, which is a requirement for intrinsification. Hence, I made the  `encodeAsciiArray0()` package-private and exposed it via `StringCodingEncodeAsciiArray0` to allow inlining, and, eventually, intrinsification. This worked.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2212396003

From bpb at openjdk.org  Thu Jul 17 06:35:54 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Jul 2025 06:35:54 GMT
Subject: Integrated: 8362429: AssertionError in File.listFiles(FileFilter |
 FilenameFilter)
In-Reply-To: <OPuc1ZEzj9kjPtMofqaRCv6ib7YLRD5cGGUlpdAZN_E=.8b468dcc-e3fb-4788-96ca-0fe6b29b2d9f@github.com>
References: <OPuc1ZEzj9kjPtMofqaRCv6ib7YLRD5cGGUlpdAZN_E=.8b468dcc-e3fb-4788-96ca-0fe6b29b2d9f@github.com>
Message-ID: <Mrygbx-iSIfleeRlRqQVaXo6k39SKWqdaREM3wmslN8=.660f29c3-aa00-4915-860c-729487b4fa37@github.com>

On Wed, 16 Jul 2025 16:54:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Address the same problem as in #26224 but for the `listFiles` variants with a filter parameter.

This pull request has now been integrated.

Changeset: be0161a8
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/be0161a8e63096f3a21ce6ea1e055ee1c4ed63ad
Stats:     65 lines in 2 files changed: 50 ins; 6 del; 9 mod

8362429: AssertionError in File.listFiles(FileFilter | FilenameFilter)

Reviewed-by: alanb

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

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

From duke at openjdk.org  Thu Jul 17 06:39:53 2025
From: duke at openjdk.org (duke)
Date: Thu, 17 Jul 2025 06:39:53 GMT
Subject: RFR: 8361697: Remove duplicate message in MainResources.properties
In-Reply-To: <apRAelAuEvvGzVSK4_pllZvS9hloXO3UE6_2CRuCX28=.0d98fffe-f426-4523-b03d-a9d9bda81799@github.com>
References: <apRAelAuEvvGzVSK4_pllZvS9hloXO3UE6_2CRuCX28=.0d98fffe-f426-4523-b03d-a9d9bda81799@github.com>
Message-ID: <944dcNv1EtHhPmSTBQTz-o246vW4qJ18wBZbUlAsKxo=.74fe7ca0-5b39-4a83-b220-de4a65f4d0d6@github.com>

On Wed, 9 Jul 2025 10:32:47 GMT, Pooja-DP <duke at openjdk.org> wrote:

> Bug reference: https://bugs.openjdk.org/browse/JDK-8361697
> 
> The following message is removed:
> 
> `
> MSG_BundlerFailed=Error: Bundler "{1}" ({0}) failed to produce a package`
> 
> Signed-off-by: Pooja.D.P1 <Pooja.D.P1 at ibm.com>

@Pooja-DP 
Your change (at version d24a0b1360ec7a80c28249c40b6885d2e97e6b15) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26215#issuecomment-3082765384

From bpb at openjdk.org  Thu Jul 17 06:41:17 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Jul 2025 06:41:17 GMT
Subject: [jdk25] RFR: 8362429: AssertionError in File.listFiles(FileFilter |
 FilenameFilter)
Message-ID: <rgZusLTPCkLik-JdBRFgZ0wB6sdUneYdoG2ZRjo0C6I=.031c30f2-ba28-48f6-b7fe-52e76adaf1f9@github.com>

Hi all,

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

    The commit being backported was authored by Brian Burkhalter on 17 Jul 2025 and was reviewed by Alan Bateman.

    Thanks!

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

Commit messages:
 - Backport be0161a8e63096f3a21ce6ea1e055ee1c4ed63ad

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

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

From alanb at openjdk.org  Thu Jul 17 06:57:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Jul 2025 06:57:46 GMT
Subject: [jdk25] RFR: 8362429: AssertionError in File.listFiles(FileFilter
 | FilenameFilter)
In-Reply-To: <rgZusLTPCkLik-JdBRFgZ0wB6sdUneYdoG2ZRjo0C6I=.031c30f2-ba28-48f6-b7fe-52e76adaf1f9@github.com>
References: <rgZusLTPCkLik-JdBRFgZ0wB6sdUneYdoG2ZRjo0C6I=.031c30f2-ba28-48f6-b7fe-52e76adaf1f9@github.com>
Message-ID: <DOutciKuyqgch_6FNuZZUL_Tfa1Ph4ARbx4jw95nSUc=.f6831cef-4cd7-4b89-bc9f-9b5de626be74@github.com>

On Thu, 17 Jul 2025 06:33:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Hi all,
> 
>     This pull request contains a backport of commit [be0161a8](https://github.com/openjdk/jdk/commit/be0161a8e63096f3a21ce6ea1e055ee1c4ed63ad) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
>     The commit being backported was authored by Brian Burkhalter on 17 Jul 2025 and was reviewed by Alan Bateman.
> 
>     Thanks!

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26361#pullrequestreview-3028164084

From bpb at openjdk.org  Thu Jul 17 07:00:54 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Jul 2025 07:00:54 GMT
Subject: [jdk25] Integrated: 8362429: AssertionError in
 File.listFiles(FileFilter | FilenameFilter)
In-Reply-To: <rgZusLTPCkLik-JdBRFgZ0wB6sdUneYdoG2ZRjo0C6I=.031c30f2-ba28-48f6-b7fe-52e76adaf1f9@github.com>
References: <rgZusLTPCkLik-JdBRFgZ0wB6sdUneYdoG2ZRjo0C6I=.031c30f2-ba28-48f6-b7fe-52e76adaf1f9@github.com>
Message-ID: <Q4Zl3Ecw-WlgPcRlWMEy37XKKQBo0s-8DpfeEzX8ZQU=.9fe2716a-c4fc-4b36-ac42-547a8db7a622@github.com>

On Thu, 17 Jul 2025 06:33:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Hi all,
> 
>     This pull request contains a backport of commit [be0161a8](https://github.com/openjdk/jdk/commit/be0161a8e63096f3a21ce6ea1e055ee1c4ed63ad) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
>     The commit being backported was authored by Brian Burkhalter on 17 Jul 2025 and was reviewed by Alan Bateman.
> 
>     Thanks!

This pull request has now been integrated.

Changeset: e989c1d1
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e989c1d138cc599b28a57911e1f1879e1e6cad46
Stats:     65 lines in 2 files changed: 50 ins; 6 del; 9 mod

8362429: AssertionError in File.listFiles(FileFilter | FilenameFilter)

Reviewed-by: alanb
Backport-of: be0161a8e63096f3a21ce6ea1e055ee1c4ed63ad

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

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

From thartmann at openjdk.org  Thu Jul 17 07:06:52 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 17 Jul 2025 07:06:52 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v7]
In-Reply-To: <ILpxTnU0Qknj87AlZ_HHK8HYIV-WECfOxZefu3ep_ZQ=.50c5c37e-c79d-4d62-a917-b7ac5ec11290@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
 <ILpxTnU0Qknj87AlZ_HHK8HYIV-WECfOxZefu3ep_ZQ=.50c5c37e-c79d-4d62-a917-b7ac5ec11290@github.com>
Message-ID: <vHLGb2BnmEuVVmiXvpkYLejq3p6Qz3bzxvsLlz4kndI=.0d07e3de-d573-44b8-906e-e5810b6c977e@github.com>

On Thu, 17 Jul 2025 04:35:01 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 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.
>
> @TobiHartmann, this change results in the following compiler error:
> 
> 
> /home/vy/.../src/hotspot/share/opto/library_call.cpp:958:35: error: invalid conversion from 'Node*' to 'RegionNode*' [-fpermissive]
>   958 |   generate_negative_guard(offset, bailout);
>       |                                   ^~~~~~~
>       |                                   |
>       |                                   Node*
> 
> 
> That is, `bailout` is supposed to be of type `RegionNode*`, but `_gvn.transform()` returns a value of type `Node*`. bfc301798d1 amends failing code with
> 
> 
> bailout = (RegionNode*) _gvn.transform(bailout);
> 
> 
> Let me know if you disagree.

Please use `->as_Region()` instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2212467404

From vyazici at openjdk.org  Thu Jul 17 07:20:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 07:20:34 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` 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");
>         }
>     }
> }
> ...

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

  Replace casting with `as_Region()` in `generate_string_range_check`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/abc0eeb3..db1ed388

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 vyazici at openjdk.org  Thu Jul 17 07:20:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 17 Jul 2025 07:20:34 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <vHLGb2BnmEuVVmiXvpkYLejq3p6Qz3bzxvsLlz4kndI=.0d07e3de-d573-44b8-906e-e5810b6c977e@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
 <ILpxTnU0Qknj87AlZ_HHK8HYIV-WECfOxZefu3ep_ZQ=.50c5c37e-c79d-4d62-a917-b7ac5ec11290@github.com>
 <vHLGb2BnmEuVVmiXvpkYLejq3p6Qz3bzxvsLlz4kndI=.0d07e3de-d573-44b8-906e-e5810b6c977e@github.com>
Message-ID: <ZF0kmTYixGF_s_Wv3IuCSXS4TUR3ocblRo_aisw1cRI=.32306c61-2fd2-43eb-9616-247d91b0146a@github.com>

On Thu, 17 Jul 2025 07:04:00 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> @TobiHartmann, this change results in the following compiler error:
>> 
>> 
>> /home/vy/.../src/hotspot/share/opto/library_call.cpp:958:35: error: invalid conversion from 'Node*' to 'RegionNode*' [-fpermissive]
>>   958 |   generate_negative_guard(offset, bailout);
>>       |                                   ^~~~~~~
>>       |                                   |
>>       |                                   Node*
>> 
>> 
>> That is, `bailout` is supposed to be of type `RegionNode*`, but `_gvn.transform()` returns a value of type `Node*`. bfc301798d1 amends failing code with
>> 
>> 
>> bailout = (RegionNode*) _gvn.transform(bailout);
>> 
>> 
>> Let me know if you disagree.
>
> Please use `->as_Region()` instead.

Changed as requested in db1ed388765.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2212492666

From alanb at openjdk.org  Thu Jul 17 07:42:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Jul 2025 07:42:48 GMT
Subject: RFR: 8361972: Clarify the condition of System.console() about
 standard input/output [v2]
In-Reply-To: <TKnCmtTeM0-f1yunDtO8zRno4ZbVWxhiWN0kagttFns=.3f8e4e55-84f4-4eee-924a-e04e46485c12@github.com>
References: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
 <TKnCmtTeM0-f1yunDtO8zRno4ZbVWxhiWN0kagttFns=.3f8e4e55-84f4-4eee-924a-e04e46485c12@github.com>
Message-ID: <HD9ktp88gpejD3h9DLO6HMAHiRNoTnHV-U5fW0xJPhk=.6a3b8a69-4c1b-43f5-ad6a-18f10196c70e@github.com>

On Mon, 14 Jul 2025 22:39:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This accompanies the fix for [JDK-8361613](https://bugs.openjdk.org/browse/JDK-8361613), which restricts `System.console()` to return a `Console` instance only when both standard input and output are connected to a terminal. The change here is solely a specification clarification and tightening of the `java.io.Console` javadoc to reflect this behavior. We are separating the spec clarification because the fix itself may be backported to prior LTS releases without requiring a Maintenance Review process.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wording modification

src/java.base/share/classes/java/io/Console.java line 51:

> 49:  * console. Regardless of how the virtual machine was created, it may not
> 50:  * have a console if either the standard input or output stream is
> 51:  * redirected.

Can you clarify what the intent of "it may not have a console" is? Initially I though the intention was that there is no Console when either stdout or stdin is redirected. However, the sentence suggests there may or may not be a Console.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26299#discussion_r2212548177

From thartmann at openjdk.org  Thu Jul 17 08:33:51 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 17 Jul 2025 08:33:51 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
Message-ID: <fuxrNfsUsBbXxW1KDYlCeDY7Qdi2CrM0C6aruF1Vv80=.91e6bee4-2828-49a8-b17c-d07716666099@github.com>

On Thu, 17 Jul 2025 07:20:34 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 IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` 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...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace casting with `as_Region()` in `generate_string_range_check`

That looks good to me. Thanks!

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3028497094

From jpai at openjdk.org  Thu Jul 17 09:10:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Jul 2025 09:10:48 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <Y5KgALU_xIs40qkrtuGTXa6uaoL5jnzFSdfP5j2kad4=.783539e5-73e8-4895-9fb4-5bec92d8524c@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3028640169

From dfenacci at openjdk.org  Thu Jul 17 09:37:51 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Thu, 17 Jul 2025 09:37:51 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
Message-ID: <zzkuyukdeX9XFwhjUDH1sRxly_VraGXe6lciLE1cWuQ=.fbf49cbe-9541-4676-92e0-be0cde765a29@github.com>

On Thu, 17 Jul 2025 07:20:34 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 IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` 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...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace casting with `as_Region()` in `generate_string_range_check`

Looks good to me too. Thanks @vy!

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

Marked as reviewed by dfenacci (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3028731726

From rgiulietti at openjdk.org  Thu Jul 17 10:10:05 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Jul 2025 10:10:05 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat
Message-ID: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>

Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.

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

Commit messages:
 - Merge branch 'master' into 8362448
 - 8362448: Make use of the Double.toString(double) algorithm in java.text.DecimalFormat
 - Remove some unused methods from FloatingDecimal.
 - Renamed compatibility config option.
 - Merge branch 'master' into dtoa
 - Remove unused methods.
 - Merge branch 'master' into dtoa
 - Added logic for exactness and direction of rounding.

Changes: https://git.openjdk.org/jdk/pull/26364/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26364&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362448
  Stats: 98 lines in 6 files changed: 47 ins; 7 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/26364.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26364/head:pull/26364

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

From rgiulietti at openjdk.org  Thu Jul 17 10:33:49 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Jul 2025 10:33:49 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
In-Reply-To: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
Message-ID: <rHPoN0EcX0YwnfCob89AMOw0GFsw8MJtmcU7kPWHEOk=.ef465d82-5a17-4fba-8d40-300066d76cd0@github.com>

On Wed, 16 Jul 2025 04:53:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.

The arrays at L.2257-2262 could be declared `static` and `@Stable` as well, and moved outside the method.

src/java.base/share/classes/java/lang/FdLibm.java line 815:

> 813:          */
> 814: 
> 815:         private static final int init_jk[] = {2, 3, 4, 6}; // initial value for jk

Suggestion:

        @Stable private static final int init_jk[] = {2, 3, 4, 6}; // initial value for jk

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

PR Review: https://git.openjdk.org/jdk/pull/26341#pullrequestreview-3028924953
PR Review Comment: https://git.openjdk.org/jdk/pull/26341#discussion_r2212968109

From swen at openjdk.org  Thu Jul 17 10:52:48 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 17 Jul 2025 10:52:48 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
In-Reply-To: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
Message-ID: <-sbpZC73xY3tOOsp2WbzZt0tV16DeeFsSsFWR011Afg=.f091e171-c06d-4511-9a4f-b5f9c3c47131@github.com>

On Wed, 16 Jul 2025 04:53:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.

src/java.base/share/classes/java/lang/FdLibm.java line 457:

> 455:             pio4  =  0x1.921fb54442d18p-1,  // 7.85398163397448278999e-01
> 456:             pio4lo=  0x1.1a62633145c07p-55; // 3.06161699786838301793e-17
> 457:         @Stable private static final double

Suggestion:

        @Stable 
        private static final double

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26341#discussion_r2213012163

From swen at openjdk.org  Thu Jul 17 11:00:49 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 17 Jul 2025 11:00:49 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
In-Reply-To: <rHPoN0EcX0YwnfCob89AMOw0GFsw8MJtmcU7kPWHEOk=.ef465d82-5a17-4fba-8d40-300066d76cd0@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
 <rHPoN0EcX0YwnfCob89AMOw0GFsw8MJtmcU7kPWHEOk=.ef465d82-5a17-4fba-8d40-300066d76cd0@github.com>
Message-ID: <vyuFN3_Mg4Alj9wZ0j_OHNO6epGCQFUiNtdRXinO-uU=.b1f2d2e2-d030-4109-aa43-6214afd01661@github.com>

On Thu, 17 Jul 2025 10:27:27 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> src/java.base/share/classes/java/lang/FdLibm.java line 815:
> 
>> 813:          */
>> 814: 
>> 815:         private static final int init_jk[] = {2, 3, 4, 6}; // initial value for jk
> 
> Suggestion:
> 
>         @Stable private static final int init_jk[] = {2, 3, 4, 6}; // initial value for jk

Suggestion:

        @Stable
        private static final int[] init_jk = {2, 3, 4, 6}; // initial value for jk

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26341#discussion_r2213028734

From rgiulietti at openjdk.org  Thu Jul 17 12:28:06 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Jul 2025 12:28:06 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v2]
In-Reply-To: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
Message-ID: <Ehgm-dIuodCjPcGT3jTRlwu5nIucpKgky-oyeBOhQUA=.8ef8181a-a701-4632-923e-363290e00a6a@github.com>

> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.

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

  Added comment to COMPAT static field.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26364/files
  - new: https://git.openjdk.org/jdk/pull/26364/files/21704193..0e16f050

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

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

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

From djelinski at openjdk.org  Thu Jul 17 12:34:14 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 17 Jul 2025 12:34:14 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
Message-ID: <BfmSxWK_QlU_xRgeDJ42C6CBn0PAgzINJ57MQG8JMPE=.6ccb4260-d3a5-4295-a09c-efb1f2add293@github.com>

On Tue, 8 Jul 2025 14:04:56 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 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

src/java.net.http/share/classes/jdk/internal/net/http/AltSvcProcessor.java line 164:

> 162:             // serialized form of an origin (defined in section 6.2 of RFC-6454)
> 163:             try {
> 164:                 origin = Origin.fromASCIISerializedForm(frame.getOrigin());

Do we check if the origin is authoritative before processing the alt service? I don't see that here

src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 419:

> 417:                 .thenApply((eimpl) -> {synchronized (Exchange.this) {exchImpl = eimpl;}
> 418:                     checkCancelled(); return eimpl; })
> 419:                 .thenApply(Function.identity());

Suggestion:

                .copy();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2210059133
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2209566030

From coleenp at openjdk.org  Thu Jul 17 12:39:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 17 Jul 2025 12:39:51 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
In-Reply-To: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
Message-ID: <aTs018gQ4ULkVAXdGUZiX-g7gKJkHEbMjKCob8i9FYA=.208a442c-52dc-4569-9c27-596fd1f94121@github.com>

On Wed, 2 Jul 2025 00:18:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

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

src/hotspot/share/classfile/modules.cpp line 777:

> 775:   if (CDSConfig::is_using_full_module_graph()) {
> 776:     precond(unnamed_module == ClassLoaderDataShared::archived_boot_unnamed_module());
> 777:     unnamed_module->restore_archived_oops(boot_loader_data);

If you're restoring the module oop from the archive, what is the module oop passed into this that the rest of the code is using?

src/java.base/share/classes/jdk/internal/loader/BootLoader.java line 71:

> 69:         }
> 70:         jla.addEnableNativeAccess(UNNAMED_MODULE);
> 71:         setBootLoaderUnnamedModule0(UNNAMED_MODULE);

Here it's being called.  Should this be called?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26082#discussion_r2213207332
PR Review Comment: https://git.openjdk.org/jdk/pull/26082#discussion_r2213222965

From coleenp at openjdk.org  Thu Jul 17 12:39:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 17 Jul 2025 12:39:52 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
In-Reply-To: <aTs018gQ4ULkVAXdGUZiX-g7gKJkHEbMjKCob8i9FYA=.208a442c-52dc-4569-9c27-596fd1f94121@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
 <aTs018gQ4ULkVAXdGUZiX-g7gKJkHEbMjKCob8i9FYA=.208a442c-52dc-4569-9c27-596fd1f94121@github.com>
Message-ID: <I6QtmOydf5-vfixmLTwYX2aO6cEM_GUjNaxnAELfFDs=.4ffabffc-a01a-4d7e-8b3a-26deac5120c6@github.com>

On Thu, 17 Jul 2025 12:29:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> 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.
>
> src/hotspot/share/classfile/modules.cpp line 777:
> 
>> 775:   if (CDSConfig::is_using_full_module_graph()) {
>> 776:     precond(unnamed_module == ClassLoaderDataShared::archived_boot_unnamed_module());
>> 777:     unnamed_module->restore_archived_oops(boot_loader_data);
> 
> If you're restoring the module oop from the archive, what is the module oop passed into this that the rest of the code is using?

If you're storing the unnamed module oop in the archive should this method not be called?  If it is, what are you saving by archiving the unnamed module?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26082#discussion_r2213221120

From rriggs at openjdk.org  Thu Jul 17 13:43:49 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Jul 2025 13:43:49 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v2]
In-Reply-To: <Ehgm-dIuodCjPcGT3jTRlwu5nIucpKgky-oyeBOhQUA=.8ef8181a-a701-4632-923e-363290e00a6a@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
 <Ehgm-dIuodCjPcGT3jTRlwu5nIucpKgky-oyeBOhQUA=.8ef8181a-a701-4632-923e-363290e00a6a@github.com>
Message-ID: <cD47TAXeyrQ2y4fIUDfQ4MzjDPuVLKkWb9tJLX1jW_o=.53cd144c-ec8d-4c86-8fb1-5f1844c0a041@github.com>

On Thu, 17 Jul 2025 12:28:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comment to COMPAT static field.

src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 51:

> 49: 
> 50:     private boolean exact;  // this decimal is an exact fp
> 51:     private boolean away;  // this decimal has a larger magnitude than fp

Drive by comment.  
The name "away" doesn't convey enough information nor the implications. A longer comment somewhere might be in order.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26364#discussion_r2213385118

From rgiulietti at openjdk.org  Thu Jul 17 13:50:50 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Jul 2025 13:50:50 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v2]
In-Reply-To: <cD47TAXeyrQ2y4fIUDfQ4MzjDPuVLKkWb9tJLX1jW_o=.53cd144c-ec8d-4c86-8fb1-5f1844c0a041@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
 <Ehgm-dIuodCjPcGT3jTRlwu5nIucpKgky-oyeBOhQUA=.8ef8181a-a701-4632-923e-363290e00a6a@github.com>
 <cD47TAXeyrQ2y4fIUDfQ4MzjDPuVLKkWb9tJLX1jW_o=.53cd144c-ec8d-4c86-8fb1-5f1844c0a041@github.com>
Message-ID: <CrzAD4dKbyXYFxsZhTgI9N3CXhQdWB7110ZcuZgBGb8=.926420c3-4f37-4f31-ad03-375d4c13f0b2@github.com>

On Thu, 17 Jul 2025 13:41:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added comment to COMPAT static field.
>
> src/java.base/share/classes/jdk/internal/math/FormattedFPDecimal.java line 51:
> 
>> 49: 
>> 50:     private boolean exact;  // this decimal is an exact fp
>> 51:     private boolean away;  // this decimal has a larger magnitude than fp
> 
> Drive by comment.  
> The name "away" doesn't convey enough information nor the implications. A longer comment somewhere might be in order.

This is IEEE 754 jargon to say "away from zero", so towards the same signed infinity.
I'll make the comment clearer in the next commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26364#discussion_r2213403030

From duke at openjdk.org  Thu Jul 17 13:55:55 2025
From: duke at openjdk.org (Pooja-DP)
Date: Thu, 17 Jul 2025 13:55:55 GMT
Subject: Integrated: 8361697: Remove duplicate message  in
 MainResources.properties
In-Reply-To: <apRAelAuEvvGzVSK4_pllZvS9hloXO3UE6_2CRuCX28=.0d98fffe-f426-4523-b03d-a9d9bda81799@github.com>
References: <apRAelAuEvvGzVSK4_pllZvS9hloXO3UE6_2CRuCX28=.0d98fffe-f426-4523-b03d-a9d9bda81799@github.com>
Message-ID: <P0VUr1-MCgiYTIAxeCShg-VXUZ3uTZPWU8HoqP-eebI=.58937189-6feb-4a88-ba18-5a22fa8e7775@github.com>

On Wed, 9 Jul 2025 10:32:47 GMT, Pooja-DP <duke at openjdk.org> wrote:

> Bug reference: https://bugs.openjdk.org/browse/JDK-8361697
> 
> The following message is removed:
> 
> `
> MSG_BundlerFailed=Error: Bundler "{1}" ({0}) failed to produce a package`
> 
> Signed-off-by: Pooja.D.P1 <Pooja.D.P1 at ibm.com>

This pull request has now been integrated.

Changeset: dc08cf01
Author:    Pooja-DP <148474762+Pooja-DP at users.noreply.github.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dc08cf016eaa4bc333c47b3e7264bf1eae6d330a
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8361697: Remove duplicate message  in MainResources.properties

Reviewed-by: rriggs, asemenyuk

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

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

From rgiulietti at openjdk.org  Thu Jul 17 14:16:52 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Jul 2025 14:16:52 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
Message-ID: <MXCeeaIUUckQu-h3Q0vdW1LZg9LDaJGCxmREH-DLTnk=.bafc71a3-6bc4-4118-aa0c-0a0cda81881c@github.com>

On Thu, 17 Jul 2025 07:20:34 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 IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` 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...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace casting with `as_Region()` in `generate_string_range_check`

src/java.base/share/classes/java/lang/StringCoding.java line 130:

> 128:      * <p>
> 129:      * This method assumes that {@code sa} is encoded in UTF-16, and hence,
> 130:      * each {@code char} maps to 2 bytes.

Since `sa` is assumed to be encoded in UTF-16, what's the point of the previous paragraph?

src/java.base/share/classes/java/lang/StringCoding.java line 132:

> 130:      * each {@code char} maps to 2 bytes.
> 131:      * </p><p>
> 132:      * {@code sp} is encoded in ISO-8859-1. There each {@code byte} corresponds

As this is an index, it doesn't make sense to state that it is encoded in ISO-8859-1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2213428956
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2213429091

From rgiulietti at openjdk.org  Thu Jul 17 14:16:53 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Jul 2025 14:16:53 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
Message-ID: <gO2q1V0LZuXhcboQGWSJTzP4_VFEQ6r4deaKX6bcpv4=.206710a6-3f28-430b-93c3-bbb1c0aee977@github.com>

On Thu, 10 Jul 2025 12:18:25 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace casting with `as_Region()` in `generate_string_range_check`
>
> 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.

I think this is incorrect.
This is the index of a character (two bytes).
As it is used in `encodeISOArray0()`, it is incremented by 1 and passed to `StringUTF16.getChar()`, where it is multiplied by 2 to obtain the real `byte[]` index.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2213466146

From rgiulietti at openjdk.org  Thu Jul 17 14:31:56 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Jul 2025 14:31:56 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
Message-ID: <yu8kjKN35lgZh1rQGK-KCpNHObLQlkPLrzWVpQ9Gnc8=.e9684b18-ec3e-4164-a22e-1b5fdde7344f@github.com>

On Thu, 17 Jul 2025 07:20:34 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 IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` 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...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace casting with `as_Region()` in `generate_string_range_check`

What is the thinking when an `@IntrinsicCandidate` method invokes another `@IntrinsicCandidate` method?
Which part is responsible for the checks?

For example, the Java code of `StringCoding.encodeISOArray0()` invokes `StringUTF16.getChar()`, another `@IntrinsicCandidate` method. The latter does not check its arguments (OK, there's an `assert`, but this is a weak check). The invocation from `encodeISOArray0()` is fine and safe, but `getChar()` is invoked by other parts of the code.

So what is the general strategy? Add checks to `getChar()` and rely on the runtime to eliminate redundant checks?

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

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3084301249

From rriggs at openjdk.org  Thu Jul 17 14:35:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Jul 2025 14:35:53 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>
Message-ID: <hkX-Krx5Kn-vkpQ5gstaiBAiClrFWp4epdpdH0ZW6pQ=.c0f112b9-81eb-4d9a-976d-6e0062812596@github.com>

On Thu, 10 Jul 2025 12:20:45 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace casting with `as_Region()` in `generate_string_range_check`
>
> 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.

The reference of `sa.length` is likely wrong also, as it is the source length in bytes but for the index check should be checking the source length in chars.
It might be worth trying to find or create a test for the accidental incorrect interpretation of length in bytes vs chars..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2213528045

From rgiulietti at openjdk.org  Thu Jul 17 14:42:55 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Jul 2025 14:42:55 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
Message-ID: <gVwo5i2-Xm3OpSnQvI0SGlOpGJ6MXhOLplcdwtCEuoc=.aac35f48-c408-4c7e-b22b-1432737da015@github.com>

On Thu, 17 Jul 2025 07:20:34 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 IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` 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...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace casting with `as_Region()` in `generate_string_range_check`

src/java.base/share/classes/java/lang/StringCoding.java line 150:

> 148:         Objects.requireNonNull(sa, "sa");
> 149:         Objects.requireNonNull(da, "da");
> 150:         Preconditions.checkFromIndexSize(sp, len << 1, sa.length, Preconditions.AIOOBE_FORMATTER);

Since `sp` is a character index and `len` counts characters but `sa.length` is in bytes, this should look like so
Suggestion:

        Preconditions.checkFromIndexSize(sp, len, sa.length >>> 1, Preconditions.AIOOBE_FORMATTER);

or something similar.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2213543167

From tschatzl at openjdk.org  Thu Jul 17 14:50:46 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 17 Jul 2025 14:50:46 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v43]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <TtV0oPZQZrjta5-y-4_GqT7Xk0Qpxt2BlASdcJYFrP4=.78b09f04-0cd9-453d-8ca1-23805bca7982@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 59 commits:

 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into pull/23739
 - 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)
 - ... and 49 more: https://git.openjdk.org/jdk/compare/ea774b74...4b21868a

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

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=42
  Stats: 7120 lines in 112 files changed: 2589 ins; 3590 del; 941 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 yzheng at openjdk.org  Thu Jul 17 15:04:52 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 17 Jul 2025 15:04:52 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
Message-ID: <RT93K6Emgyktk7vf53EKMZrKIp4zGqVus9x5V7mmGAI=.e05a92eb-4911-4dcc-bbae-8e4a38cf0723@github.com>

On Thu, 17 Jul 2025 07:20:34 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 IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` 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...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace casting with `as_Region()` in `generate_string_range_check`

test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 25:

> 23: 
> 24: /*
> 25:  * @test

could you please add ` * @requires !vm.graal.enabled`? Graal is failing this test

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2213601907

From cushon at openjdk.org  Thu Jul 17 15:25:59 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 17 Jul 2025 15:25:59 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: <gDgAzVOWllN9McWLxfco_q2EfeioJS8IcZL5zkHDBjY=.21f01a62-6a26-4412-9dba-258f600bc5fc@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

src/java.base/share/classes/java/nio/BufferCleaner.java line 203:

> 201:     }
> 202: 
> 203:     private static final class CleaningThread extends Thread {

Similar to https://bugs.openjdk.org/browse/JDK-8346124, should this be creating an `InnocuousThread`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2213655440

From duke at openjdk.org  Thu Jul 17 15:32:32 2025
From: duke at openjdk.org (cagliostro92)
Date: Thu, 17 Jul 2025 15:32:32 GMT
Subject: RFR: 8358530: Properties#list should warn against non-String
 values [v3]
In-Reply-To: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
References: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
Message-ID: <7GTzRxnXL2WlZDaFC5G6uirYlUs-jhsfNoEREBwQe3U=.8468402d-e5c8-41bb-9887-b73880bb0d71@github.com>

> Trivial PR to enhance Javadoc for the `Properties#list` method, which has cost me some debugging time.

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

  8358530: adds oxford comma

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25334/files
  - new: https://git.openjdk.org/jdk/pull/25334/files/8d7e3d2f..a0c7572f

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

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

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

From duke at openjdk.org  Thu Jul 17 15:32:32 2025
From: duke at openjdk.org (cagliostro92)
Date: Thu, 17 Jul 2025 15:32:32 GMT
Subject: RFR: 8358530: Properties#list should warn against non-String
 values [v3]
In-Reply-To: <t_VofOPyeSdmQ0YggdCmaG07qvCtWXpA-kDYfITJWq4=.9811444e-4bdf-44db-9144-24c3b7fc63d2@github.com>
References: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
 <9Wr-amACg6uZeYoPf5Qfo-UwVDVvITaxpcNksaf6xY4=.54c2ac06-5e6d-41af-a4dd-b52b31824143@github.com>
 <sn5U00RQ3hVAIuwPMPKcWtbmuwFZNy2hLcgGOleXqFc=.9288a26a-41bf-49ce-9129-63d4a4786470@github.com>
 <t_VofOPyeSdmQ0YggdCmaG07qvCtWXpA-kDYfITJWq4=.9811444e-4bdf-44db-9144-24c3b7fc63d2@github.com>
Message-ID: <mbre3gMkx8Hi6e2TORh60tyn5H_Vm0c2l8x5fBCcXxE=.522ecb34-dbdc-4acd-b77c-3a742df29fa5@github.com>

On Wed, 16 Jul 2025 17:42:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> My bad, sorry. Fixed with 8d7e3d2fde65bd1e4ad85eca5ea93a430e2e8238
>
> Thanks for the changes. The current form seems reasonable to me, although others might have comments. I created the following CSR, [JDK-8362447](https://bugs.openjdk.org/browse/JDK-8362447) for you. We will need a reviewer to take a look at these changes as well. (Nit: we could use the oxford comma in the class description changes.)

done ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25334#discussion_r2213669954

From rgiulietti at openjdk.org  Thu Jul 17 15:35:52 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Jul 2025 15:35:52 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 String-related intrinsics [v8]
In-Reply-To: <yu8kjKN35lgZh1rQGK-KCpNHObLQlkPLrzWVpQ9Gnc8=.e9684b18-ec3e-4164-a22e-1b5fdde7344f@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
 <yu8kjKN35lgZh1rQGK-KCpNHObLQlkPLrzWVpQ9Gnc8=.e9684b18-ec3e-4164-a22e-1b5fdde7344f@github.com>
Message-ID: <PmH2X0PiqCK7Zz7HQ5d9948bfKM950ziS9VN2Epf6Dk=.fab73b5d-5511-47ef-9f93-4b9496820a1d@github.com>

On Thu, 17 Jul 2025 14:29:08 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> What is the thinking when an `@IntrinsicCandidate` method invokes another `@IntrinsicCandidate` method? Which part is responsible for the checks?
> 
> For example, the Java code of `StringCoding.encodeISOArray0()` invokes `StringUTF16.getChar()`, another `@IntrinsicCandidate` method. The latter does not check its arguments (OK, there's an `assert`, but this is a weak check). The invocation from `encodeISOArray0()` is fine and safe, but `getChar()` is invoked by other parts of the code.
> 
> So what is the general strategy? Add checks to `getChar()` and rely on the runtime to eliminate redundant checks?

To reformulate my confusing question for the above example, there are apparently around 75-80 invocations of `getChar()`. How to make sure that they are all safe? Some are easy to verify, but others are not.

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

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3084525709

From naoto at openjdk.org  Thu Jul 17 16:50:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 17 Jul 2025 16:50:51 GMT
Subject: RFR: 8361972: Clarify the condition of System.console() about
 standard input/output [v2]
In-Reply-To: <HD9ktp88gpejD3h9DLO6HMAHiRNoTnHV-U5fW0xJPhk=.6a3b8a69-4c1b-43f5-ad6a-18f10196c70e@github.com>
References: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
 <TKnCmtTeM0-f1yunDtO8zRno4ZbVWxhiWN0kagttFns=.3f8e4e55-84f4-4eee-924a-e04e46485c12@github.com>
 <HD9ktp88gpejD3h9DLO6HMAHiRNoTnHV-U5fW0xJPhk=.6a3b8a69-4c1b-43f5-ad6a-18f10196c70e@github.com>
Message-ID: <YXJTMmkw39pSM87RT9BqXM9rwE0KHTcZF7pG3rUfvL8=.ac8e50b0-524f-4f64-8e2f-1e8999909860@github.com>

On Thu, 17 Jul 2025 07:40:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wording modification
>
> src/java.base/share/classes/java/io/Console.java line 51:
> 
>> 49:  * console. Regardless of how the virtual machine was created, it may not
>> 50:  * have a console if either the standard input or output stream is
>> 51:  * redirected.
> 
> Can you clarify what the intent of "it may not have a console" is? Initially I though the intention was that there is no Console when either stdout or stdin is redirected. However, the sentence suggests there may or may not be a Console.

I was considering the case for `jshell`, where its `System.console()` returns a `Console` instance regardless of the `isTTY` state:

https://github.com/openjdk/jdk/blob/bd55d7a49514da9fa4de0d4a372956e21deab4d2/src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java#L70

That led me to use `may` in the updated spec. I'd appreciate your suggestions on wording.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26299#discussion_r2213837754

From liach at openjdk.org  Thu Jul 17 16:55:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Jul 2025 16:55:25 GMT
Subject: RFR: 8361638: java.lang.classfile.CodeBuilder.catchingAll doesn't
 throw IllegalArgumentException if an existing catch block catches all
 exceptions
Message-ID: <EsgujIABpxOwwcDzA9fsWpfB9YMY0XIzlmJIFwipVXY=.8f40bdea-49b4-468b-83df-b22951a23d41@github.com>

The detection of catch builder arguments is not working for catch-all blocks. Update this to track CP indices including 0 so we can more easily validate the incoming ClassDesc are all non-primitive and there is no duplicate.

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

Commit messages:
 - Formatting
 - 8361638: java.lang.classfile.CodeBuilder.catchingAll doesn't throw IllegalArgumentException if an existing catch block catches all exceptions

Changes: https://git.openjdk.org/jdk/pull/26372/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26372&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361638
  Stats: 63 lines in 2 files changed: 40 ins; 9 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/26372.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26372/head:pull/26372

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

From darcy at openjdk.org  Thu Jul 17 17:05:51 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 17 Jul 2025 17:05:51 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
In-Reply-To: <vyuFN3_Mg4Alj9wZ0j_OHNO6epGCQFUiNtdRXinO-uU=.b1f2d2e2-d030-4109-aa43-6214afd01661@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
 <rHPoN0EcX0YwnfCob89AMOw0GFsw8MJtmcU7kPWHEOk=.ef465d82-5a17-4fba-8d40-300066d76cd0@github.com>
 <vyuFN3_Mg4Alj9wZ0j_OHNO6epGCQFUiNtdRXinO-uU=.b1f2d2e2-d030-4109-aa43-6214afd01661@github.com>
Message-ID: <NBYvF7bHRYaRjED4SKD6nYqOD_c6hpkVs71THvodtMU=.87b243d1-4f42-4517-bddf-c11d89e2ad78@github.com>

On Thu, 17 Jul 2025 10:58:30 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/FdLibm.java line 815:
>> 
>>> 813:          */
>>> 814: 
>>> 815:         private static final int init_jk[] = {2, 3, 4, 6}; // initial value for jk
>> 
>> Suggestion:
>> 
>>         @Stable private static final int init_jk[] = {2, 3, 4, 6}; // initial value for jk
>
> Suggestion:
> 
>         @Stable
>         private static final int[] init_jk = {2, 3, 4, 6}; // initial value for jk

Missed that array on my edit; will add. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26341#discussion_r2213864318

From liach at openjdk.org  Thu Jul 17 17:10:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Jul 2025 17:10:48 GMT
Subject: RFR: 8345836: Stable annotation documentation is incomplete
In-Reply-To: <5MPznGbnl6jsZ-og3SMtakdoHRjfRf8xZTKUUCCFqvk=.6e785ddf-cb06-48a1-ad40-70faaa7e8ee4@github.com>
References: <5MPznGbnl6jsZ-og3SMtakdoHRjfRf8xZTKUUCCFqvk=.6e785ddf-cb06-48a1-ad40-70faaa7e8ee4@github.com>
Message-ID: <KBZuUyH9Y5SgkRpPhJl1hNaH0vwbnHzDe_xPKn-Ym0k=.c95834fe-80b5-4b33-a008-8ef2fee35f59@github.com>

On Wed, 16 Jul 2025 17:45:23 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this documentation update, authored by @rose00 and originally pushed to the Leyden repo in [this PR](https://github.com/openjdk/leyden/pull/26), where more comments can be found regarding this update.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26355#pullrequestreview-3030356983

From liach at openjdk.org  Thu Jul 17 17:16:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Jul 2025 17:16:50 GMT
Subject: RFR: 8358530: Properties#list should warn against non-String
 values [v3]
In-Reply-To: <7GTzRxnXL2WlZDaFC5G6uirYlUs-jhsfNoEREBwQe3U=.8468402d-e5c8-41bb-9887-b73880bb0d71@github.com>
References: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
 <7GTzRxnXL2WlZDaFC5G6uirYlUs-jhsfNoEREBwQe3U=.8468402d-e5c8-41bb-9887-b73880bb0d71@github.com>
Message-ID: <hz-L_uWNazJ_E9B8LKjSDwqDlqVTIn1GdqB-oIKyOBw=.9720d894-f5d4-480f-abb9-c3e48d0827b4@github.com>

On Thu, 17 Jul 2025 15:32:32 GMT, cagliostro92 <duke at openjdk.org> wrote:

>> Trivial PR to enhance Javadoc for the `Properties#list` method, which has cost me some debugging time.
>
> cagliostro92 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8358530: adds oxford comma

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25334#pullrequestreview-3030375304

From jlu at openjdk.org  Thu Jul 17 17:41:48 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 17 Jul 2025 17:41:48 GMT
Subject: RFR: 8361972: Clarify the condition of System.console() about
 standard input/output [v2]
In-Reply-To: <YXJTMmkw39pSM87RT9BqXM9rwE0KHTcZF7pG3rUfvL8=.ac8e50b0-524f-4f64-8e2f-1e8999909860@github.com>
References: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
 <TKnCmtTeM0-f1yunDtO8zRno4ZbVWxhiWN0kagttFns=.3f8e4e55-84f4-4eee-924a-e04e46485c12@github.com>
 <HD9ktp88gpejD3h9DLO6HMAHiRNoTnHV-U5fW0xJPhk=.6a3b8a69-4c1b-43f5-ad6a-18f10196c70e@github.com>
 <YXJTMmkw39pSM87RT9BqXM9rwE0KHTcZF7pG3rUfvL8=.ac8e50b0-524f-4f64-8e2f-1e8999909860@github.com>
Message-ID: <PMI4a2USZ3ox-Oijc6Cu2xF8tCn6b2PdjRvGcWbBYl4=.17364eb2-cd38-47ea-b7d1-9d58c62767d4@github.com>

On Thu, 17 Jul 2025 16:48:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 51:
>> 
>>> 49:  * console. Regardless of how the virtual machine was created, it may not
>>> 50:  * have a console if either the standard input or output stream is
>>> 51:  * redirected.
>> 
>> Can you clarify what the intent of "it may not have a console" is? Initially I though the intention was that there is no Console when either stdout or stdin is redirected. However, the sentence suggests there may or may not be a Console.
>
> I was considering the case for `jshell`, where its `System.console()` returns a `Console` instance regardless of the `isTTY` state:
> 
> https://github.com/openjdk/jdk/blob/bd55d7a49514da9fa4de0d4a372956e21deab4d2/src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java#L70
> 
> That led me to use `may` in the updated spec. I'd appreciate your suggestions on wording.

Since the decision of whether a console exists is dependent on the implementation as specified,

> Whether a virtual machine has a console is dependent upon the underlying platform

And the existing wording in this paragraph uses open-ended words such as "may" and "typically", it makes sense to me that this change would follow the same style of wording. If you wanted to concretely define what this implementation does, using one of the `@impl` tags to describe the behavior could be an option?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26299#discussion_r2213927933

From darcy at openjdk.org  Thu Jul 17 17:44:04 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 17 Jul 2025 17:44:04 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
 [v2]
In-Reply-To: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
Message-ID: <vDpPRsDFcyHIeMXacdTdVMZEdVLCZcfauKSbutewigg=.0fc78693-c868-4ade-b8d6-956f87a25403@github.com>

> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.

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

  Respond to review feedback and update copyright.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26341/files
  - new: https://git.openjdk.org/jdk/pull/26341/files/7fec1518..a7b86ee5

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

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

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

From liach at openjdk.org  Thu Jul 17 17:57:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Jul 2025 17:57:16 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v4]
In-Reply-To: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
Message-ID: <FP4q5t1LPBzfa1OKvAu7gtt3vbY6vnzWBAKYYLKfQP8=.5c7ab552-f16d-4b13-93b6-fccc4386ed9a@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`.
> 
> 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

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

  avoid "non-atomic"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26258/files
  - new: https://git.openjdk.org/jdk/pull/26258/files/7563e6b7..3235899a

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

  Stats: 10 lines in 2 files changed: 2 ins; 0 del; 8 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 liach at openjdk.org  Thu Jul 17 18:02:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Jul 2025 18:02:50 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v3]
In-Reply-To: <KPkEWeFIcUBE3Xw611x9c2LDSucL0gO3BBQNS9tcd5w=.6302fefc-3bc0-48c7-aac4-83676ce7cd66@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <tCyx-XkttQoAnJcEOtC8SITb9NaurEROV_OjT-E3Imc=.320d74bc-5aa1-4d8a-9867-c767dea379c5@github.com>
 <KPkEWeFIcUBE3Xw611x9c2LDSucL0gO3BBQNS9tcd5w=.6302fefc-3bc0-48c7-aac4-83676ce7cd66@github.com>
Message-ID: <Vc9wAIM3m7VI_LqEzNWAQNsdt9pMiVR53ztfEBFrBpk=.dddfa782-d044-4090-98b7-c1fdd068481d@github.com>

On Wed, 16 Jul 2025 09:28:28 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   "may be non-atomic"
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 281:
> 
>> 279:  * <li>read write access modes for all {@code T}. On 32-bit platforms, access modes
>> 280:  *     {@code get} and {@code set} for {@code long}, {@code double} and {@code MemorySegment}
>> 281:  *     are supported but may be non-atomic, as described in Section {@jls 17.7}
> 
> Suggestion:
> 
>  *     are supported but may be non-atomic in the sense of Section {@jls 17.7}
> 
> 
> A useful taxonomy has atomic _read-modify-write_ operations (atomic updates, numeric atomic updates, bitwise atomic updates, like CASes, etc.), and atomic _access_ operations, that is, atomic loads and stores (atomic reads and writes).
> 
> But the reference to the JLS section here should clarify what is meant in this specific context, namely access operation, not read-modify-write operations.

Yep, to distinguish access and the encapsulated read-modify-write atomicity, I decided to avoid using "atomic"/"non-atomic" altogether - now it is just "make no atomicity guarantee"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26258#discussion_r2213964762

From liach at openjdk.org  Thu Jul 17 18:06:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Jul 2025 18:06:48 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
 [v2]
In-Reply-To: <vDpPRsDFcyHIeMXacdTdVMZEdVLCZcfauKSbutewigg=.0fc78693-c868-4ade-b8d6-956f87a25403@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
 <vDpPRsDFcyHIeMXacdTdVMZEdVLCZcfauKSbutewigg=.0fc78693-c868-4ade-b8d6-956f87a25403@github.com>
Message-ID: <5rCmSGQ2lJCDEvnl7sY8kJV2p2NwkxarKJZyoAXtid4=.e48bf026-0780-4a0c-8357-70fbe3c55cea@github.com>

On Thu, 17 Jul 2025 17:44:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback and update copyright.

These additions look reasonable.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26341#pullrequestreview-3030504704

From rgiulietti at openjdk.org  Thu Jul 17 18:06:49 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Jul 2025 18:06:49 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
In-Reply-To: <76CdiCuDBq45d6ke6zQnX_xdS3kQisxveFvPzKI_zLw=.40b46ae1-4560-426d-9ce6-5cd6de6a604c@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
 <76CdiCuDBq45d6ke6zQnX_xdS3kQisxveFvPzKI_zLw=.40b46ae1-4560-426d-9ce6-5cd6de6a604c@github.com>
Message-ID: <53NPuNOHhHglIfYV8cII3KS0IlYtAmBQbIC25APMMYw=.b1ff77df-cdc8-48ce-b0a4-888be98baff2@github.com>

On Wed, 16 Jul 2025 18:51:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> The methods directly affected by this update are atan, exp, and sin, cos, tan. The sin, cos, and tan method are affected by the updates to KernelRemPio2 and tan is also directly affected by its own updates.

@jddarcy What about the local arrays mentioned in my comment above

> The arrays at L.2257-2262 could be declared `static` and `@Stable` as well, and moved outside the method.

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

PR Comment: https://git.openjdk.org/jdk/pull/26341#issuecomment-3084966250

From jlu at openjdk.org  Thu Jul 17 18:09:48 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 17 Jul 2025 18:09:48 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v2]
In-Reply-To: <Ehgm-dIuodCjPcGT3jTRlwu5nIucpKgky-oyeBOhQUA=.8ef8181a-a701-4632-923e-363290e00a6a@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
 <Ehgm-dIuodCjPcGT3jTRlwu5nIucpKgky-oyeBOhQUA=.8ef8181a-a701-4632-923e-363290e00a6a@github.com>
Message-ID: <5h2vyeFRO_t6-cJOEC7LH3hy_VMz39QxXgj1Afaog7E=.34bfea42-3dbe-4881-9e0c-8bda32bbd15e@github.com>

On Thu, 17 Jul 2025 12:28:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comment to COMPAT static field.

Thanks for working on this Raffaello, the `DecimalFormat` and `DigitList` changes look good to me. Also, the JBS issue needs a `noreg-.*` tag.

src/java.base/share/classes/java/text/DigitList.java line 292:

> 290: 
> 291:     /*
> 292:      * This compatibility option will only be available for a *very* limited

I suppose the number of releases is dependent on if we run into any issues with this change. I'm wondering when is a good time to revisit this for removal. (I guess a few releases means maybe before the next LTS.)

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1769:

> 1767:      * fields (> 550 lines).
> 1768:      */
> 1769:     private static BinaryToASCIIConverter getCompatBinaryToASCIIConverter(double d, boolean isCompatibleFormat) {

Can we just remove the `isCompatibleFormat` param and pass true to `buf.dtoa` which should always be true as indicated by the method name and its usage?

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26364#pullrequestreview-3030364252
PR Review Comment: https://git.openjdk.org/jdk/pull/26364#discussion_r2213876548
PR Review Comment: https://git.openjdk.org/jdk/pull/26364#discussion_r2213961792

From liach at openjdk.org  Thu Jul 17 18:18:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Jul 2025 18:18:48 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
 [v2]
In-Reply-To: <vDpPRsDFcyHIeMXacdTdVMZEdVLCZcfauKSbutewigg=.0fc78693-c868-4ade-b8d6-956f87a25403@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
 <vDpPRsDFcyHIeMXacdTdVMZEdVLCZcfauKSbutewigg=.0fc78693-c868-4ade-b8d6-956f87a25403@github.com>
Message-ID: <9xZTuEGIm8Glb9CnBy1xLl8xfeqtJMR-EBHZVB1N85w=.41fb17e3-931c-4ff3-8481-ba45aa4712ce@github.com>

On Thu, 17 Jul 2025 17:44:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback and update copyright.

I think local arrays require more structural changes to the code, which might be why this patch did not include that change. However, note as said in #26355, such conversions are meaningful and would potentially allow performance boosts.

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

PR Comment: https://git.openjdk.org/jdk/pull/26341#issuecomment-3085001065

From mcimadamore at openjdk.org  Thu Jul 17 18:21:50 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 17 Jul 2025 18:21:50 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v4]
In-Reply-To: <FP4q5t1LPBzfa1OKvAu7gtt3vbY6vnzWBAKYYLKfQP8=.5c7ab552-f16d-4b13-93b6-fccc4386ed9a@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <FP4q5t1LPBzfa1OKvAu7gtt3vbY6vnzWBAKYYLKfQP8=.5c7ab552-f16d-4b13-93b6-fccc4386ed9a@github.com>
Message-ID: <EEwjPPAIwFjQE2YdbrBO_K8ZJHunT4UZLtWwLKUhXCY=.8214becc-438c-4590-b3e2-91beb89a45c8@github.com>

On Thu, 17 Jul 2025 17:57:16 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
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid "non-atomic"

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 281:

> 279:  * <li>read write access modes for all {@code T}.  Access modes {@code get} and
> 280:  *     {@code set} for {@code long}, {@code double} and {@code MemorySegment}
> 281:  *     are supported but have no atomicity guarantee; in particular, the

I think just a quick reference to the spec is fine, something like "are supported but provide no atomicity guarantees, as described in Section 17.7 of The Java Language Specification"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26258#discussion_r2213998491

From liach at openjdk.org  Thu Jul 17 18:28:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Jul 2025 18:28:05 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v4]
In-Reply-To: <EEwjPPAIwFjQE2YdbrBO_K8ZJHunT4UZLtWwLKUhXCY=.8214becc-438c-4590-b3e2-91beb89a45c8@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <FP4q5t1LPBzfa1OKvAu7gtt3vbY6vnzWBAKYYLKfQP8=.5c7ab552-f16d-4b13-93b6-fccc4386ed9a@github.com>
 <EEwjPPAIwFjQE2YdbrBO_K8ZJHunT4UZLtWwLKUhXCY=.8214becc-438c-4590-b3e2-91beb89a45c8@github.com>
Message-ID: <f4fpeKRuITjOWw9xhp1Ueup1ITfv247GZVKxx17XmLU=.a5a23ae2-5231-47cc-90c8-511d0067a3b1@github.com>

On Thu, 17 Jul 2025 18:18:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   avoid "non-atomic"
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 281:
> 
>> 279:  * <li>read write access modes for all {@code T}.  Access modes {@code get} and
>> 280:  *     {@code set} for {@code long}, {@code double} and {@code MemorySegment}
>> 281:  *     are supported but have no atomicity guarantee; in particular, the
> 
> I think just a quick reference to the spec is fine, something like "are supported but provide no atomicity guarantees, as described in Section 17.7 of The Java Language Specification"

Sure, I will simplify this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26258#discussion_r2214007372

From liach at openjdk.org  Thu Jul 17 18:28:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Jul 2025 18:28:04 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v5]
In-Reply-To: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
Message-ID: <lirArNH2rA5pWS5OGkhT15w6_dGdbt-Ds0jwrxPoC5k=.18aff583-5acf-49e7-9cbd-1a1e05fc3612@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`.
> 
> 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

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

  Simplify wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26258/files
  - new: https://git.openjdk.org/jdk/pull/26258/files/3235899a..8e702d27

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

  Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 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 naoto at openjdk.org  Thu Jul 17 18:28:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 17 Jul 2025 18:28:51 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v2]
In-Reply-To: <Ehgm-dIuodCjPcGT3jTRlwu5nIucpKgky-oyeBOhQUA=.8ef8181a-a701-4632-923e-363290e00a6a@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
 <Ehgm-dIuodCjPcGT3jTRlwu5nIucpKgky-oyeBOhQUA=.8ef8181a-a701-4632-923e-363290e00a6a@github.com>
Message-ID: <o9PEv-AjuFI373A-GJqunNxwL_xxxm4erHyqFn2uEVs=.404dd4e1-cd90-4db5-bc27-254d1c740fb0@github.com>

On Thu, 17 Jul 2025 12:28:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comment to COMPAT static field.

Good to see this enhancement, Raffaello. Are you planning to provide some test cases for the change, confirming the implementation switches between old/new depending on the system property?

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

PR Comment: https://git.openjdk.org/jdk/pull/26364#issuecomment-3085028742

From missa at openjdk.org  Thu Jul 17 18:46:06 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Thu, 17 Jul 2025 18:46:06 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v2]
In-Reply-To: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
Message-ID: <9pe9LuUrBnk6A2TQ2emhgonljAvnJLcmSV_lEbrYIlo=.fec9b081-d6ae-4d85-8826-489828d9f442@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.

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

  Move error bound to separate section in comment header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26152/files
  - new: https://git.openjdk.org/jdk/pull/26152/files/9c5cc60c..c0adc8b3

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

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 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 missa at openjdk.org  Thu Jul 17 18:51:47 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Thu, 17 Jul 2025 18:51:47 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms
In-Reply-To: <fuR6ms-rfPnU-30v-gBJpQE0xKOk-a9_qgx0TTrZ7bA=.f13bb99f-2863-4776-9fec-1e8b8c3873e7@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>
 <fuR6ms-rfPnU-30v-gBJpQE0xKOk-a9_qgx0TTrZ7bA=.f13bb99f-2863-4776-9fec-1e8b8c3873e7@github.com>
Message-ID: <ia-MhOd66FkoS1hpvWHK_jGlQt_G9cytK6vK4zN9q-I=.ad70d25f-3d9e-4461-ad6b-744c33fc9edc@github.com>

On Thu, 10 Jul 2025 21:23:50 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
> 
> 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.

I included the error bound as a separate section of the comment header in the stub generator source file. Also, the input ranges are covered in `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3085084538

From liach at openjdk.org  Thu Jul 17 19:07:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Jul 2025 19:07:32 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v7]
In-Reply-To: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
Message-ID: <V4ikyLrr4JkS2tuE46GnTSsmI2g_dRR6b73da_4i13Q=.4c0677da-afb3-4be5-b1b2-97223069655e@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 12 commits:

 - Fix sourceversion test
 - 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
 - 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
 - ... and 2 more: https://git.openjdk.org/jdk/compare/bd55d7a4...0f9c501c

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

Changes: https://git.openjdk.org/jdk/pull/25017/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25017&range=06
  Stats: 1279 lines in 6 files changed: 1137 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 rgiulietti at openjdk.org  Thu Jul 17 19:08:48 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Jul 2025 19:08:48 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v2]
In-Reply-To: <5h2vyeFRO_t6-cJOEC7LH3hy_VMz39QxXgj1Afaog7E=.34bfea42-3dbe-4881-9e0c-8bda32bbd15e@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
 <Ehgm-dIuodCjPcGT3jTRlwu5nIucpKgky-oyeBOhQUA=.8ef8181a-a701-4632-923e-363290e00a6a@github.com>
 <5h2vyeFRO_t6-cJOEC7LH3hy_VMz39QxXgj1Afaog7E=.34bfea42-3dbe-4881-9e0c-8bda32bbd15e@github.com>
Message-ID: <AJ1hQLeqtGlLi9M7j3aRnz93xLE7D5Hut8iblolC7iA=.028e01c6-de00-4eb5-bb18-bd24dbd404a3@github.com>

On Thu, 17 Jul 2025 17:58:51 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added comment to COMPAT static field.
>
> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1769:
> 
>> 1767:      * fields (> 550 lines).
>> 1768:      */
>> 1769:     private static BinaryToASCIIConverter getCompatBinaryToASCIIConverter(double d, boolean isCompatibleFormat) {
> 
> Can we just remove the `isCompatibleFormat` param and pass true to `buf.dtoa` which should always be true as indicated by the method name and its usage?

There are many more changes that I've planned in `FloatingDecimal`, including this one and the removal of unused methods.
For this PR, however, I just wanted to keep the changes in `FloatingDecimal` minimal, focused on the replacement with the new algorithm.

But I have no problems with your proposal, if you insist.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26364#discussion_r2214084343

From liach at openjdk.org  Thu Jul 17 19:13:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Jul 2025 19:13:12 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v8]
In-Reply-To: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
Message-ID: <uAQ8Ruh85CVDpj_pUznOWUA0H4FvKxjonlPGdWJgjW8=.a6d8d624-3143-4058-8871-72cba950540a@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 incrementally with one additional commit since the last revision:

  Fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25017/files
  - new: https://git.openjdk.org/jdk/pull/25017/files/0f9c501c..b39504fc

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

  Stats: 15 lines in 3 files changed: 3 ins; 6 del; 6 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 rgiulietti at openjdk.org  Thu Jul 17 19:23:52 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Jul 2025 19:23:52 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v2]
In-Reply-To: <o9PEv-AjuFI373A-GJqunNxwL_xxxm4erHyqFn2uEVs=.404dd4e1-cd90-4db5-bc27-254d1c740fb0@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
 <Ehgm-dIuodCjPcGT3jTRlwu5nIucpKgky-oyeBOhQUA=.8ef8181a-a701-4632-923e-363290e00a6a@github.com>
 <o9PEv-AjuFI373A-GJqunNxwL_xxxm4erHyqFn2uEVs=.404dd4e1-cd90-4db5-bc27-254d1c740fb0@github.com>
Message-ID: <jgDQDK9p3jdk1Db3h0iWFac2A6Ht2rNpiSj0RomGtYg=.945c9b1e-1803-470e-8fd3-aab40f714754@github.com>

On Thu, 17 Jul 2025 18:26:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added comment to COMPAT static field.
>
> Good to see this enhancement, Raffaello. Are you planning to provide some test cases for the change, confirming the implementation switches between old/new depending on the system property?

@naotoj Do you mean adding a test with values known to have slightly different outcomes? Sure, will do.

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

PR Comment: https://git.openjdk.org/jdk/pull/26364#issuecomment-3085207988

From naoto at openjdk.org  Thu Jul 17 19:39:48 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 17 Jul 2025 19:39:48 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v2]
In-Reply-To: <o9PEv-AjuFI373A-GJqunNxwL_xxxm4erHyqFn2uEVs=.404dd4e1-cd90-4db5-bc27-254d1c740fb0@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
 <Ehgm-dIuodCjPcGT3jTRlwu5nIucpKgky-oyeBOhQUA=.8ef8181a-a701-4632-923e-363290e00a6a@github.com>
 <o9PEv-AjuFI373A-GJqunNxwL_xxxm4erHyqFn2uEVs=.404dd4e1-cd90-4db5-bc27-254d1c740fb0@github.com>
Message-ID: <SgyqhFlGbzacV_bV9cWNYUiwfVeIwt9PaQnbFSzyc3c=.52676b13-0e61-49d4-bfbf-528c3fd67934@github.com>

On Thu, 17 Jul 2025 18:26:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added comment to COMPAT static field.
>
> Good to see this enhancement, Raffaello. Are you planning to provide some test cases for the change, confirming the implementation switches between old/new depending on the system property?

> @naotoj Do you mean adding a test with values known to have slightly different outcomes? Sure, will do.

Yes, as in the JBS issue

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

PR Comment: https://git.openjdk.org/jdk/pull/26364#issuecomment-3085253076

From jlu at openjdk.org  Thu Jul 17 20:14:47 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 17 Jul 2025 20:14:47 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v2]
In-Reply-To: <AJ1hQLeqtGlLi9M7j3aRnz93xLE7D5Hut8iblolC7iA=.028e01c6-de00-4eb5-bb18-bd24dbd404a3@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
 <Ehgm-dIuodCjPcGT3jTRlwu5nIucpKgky-oyeBOhQUA=.8ef8181a-a701-4632-923e-363290e00a6a@github.com>
 <5h2vyeFRO_t6-cJOEC7LH3hy_VMz39QxXgj1Afaog7E=.34bfea42-3dbe-4881-9e0c-8bda32bbd15e@github.com>
 <AJ1hQLeqtGlLi9M7j3aRnz93xLE7D5Hut8iblolC7iA=.028e01c6-de00-4eb5-bb18-bd24dbd404a3@github.com>
Message-ID: <O8xvVkXgIksVKYK7WP5nTW2AyI183wVxRZ3boODVrkg=.b02604fd-7c09-4138-b57a-3a5c486449a8@github.com>

On Thu, 17 Jul 2025 19:06:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1769:
>> 
>>> 1767:      * fields (> 550 lines).
>>> 1768:      */
>>> 1769:     private static BinaryToASCIIConverter getCompatBinaryToASCIIConverter(double d, boolean isCompatibleFormat) {
>> 
>> Can we just remove the `isCompatibleFormat` param and pass true to `buf.dtoa` which should always be true as indicated by the method name and its usage?
>
> There are many more changes that I've planned in `FloatingDecimal`, including this one and the removal of unused methods.
> For this PR, however, I just wanted to keep the changes in `FloatingDecimal` minimal, focused on the replacement with the new algorithm.
> 
> But I have no problems with your proposal, if you insist.

Understood, in that case the current form is fine with me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26364#discussion_r2214203114

From liach at openjdk.org  Thu Jul 17 20:20:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Jul 2025 20:20:33 GMT
Subject: RFR: 8361614: Missing sub-int value validation in the Class-File
 API [v4]
In-Reply-To: <uJfr8RQBE0nk26hcVMgU6JXU6cfPbSd1b8HCGgazH1s=.7916f354-c513-4c39-b999-6769b28551d6@github.com>
References: <uJfr8RQBE0nk26hcVMgU6JXU6cfPbSd1b8HCGgazH1s=.7916f354-c513-4c39-b999-6769b28551d6@github.com>
Message-ID: <au6zr_bZ2qn0SVKEVI2V4XAIIdzF8sc39ANdkhV7bvo=.b7736f96-211e-41be-b424-322824549cf6@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:

  Package-level information

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26201/files
  - new: https://git.openjdk.org/jdk/pull/26201/files/96f50b0f..15f00c8c

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

  Stats: 16 lines in 1 file changed: 9 ins; 0 del; 7 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 darcy at openjdk.org  Thu Jul 17 21:11:48 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 17 Jul 2025 21:11:48 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
In-Reply-To: <53NPuNOHhHglIfYV8cII3KS0IlYtAmBQbIC25APMMYw=.b1ff77df-cdc8-48ce-b0a4-888be98baff2@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
 <76CdiCuDBq45d6ke6zQnX_xdS3kQisxveFvPzKI_zLw=.40b46ae1-4560-426d-9ce6-5cd6de6a604c@github.com>
 <53NPuNOHhHglIfYV8cII3KS0IlYtAmBQbIC25APMMYw=.b1ff77df-cdc8-48ce-b0a4-888be98baff2@github.com>
Message-ID: <sBpGu76upZ8ZgzF4CbcBybaK_2LvpgkRgPlpb4-uSBQ=.ae28d8e1-ffed-4cb9-b536-892d8f7f16de@github.com>

On Thu, 17 Jul 2025 18:04:31 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> The arrays at L.2257-2262 could be declared `static` and `@Stable` as well, and moved outside the method.

Right; those were the ones I was referring to when I wrote "Some small refactorings could be used to make a few non-static arrays static." :-)

I wanted to just start with the static final arrays, but I could pull those out too in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/26341#issuecomment-3085477901

From mcimadamore at openjdk.org  Thu Jul 17 21:36:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 17 Jul 2025 21:36:54 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v5]
In-Reply-To: <lirArNH2rA5pWS5OGkhT15w6_dGdbt-Ds0jwrxPoC5k=.18aff583-5acf-49e7-9cbd-1a1e05fc3612@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <lirArNH2rA5pWS5OGkhT15w6_dGdbt-Ds0jwrxPoC5k=.18aff583-5acf-49e7-9cbd-1a1e05fc3612@github.com>
Message-ID: <v1WidYiOXUdfms1c_8zupLHhsJJd4A3cO3PTmRghisk=.9b39922b-6f1e-4ada-9688-689486d7160b@github.com>

On Thu, 17 Jul 2025 18:28:04 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
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify wording

Looks good, thanks!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26258#pullrequestreview-3031098353

From darcy at openjdk.org  Thu Jul 17 21:40:13 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 17 Jul 2025 21:40:13 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
 [v3]
In-Reply-To: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
Message-ID: <ZgjRJGyu9IFgCsZyFF3D1cswr9nJD3vq7hWeX6Qumdk=.a8a46b00-108f-4d0f-9d47-cb4932e07d29@github.com>

> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.

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

  Implement review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26341/files
  - new: https://git.openjdk.org/jdk/pull/26341/files/a7b86ee5..5e1233b7

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

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

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

From darcy at openjdk.org  Thu Jul 17 21:40:13 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 17 Jul 2025 21:40:13 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
 [v2]
In-Reply-To: <9xZTuEGIm8Glb9CnBy1xLl8xfeqtJMR-EBHZVB1N85w=.41fb17e3-931c-4ff3-8481-ba45aa4712ce@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
 <vDpPRsDFcyHIeMXacdTdVMZEdVLCZcfauKSbutewigg=.0fc78693-c868-4ade-b8d6-956f87a25403@github.com>
 <9xZTuEGIm8Glb9CnBy1xLl8xfeqtJMR-EBHZVB1N85w=.41fb17e3-931c-4ff3-8481-ba45aa4712ce@github.com>
Message-ID: <B-77CYdOc038SUoiw748nD3XrPhpsWHsGjC6KHL39rg=.99fede0c-6290-43d7-a049-70f5321e7f57@github.com>

On Thu, 17 Jul 2025 18:16:33 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think local arrays require more structural changes to the code, which might be why this patch did not include that change. However, note as said in #26355, such conversions are meaningful and would potentially allow performance boosts.

Okay; I took a look at what the code was actually doing and wrote something that avoiding using arrays entirely.

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

PR Comment: https://git.openjdk.org/jdk/pull/26341#issuecomment-3085566073

From rgiulietti at openjdk.org  Thu Jul 17 21:49:48 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Jul 2025 21:49:48 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v5]
In-Reply-To: <lirArNH2rA5pWS5OGkhT15w6_dGdbt-Ds0jwrxPoC5k=.18aff583-5acf-49e7-9cbd-1a1e05fc3612@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <lirArNH2rA5pWS5OGkhT15w6_dGdbt-Ds0jwrxPoC5k=.18aff583-5acf-49e7-9cbd-1a1e05fc3612@github.com>
Message-ID: <betYTu4AGmRlQIk1JOD5zespHcy0Ju64TlNnMn6l-wk=.9db64713-e0bf-4430-8c27-73b3489a4eff@github.com>

On Thu, 17 Jul 2025 18:28:04 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
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify wording

Looks good

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

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26258#pullrequestreview-3031130811

From iklam at openjdk.org  Thu Jul 17 22:43:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 17 Jul 2025 22:43:48 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
In-Reply-To: <I6QtmOydf5-vfixmLTwYX2aO6cEM_GUjNaxnAELfFDs=.4ffabffc-a01a-4d7e-8b3a-26deac5120c6@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
 <aTs018gQ4ULkVAXdGUZiX-g7gKJkHEbMjKCob8i9FYA=.208a442c-52dc-4569-9c27-596fd1f94121@github.com>
 <I6QtmOydf5-vfixmLTwYX2aO6cEM_GUjNaxnAELfFDs=.4ffabffc-a01a-4d7e-8b3a-26deac5120c6@github.com>
Message-ID: <dwrToo7aFLg6SgqDSaYQkYvh-TPXWND7wZacVfp2QAY=.8420ecbe-362b-46a6-b583-4e5497b3c287@github.com>

On Thu, 17 Jul 2025 12:35:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/modules.cpp line 777:
>> 
>>> 775:   if (CDSConfig::is_using_full_module_graph()) {
>>> 776:     precond(unnamed_module == ClassLoaderDataShared::archived_boot_unnamed_module());
>>> 777:     unnamed_module->restore_archived_oops(boot_loader_data);
>> 
>> If you're restoring the module oop from the archive, what is the module oop passed into this that the rest of the code is using?
>
> If you're storing the unnamed module oop in the archive should this method not be called?  If it is, what are you saving by archiving the unnamed module?

The callstack is:


jdk.internal.loader.BootLoader.setBootLoaderUnnamedModule0(java.base at 26-internal/Native Method)
jdk.internal.loader.BootLoader.<clinit>(java.base at 26-internal/BootLoader.java:71)
jdk.internal.module.ModuleBootstrap.boot(java.base at 26-internal/ModuleBootstrap.java:162)
java.lang.System.initPhase2(java.base at 26-internal/System.java:1932)


Both the Java code and the native code have a handle to this unnamed module oop. The `precond` checks that they indeed are pointing the same oop.

Also, even though the oop is archived, we still need to set up some native states inside the `unnamed_module->restore_archived_oops(boot_loader_data)` call. E.g., set up the `OopHandle` that binds the oop to the `ModuleEntry`.

---------------
> what are you saving by archiving the unnamed module?

It's for [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550)) -- I want to be able to reference the unnamed module before executing any Java code, so that archived classes can be loaded at the very beginning of `vmClasses::resolve_all()`. See my draft PR: https://github.com/openjdk/jdk/pull/26375

---------------
Currently, we still execute a lot of Java code when setting up the archived module graph (inside `ModuleBootstrap.boot()`. I am working on a way to enable the archived module graph without executing any Java code (which will be a few REFs after [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550)), so this call will eventually be gone.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26082#discussion_r2214437363

From john.r.rose at oracle.com  Thu Jul 17 23:07:53 2025
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 17 Jul 2025 16:07:53 -0700
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
In-Reply-To: <hVTqb5aXoMwBwtQNThsYewFRlxPDra9KKemnebBLFR0=.4a2300de-8c0c-42c6-93aa-733c0d018757@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <JyFXnnkzrbOSXSsVUmDwkKfm-F3UlWHRkWzOsl8CMko=.d8c23079-1ace-4df9-88b7-7628576570a7@github.com>
 <iU-k-9EJmUVSn-O45JHrHYQSE27TEpVH57GLafkgsxU=.0eaaaf5e-f25e-43fa-a37c-2b0b3a797349@github.com>
 <hVTqb5aXoMwBwtQNThsYewFRlxPDra9KKemnebBLFR0=.4a2300de-8c0c-42c6-93aa-733c0d018757@github.com>
Message-ID: <4621FEE1-8A22-48A0-8592-5FEE6F46A3B8@oracle.com>

On 11 Jul 2025, at 6:19, Chen Liang wrote:

> On Fri, 11 Jul 2025 13:05:09 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:
>
>>> 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.
>>
>> Right, "word tearing" and "non-atomic access" are different notions.
>
> True, word tearing is racing a single memory location. Good that we discovered another spec bug and could fix it in time for 25.

The terms are connected, IMO.  The connection can be emphasized
by using the term ?struct tearing? when discussing racing confusion
of partial writes to multi-part items.  ?Word tearing?, by contrast,
involves racing confusion of subparts of a single-part item (a ?word?),
when the confused writes are intended to update one subpart
at a time.

A struct, being a group of independent parts, has piecewise non-atomic
access methods for each part, whether or not it also has an atomic
access method to update the whole struct (as if it were a ?big word?).

A word, being a single unit, has an atomic access method.  Using
one word to represent several smaller (?subword?) parts brings the
risk of word-tearing (not struct-tearing) since two atomic updates,
to two distinct parts, might end up cancelling one of the part-stores,
by overwriting it with a bit pattern asserted by the other part-store.

On modern machines, memory words are 64/32/16/8 bits because each
size has independent atomic access instructions.

And structs can be anything larger than the smallest memory word (8 bits).
So, depending on how access methods are used, a memory word of size
64/32/16 might suffer from either word-tearing or (as a struct of
smaller words) struct-tearing.

Java?s ?struct tearing? (non-atomic access) of 64-bit longs can happen
where a long is treated as a struct of 32-bit words.  ?Word tearing?
would be a risk if we implemented boolean variables in one physical
bit of storage, since 8 of them would be packed into the smallest
possible memory word, an 8-bit byte.

So, while word-tearing and struct-tearing are distinct, they apply
to an overlapping set of memory structures, in similar conditions
(racing writes).  One happens when the physical storage unit is
too large for the logical write, and one happens when the logical
write is too large for a single physical memory unit.

From jrose at openjdk.org  Thu Jul 17 23:18:48 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 17 Jul 2025 23:18:48 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v3]
In-Reply-To: <Vc9wAIM3m7VI_LqEzNWAQNsdt9pMiVR53ztfEBFrBpk=.dddfa782-d044-4090-98b7-c1fdd068481d@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <tCyx-XkttQoAnJcEOtC8SITb9NaurEROV_OjT-E3Imc=.320d74bc-5aa1-4d8a-9867-c767dea379c5@github.com>
 <KPkEWeFIcUBE3Xw611x9c2LDSucL0gO3BBQNS9tcd5w=.6302fefc-3bc0-48c7-aac4-83676ce7cd66@github.com>
 <Vc9wAIM3m7VI_LqEzNWAQNsdt9pMiVR53ztfEBFrBpk=.dddfa782-d044-4090-98b7-c1fdd068481d@github.com>
Message-ID: <g4d3FJdMpKMbXjRRdxEExWWYxe7ASA9Widz9R5MZ9ek=.8f6090ed-bac7-4461-a898-6330035a0799@github.com>

On Thu, 17 Jul 2025 18:00:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 281:
>> 
>>> 279:  * <li>read write access modes for all {@code T}. On 32-bit platforms, access modes
>>> 280:  *     {@code get} and {@code set} for {@code long}, {@code double} and {@code MemorySegment}
>>> 281:  *     are supported but may be non-atomic, as described in Section {@jls 17.7}
>> 
>> Suggestion:
>> 
>>  *     are supported but may be non-atomic in the sense of Section {@jls 17.7}
>> 
>> 
>> A useful taxonomy has atomic _read-modify-write_ operations (atomic updates, numeric atomic updates, bitwise atomic updates, like CASes, etc.), and atomic _access_ operations, that is, atomic loads and stores (atomic reads and writes).
>> 
>> But the reference to the JLS section here should clarify what is meant in this specific context, namely access operation, not read-modify-write operations.
>
> Yep, to distinguish access and the encapsulated read-modify-write atomicity, I decided to avoid using "atomic"/"non-atomic" altogether - now it is just "make no atomicity guarantee"

Not sure this is relevant, but isn't "opaque" access the way to request atomicity "by all means possible"?  So a user who cares can use `VH::getOpaque` if the requirement is atomicity aligned to `CAS`.

I still agree that it is good to specify the meaning of plain `VH::get` and `VH::set` as much as possible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26258#discussion_r2214474938

From jrose at openjdk.org  Thu Jul 17 23:27:49 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 17 Jul 2025 23:27:49 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v5]
In-Reply-To: <lirArNH2rA5pWS5OGkhT15w6_dGdbt-Ds0jwrxPoC5k=.18aff583-5acf-49e7-9cbd-1a1e05fc3612@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <lirArNH2rA5pWS5OGkhT15w6_dGdbt-Ds0jwrxPoC5k=.18aff583-5acf-49e7-9cbd-1a1e05fc3612@github.com>
Message-ID: <AUXl2AWiQFApQt97Rf15e9LafxX6gvfF1yuITwuOqxc=.7332ad9e-435e-4616-9a19-7c9a05108258@github.com>

On Thu, 17 Jul 2025 18:28:04 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
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify wording

Marked as reviewed by jrose (Reviewer).

The previous comment is informational only.  I'm NOT suggesting the PR use the term "struct tearing", since that is not a term in the JVMS.  It's just a useful term that has cropped up in Project Valhalla as the generalization of long/double non-atomicity.  Another Valhalla term for the same thing, FWIW, is "loose consistency".  For technical discourse, either term is better than just "non-atomicity", since "non-atomicity" doesn't suggest there is any limit to the tearing; using bytewise memcpy on a long or a value object would be "non-atomic" but not "loosely consistent", so there is important daylight between the terms.

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

PR Review: https://git.openjdk.org/jdk/pull/26258#pullrequestreview-3031277023
PR Comment: https://git.openjdk.org/jdk/pull/26258#issuecomment-3085811559

From almatvee at openjdk.org  Fri Jul 18 00:07:00 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 18 Jul 2025 00:07:00 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v8]
In-Reply-To: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
Message-ID: <E0uQU5JLZWMRoptG7VkuOB2qEnN1uyhcOt6_ZBDlSO8=.d47fe0af-ee08-4da1-8265-66a5e6a099f2@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 [v7]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26173/files
  - new: https://git.openjdk.org/jdk/pull/26173/files/72e47ddd..3cc08462

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

  Stats: 530 lines in 13 files changed: 168 ins; 248 del; 114 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  Fri Jul 18 00:09:09 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 18 Jul 2025 00:09:09 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v7]
In-Reply-To: <1alrEItE8VTiorSu-uXu3l10Dppe5ZFLND0LG3EBy7A=.d9fcfe97-df70-45ec-93eb-2e3ca0494940@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <1alrEItE8VTiorSu-uXu3l10Dppe5ZFLND0LG3EBy7A=.d9fcfe97-df70-45ec-93eb-2e3ca0494940@github.com>
Message-ID: <Q-7Eo--ZKss5dc9MV1aIJy1kay77SfCdm9yYS1cXq8U=.212df826-ef75-4ed8-a1b7-0f75278abfe7@github.com>

On Wed, 16 Jul 2025 22:26:51 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 [v6]

8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v7]
- Merged with @alexeysemenyukoracle proposed changes to introduce MacBundle to handle macOS bundle specific paths. Proposed changes located at https://github.com/alexeysemenyukoracle/jdk/tree/JDK-8351073-mods.

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

PR Comment: https://git.openjdk.org/jdk/pull/26173#issuecomment-3085967209

From almatvee at openjdk.org  Fri Jul 18 02:47:04 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 18 Jul 2025 02:47:04 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v9]
In-Reply-To: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
Message-ID: <BJ6wcJNbVORQqbvBJc2O8XTuFPHbDpePRfYXiGAINS0=.af2c2e79-b392-469f-b11f-63b7a296effb@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 [v8]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26173/files
  - new: https://git.openjdk.org/jdk/pull/26173/files/3cc08462..336a5d3b

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

  Stats: 64 lines in 5 files changed: 20 ins; 44 del; 0 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  Fri Jul 18 02:47:04 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 18 Jul 2025 02:47:04 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v8]
In-Reply-To: <E0uQU5JLZWMRoptG7VkuOB2qEnN1uyhcOt6_ZBDlSO8=.d47fe0af-ee08-4da1-8265-66a5e6a099f2@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <E0uQU5JLZWMRoptG7VkuOB2qEnN1uyhcOt6_ZBDlSO8=.d47fe0af-ee08-4da1-8265-66a5e6a099f2@github.com>
Message-ID: <HPL9_F4ioEoUcvRhqw4pRTPrTcob-7vV-DAH6M1uhbE=.08908f81-d5cc-476c-badd-d928babe485d@github.com>

On Fri, 18 Jul 2025 00:07:00 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 [v7]

8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v8]
- Renamed RuntimeBundle-Info.plist -> Runtime-Info.plist and Runtime-Info.plist -> ApplicationRuntime-Info.plist.
- Category also renamed.
- Public name of Runtime installer info plist changed to Runtime-Info.plist as per documentation from RuntimeBundle-Info.plist.

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

PR Comment: https://git.openjdk.org/jdk/pull/26173#issuecomment-3086477974

From rgiulietti at openjdk.org  Fri Jul 18 08:18:54 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 18 Jul 2025 08:18:54 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
 [v3]
In-Reply-To: <ZgjRJGyu9IFgCsZyFF3D1cswr9nJD3vq7hWeX6Qumdk=.a8a46b00-108f-4d0f-9d47-cb4932e07d29@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
 <ZgjRJGyu9IFgCsZyFF3D1cswr9nJD3vq7hWeX6Qumdk=.a8a46b00-108f-4d0f-9d47-cb4932e07d29@github.com>
Message-ID: <-C0kP9-Vxly4NbTKJP1ktIzE2W9dQwW_bVy3efPMK6Y=.bba3e072-2559-4963-8076-bf624d387e1f@github.com>

On Thu, 17 Jul 2025 21:40:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review feedback.

Looks fine

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

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26341#pullrequestreview-3032515403

From xgong at openjdk.org  Fri Jul 18 09:01:53 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 18 Jul 2025 09:01:53 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: <QSsZ6TlwsuTKpZ6C9CRGZeO_tm4jyblgVQN1TWDhG-Y=.33e59ea3-47e7-4e80-ac9f-83e891e176ae@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 @jatin-bhateja, would you mind help taking a look at the IR test part especially the IR check on X86? Thanks a lot in advance!

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

PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3088643964

From asemenyuk at openjdk.org  Fri Jul 18 11:57:12 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 18 Jul 2025 11:57:12 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v9]
In-Reply-To: <BJ6wcJNbVORQqbvBJc2O8XTuFPHbDpePRfYXiGAINS0=.af2c2e79-b392-469f-b11f-63b7a296effb@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <BJ6wcJNbVORQqbvBJc2O8XTuFPHbDpePRfYXiGAINS0=.af2c2e79-b392-469f-b11f-63b7a296effb@github.com>
Message-ID: <FE-zoQLQspEMBABezT3tIDcXb2MofsPR1v1mQg_MUzc=.7184b898-b588-4fc9-950a-c2e0514e1bd2@github.com>

On Fri, 18 Jul 2025 02:47:04 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 [v8]

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPackagingPipeline.java line 314:

> 312:         if (app.isRuntime()) {
> 313:             template = "Runtime-Info.plist.template";
> 314:             publicName = "Runtime-Info.plist";

The public name of the info plist file for the runtime bundle and the application bundle should differ.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2215865375

From liach at openjdk.org  Fri Jul 18 13:42:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Jul 2025 13:42:56 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
 [v3]
In-Reply-To: <ZgjRJGyu9IFgCsZyFF3D1cswr9nJD3vq7hWeX6Qumdk=.a8a46b00-108f-4d0f-9d47-cb4932e07d29@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
 <ZgjRJGyu9IFgCsZyFF3D1cswr9nJD3vq7hWeX6Qumdk=.a8a46b00-108f-4d0f-9d47-cb4932e07d29@github.com>
Message-ID: <l2JxavYCqhe0c7Kh0YsmJARsKVbF7rtsQRFjWjp2NZE=.3c22c5f4-473c-4dc4-885a-914d9e636a9c@github.com>

On Thu, 17 Jul 2025 21:40:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review feedback.

This array unrolling looks right to me.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26341#pullrequestreview-3033591853

From rriggs at openjdk.org  Fri Jul 18 14:38:57 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 18 Jul 2025 14:38:57 GMT
Subject: RFR: 8357823: Changes in StringBuilder (JDK-8351443) caused a 1-3%
 regression in biojava [v2]
In-Reply-To: <WzoAuynrcGPSOU45b0ZIVCrfLB8BCWLXGKIb57N2RnY=.bbcd4e75-8e1d-4faa-a657-af9f14934b8c@github.com>
References: <EqrJvAzbQYoe6SnQhsy9_KmtAhqJI4jGMaHOztKb0n8=.99ee9a06-04d4-499b-976c-74da3314f4b5@github.com>
 <WzoAuynrcGPSOU45b0ZIVCrfLB8BCWLXGKIb57N2RnY=.bbcd4e75-8e1d-4faa-a657-af9f14934b8c@github.com>
Message-ID: <yO3Hwm1rmYfWBv4GC70mDtmkjBxFfoljRBBkzuVPea0=.42478b78-c86d-48f7-b989-eacd6d477f86@github.com>

On Wed, 11 Jun 2025 11:35:09 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Comment out assertions added in JDK-8351443 from AbstractStringBuilder.ensureCapacityNewCoder that increase the codesize, preventing some inlining, and reducing performance
>> 
>>        assert coder == newCoder || newCoder == UTF16 : "bad new coder UTF16 -> LATIN1";
>>        assert count <= newCapacity : "count exceeds new capacity";
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Microbenchmark java.lang.StringBuilders is modified to not re-use existing StringBuilders
>   in the appendWithXXX benchmarks.
>   The StringBuilders sbLatin1 and sbUtf15 are created as re-only for specific test cases.
>   Re-using and setting the length to zero, makes the test suseptable to variations
>   depend on the order of execution of the the benchmarks because the buffers may or
>   may not have to been re-sized based on the previous test cases.

The specific patch suggested did not resolve the performance deficit.
Several other refactorings did not yield reliable improvement across all architectures and platforms including several refactorings that move high frequency paths into the public methods or the direct support methods.
Reverting to the original code would undo the integrity goals of JDK-8351443.
Offline discussion suggested that additional work on the optimizations in HotSpot may be needed, but the timeline is not known.

With RPD2 for JDK 25 past, closing until a better improvement can be found.

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

PR Comment: https://git.openjdk.org/jdk/pull/25550#issuecomment-3089698531
PR Comment: https://git.openjdk.org/jdk/pull/25550#issuecomment-3089701809

From rriggs at openjdk.org  Fri Jul 18 14:38:58 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 18 Jul 2025 14:38:58 GMT
Subject: Withdrawn: 8357823: Changes in StringBuilder (JDK-8351443) caused a
 1-3% regression in biojava
In-Reply-To: <EqrJvAzbQYoe6SnQhsy9_KmtAhqJI4jGMaHOztKb0n8=.99ee9a06-04d4-499b-976c-74da3314f4b5@github.com>
References: <EqrJvAzbQYoe6SnQhsy9_KmtAhqJI4jGMaHOztKb0n8=.99ee9a06-04d4-499b-976c-74da3314f4b5@github.com>
Message-ID: <4h01g0QTB7Org66N0IDzsUiNf6N_y9e38lvObn1TrHc=.838bb698-1262-4711-9c9a-03a64416ec98@github.com>

On Fri, 30 May 2025 14:01:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Comment out assertions added in JDK-8351443 from AbstractStringBuilder.ensureCapacityNewCoder that increase the codesize, preventing some inlining, and reducing performance
> 
>        assert coder == newCoder || newCoder == UTF16 : "bad new coder UTF16 -> LATIN1";
>        assert count <= newCapacity : "count exceeds new capacity";

This pull request has been closed without being integrated.

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

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

From jvernee at openjdk.org  Fri Jul 18 14:56:52 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 18 Jul 2025 14:56:52 GMT
Subject: Integrated: 8362169: Pointer passed to upcall may get wrong scope
In-Reply-To: <p9Ykd_mrk9HP9goCgtwnry5CJEzhtSpIblLZUZLIl0w=.73dae209-8b94-4e5b-9001-bf8c3861a2b5@github.com>
References: <p9Ykd_mrk9HP9goCgtwnry5CJEzhtSpIblLZUZLIl0w=.73dae209-8b94-4e5b-9001-bf8c3861a2b5@github.com>
Message-ID: <R8Za_LoPT-4OFg83TG04uc29aZo2jcNB6m8IqnOVqXs=.3bf02466-6a89-4c54-b1f7-613828ab9f6e@github.com>

On Mon, 14 Jul 2025 15:33:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Issue copied from the JBS issue:
> 
> When an upcall stub accepts a by-value struct, and the struct is passed by the underlying ABI as a pointer to a temporary copy on the caller's stack (for instance on Windows when the struct doesn't fit into a single register), a scope is created for the duration of the upcall, to which the memory segment for this struct is attached.
> 
> However, if such a scope is created for the upcall, any other unrelated pointer argument will _also_ be attached to the same scope. This is incorrect, as unrelated pointer arguments should be attached to the global scope. The underlying issue is that, when deciding whether a particular argument needs to be attached to the scope, we check if _any_ of the argument needs to be attached to the created scope.
> 
> This PR fixes the issue by calling `boxAddress.needsScope()` in `BindingSpecializer::emitBoxAddress`, which checks only if that particular argument needs to be attached to the upcall scope.
> 
> I've also renamed the 'global' `needsScope` method, which checks whether _any_ of the arguments need a scope, to `anyArgNeedsScope` for clarity.
> 
> Testing: `jdk_foreign` test suite on Mac/Windows/Linux x64, and Mac/Linux aarch64

This pull request has now been integrated.

Changeset: 9dc62825
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9dc62825b5e7300542d22df0b87b79116f3562d3
Stats:     44 lines in 3 files changed: 39 ins; 0 del; 5 mod

8362169: Pointer passed to upcall may get wrong scope

Reviewed-by: mcimadamore

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

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

From rriggs at openjdk.org  Fri Jul 18 15:18:59 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 18 Jul 2025 15:18:59 GMT
Subject: RFR: 8357380: java/lang/StringBuilder/RacingSBThreads.java times out
 with C1
Message-ID: <mIva-H6XZKGDppUqGZdwUgFhPuasxWrErV0t6RYm9VE=.ae9594a5-cbcd-4945-8e72-85991d93fb11@github.com>

Reduced number of iterations from 10 million to 1 million to reduce cpu time

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

Commit messages:
 - 8357380: java/lang/StringBuilder/RacingSBThreads.java times out with C1

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

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

From jpai at openjdk.org  Fri Jul 18 15:25:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 18 Jul 2025 15:25:48 GMT
Subject: RFR: 8357380: java/lang/StringBuilder/RacingSBThreads.java times
 out with C1
In-Reply-To: <mIva-H6XZKGDppUqGZdwUgFhPuasxWrErV0t6RYm9VE=.ae9594a5-cbcd-4945-8e72-85991d93fb11@github.com>
References: <mIva-H6XZKGDppUqGZdwUgFhPuasxWrErV0t6RYm9VE=.ae9594a5-cbcd-4945-8e72-85991d93fb11@github.com>
Message-ID: <OOD32_ezOPbN8ZM12hqWG6vM0e3RidsYA9vA_q8Q0MM=.a1b9f183-f4b3-4994-b4fa-68c754cda9a0@github.com>

On Fri, 18 Jul 2025 15:06:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Reduced number of iterations from 10 million to 1 million to reduce cpu time

Looks good and trivial to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26389#pullrequestreview-3033958779

From darcy at openjdk.org  Fri Jul 18 16:58:20 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 18 Jul 2025 16:58:20 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
 [v3]
In-Reply-To: <l2JxavYCqhe0c7Kh0YsmJARsKVbF7rtsQRFjWjp2NZE=.3c22c5f4-473c-4dc4-885a-914d9e636a9c@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
 <ZgjRJGyu9IFgCsZyFF3D1cswr9nJD3vq7hWeX6Qumdk=.a8a46b00-108f-4d0f-9d47-cb4932e07d29@github.com>
 <l2JxavYCqhe0c7Kh0YsmJARsKVbF7rtsQRFjWjp2NZE=.3c22c5f4-473c-4dc4-885a-914d9e636a9c@github.com>
Message-ID: <2QPg2jhLs2gjJ36zA9srFUx0LRTtNwzqBIqQ5xud_zg=.c5abe69b-6a57-4c44-9009-50e3a04bf918@github.com>

On Fri, 18 Jul 2025 13:40:15 GMT, Chen Liang <liach at openjdk.org> wrote:

> This array unrolling looks right to me.

I'll write a regression test case to make sure.

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

PR Comment: https://git.openjdk.org/jdk/pull/26341#issuecomment-3090070661

From darcy at openjdk.org  Fri Jul 18 17:03:01 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 18 Jul 2025 17:03:01 GMT
Subject: RFR: 8357728: Optimize Executable#synthesizeAllParams
In-Reply-To: <0qVgwcVSAYKsWc8eNHuDThScC9vz4OCxSdA_Am9ENAo=.f9d422f8-2d4a-4244-9d74-7b605df2cdd5@github.com>
References: <0qVgwcVSAYKsWc8eNHuDThScC9vz4OCxSdA_Am9ENAo=.f9d422f8-2d4a-4244-9d74-7b605df2cdd5@github.com>
Message-ID: <OR5Tz56ezKwOQJ0p8CA6KPbAK0sv-5tiZx3tH3nSmhc=.113ade5b-4889-4f54-a719-bfc6e4b8cb48@github.com>

On Tue, 24 Jun 2025 22:32:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, fake parameters are created with "arg0" etc. strings that are retained for class file methods with no MethodParameters attribute. The original issue report observes many of these strings present in the heap. To address this issue, we can remove these eagerly created fake names, bringing their behavior in line with nameless parameters from MethodParameters attribute, such as those from inner class constructors. A unit test verifies that no name is retained in the Parameter object when the name is fake.
> 
> The original report recommends using a pool to store the arg name strings. I did not take that approach as I don't think it is very necessary; if the issue of retained fake names persist, we can update `Parameter::getName` to return fake names from a pool instead.

@liach , please file a CSR for the behavioral change here.

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

PR Comment: https://git.openjdk.org/jdk/pull/25961#issuecomment-3090040953

From rriggs at openjdk.org  Fri Jul 18 17:11:04 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 18 Jul 2025 17:11:04 GMT
Subject: Integrated: 8357380: java/lang/StringBuilder/RacingSBThreads.java
 times out with C1
In-Reply-To: <mIva-H6XZKGDppUqGZdwUgFhPuasxWrErV0t6RYm9VE=.ae9594a5-cbcd-4945-8e72-85991d93fb11@github.com>
References: <mIva-H6XZKGDppUqGZdwUgFhPuasxWrErV0t6RYm9VE=.ae9594a5-cbcd-4945-8e72-85991d93fb11@github.com>
Message-ID: <qksbLIWiNSLnJq4IqK_pDYXFqkvkBUpYyvxvTK6fVD4=.ccf231d1-d2a0-45d8-b6d8-881a3fae72df@github.com>

On Fri, 18 Jul 2025 15:06:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Reduced number of iterations from 10 million to 1 million to reduce cpu time

This pull request has now been integrated.

Changeset: 30d20036
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/30d20036987c9d68eb76b1e0401821386a76bb07
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8357380: java/lang/StringBuilder/RacingSBThreads.java times out with C1

Reviewed-by: jpai

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

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

From bpb at openjdk.org  Fri Jul 18 17:11:13 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Jul 2025 17:11:13 GMT
Subject: RFR: 8361587: AssertionError in File.listFiles() when path is
 empty and -esa is enabled [v8]
In-Reply-To: <klJ8pNhM7Otr222yfOIM42fjb1UGMNHPan5skF3nxWE=.28bf2472-e4fe-4da9-bf2a-90b664efb31d@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <CZboh0l2JIXaw4kzPpiVVZCKM4Ic_EMbwni0XKaVrTA=.6f5b4655-2456-416d-a4ba-f32d4be6361d@github.com>
 <wPphAluu7QpZpUlLbvLqeLjSB1tpoYkyq1Wt5zcV174=.239e046f-27b2-4ba9-85a1-ba153abb6f4c@github.com>
 <klJ8pNhM7Otr222yfOIM42fjb1UGMNHPan5skF3nxWE=.28bf2472-e4fe-4da9-bf2a-90b664efb31d@github.com>
Message-ID: <aKv8Yguwivr2RMhj0EDOFN2JsIkkUhvGhClmkoxSxWo=.26bdb154-688a-441d-958f-a0b331c783ef@github.com>

On Wed, 16 Jul 2025 13:30:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Hello Brian, I'm late to this discussion. I think there are a couple of more places in this code which need attention.

Thanks for catching this, @jaikiran. As you no doubt already observed, this has been fixed by #26353 in the mainline and backported by #26361 to JDK 25 before the rampdown phase 2 deadline.

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

PR Comment: https://git.openjdk.org/jdk/pull/26224#issuecomment-3090024915

From rriggs at openjdk.org  Fri Jul 18 17:19:47 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 18 Jul 2025 17:19:47 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v12]
In-Reply-To: <eRJU5NDSnIIlE9ssz_zq_CrbyGAvaaWf7W6bzI0uDiU=.f4b4907c-ae6b-431d-81fd-bd97c1f81231@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <eRJU5NDSnIIlE9ssz_zq_CrbyGAvaaWf7W6bzI0uDiU=.f4b4907c-ae6b-431d-81fd-bd97c1f81231@github.com>
Message-ID: <yQoWs6r3QYoNoA9vfCM-DwasBs_pRFAecZulKJpKoCg=.133fb988-9647-4fb6-8102-8f82c209066e@github.com>

On Wed, 16 Jul 2025 15:31:07 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 with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Resync after benchmark.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 28:

> 26: 
> 27: import java.io.IOException;
> 28: import java.io.UncheckedIOException;

Unused, can be removed

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 279:

> 277:         }
> 278: 
> 279:         /// Returns a node in the JRT filesystem namespace, or null if no resource or

Using the standard javadoc tags for @param, @return can give some consistency and readability even for internal methods.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 532:

> 530:     public abstract static class Node {
> 531:         private final String name;
> 532:         private final BasicFileAttributes fileAttrs;

It seems a bit wasteful to cache the same attributes in every Node.
But its no more expensive (size-wise) than a referernce to the ImageReader and the indirection.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 543:

> 541:         // As such, non-directory nodes are always complete.
> 542:         boolean isCompleted() {
> 543:             return true;

Seems like a risky default to have this be a concrete method/default that is not required to be overridden.
A subclass (not that many here) could forget to override and have a default wrong answer. YMMV.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 611:

> 609:          *
> 610:          * <p>If this node is not a directory ({@code isDirectory() == false})
> 611:          * then this method will throw {@link IllegalStateException}.

A mismatch in overriding could give inconsistent results (since the impl does not call `isDirectory()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2216403082
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2216447991
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2216510819
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2216472104
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2216478048

From cushon at google.com  Fri Jul 18 17:26:24 2025
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 18 Jul 2025 10:26:24 -0700
Subject: FFM - Optimizing string reads in MemorySegment
Message-ID: <CAL4QsgvQ-O4JeLEjKjZH_p5+SAO5hCWdWJPFtBRDL-r3d_fULA@mail.gmail.com>

Hi,

I have a question about the performance of string reads in MemorySegment.

There was some discussion about reading strings with known lengths
in JDK-8333843, and the outcome was to update the getString javadoc to
recommend:

byte[] bytes = new byte[length];
MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
return new String(bytes, charset);

As I understand it that's as efficient as what MemorySegment#getString is
doing under the hood, the main difference with getString is that it's first
reading the length of a null-terminated string, but after that it just uses
MemorySegment.copy and calls the String constructor.

Has avoiding the byte[] copy in the String constructor been considered?

In theory it might be possible for the runtime to inline the String
constructor, see that the byte[] doesn't escape, and skip the copy. In
practice, based on some benchmarking my colleague Louis Wasserman was
doing, that doesn't seem to be happening.

Would it make sense to consider using
JavaLangAccess#uncheckedNewStringNoRepl here to avoid having to copy the
byte[]?

Thanks,
Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250718/91063678/attachment-0001.htm>

From liach at openjdk.org  Fri Jul 18 18:18:39 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Jul 2025 18:18:39 GMT
Subject: RFR: 8357728: Optimize Executable#synthesizeAllParams
In-Reply-To: <0qVgwcVSAYKsWc8eNHuDThScC9vz4OCxSdA_Am9ENAo=.f9d422f8-2d4a-4244-9d74-7b605df2cdd5@github.com>
References: <0qVgwcVSAYKsWc8eNHuDThScC9vz4OCxSdA_Am9ENAo=.f9d422f8-2d4a-4244-9d74-7b605df2cdd5@github.com>
Message-ID: <dyiUVCPGj6ZAuyTPQ3tMcuhWubhEjp-yxNxrIaK6P18=.0699a584-c507-4a5a-a83d-5c8f00e03431@github.com>

On Tue, 24 Jun 2025 22:32:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, fake parameters are created with "arg0" etc. strings that are retained for class file methods with no MethodParameters attribute. The original issue report observes many of these strings present in the heap. To address this issue, we can remove these eagerly created fake names, bringing their behavior in line with nameless parameters from MethodParameters attribute, such as those from inner class constructors. A unit test verifies that no name is retained in the Parameter object when the name is fake.
> 
> The original report recommends using a pool to store the arg name strings. I did not take that approach as I don't think it is very necessary; if the issue of retained fake names persist, we can update `Parameter::getName` to return fake names from a pool instead.

Done. I have described the context in detail and moved the CSR to proposed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25961#issuecomment-3090285751

From rgiulietti at openjdk.org  Fri Jul 18 19:35:58 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 18 Jul 2025 19:35:58 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v3]
In-Reply-To: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
Message-ID: <aynCB1-CZYGaT1nphsAMEyuFDbtx_Pb1wueY6MO5dVU=.106bd166-7111-4792-b979-03dedefc1934@github.com>

> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.

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

  Added tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26364/files
  - new: https://git.openjdk.org/jdk/pull/26364/files/0e16f050..d4f49c12

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

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

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

From rgiulietti at openjdk.org  Fri Jul 18 19:58:30 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 18 Jul 2025 19:58:30 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v4]
In-Reply-To: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
Message-ID: <9xBPVwNt2eeaWZI4Ad4y81yIXdYcy4JUhWLYMyAWzec=.acef0109-8fa8-4d2b-863d-fb37702bcbf3@github.com>

> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.

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

  Removed temporary comment from tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26364/files
  - new: https://git.openjdk.org/jdk/pull/26364/files/d4f49c12..8a14ef2e

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

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

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

From rgiulietti at openjdk.org  Fri Jul 18 20:01:00 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 18 Jul 2025 20:01:00 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
 [v3]
In-Reply-To: <ZgjRJGyu9IFgCsZyFF3D1cswr9nJD3vq7hWeX6Qumdk=.a8a46b00-108f-4d0f-9d47-cb4932e07d29@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
 <ZgjRJGyu9IFgCsZyFF3D1cswr9nJD3vq7hWeX6Qumdk=.a8a46b00-108f-4d0f-9d47-cb4932e07d29@github.com>
Message-ID: <2g-seJzlwjrk1_CFTzWTN9V4m2tUJ2UpjYNgluSLBuo=.9d3dc0f8-2c8a-407f-86ef-2b8498324163@github.com>

On Thu, 17 Jul 2025 21:40:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review feedback.

Since the refactoring is rather simple, I'm not sure "yet another test" is really needed. But if you are unsure, then please go ahead.

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

PR Comment: https://git.openjdk.org/jdk/pull/26341#issuecomment-3090575582

From almatvee at openjdk.org  Fri Jul 18 20:04:57 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 18 Jul 2025 20:04:57 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v10]
In-Reply-To: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
Message-ID: <7QIrNAzOUUNiaP7P33Q1ayQlE4gxDeBiKs9ip5CdZaE=.daad2f9d-60b0-4727-b847-676657d1b2f9@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 [v9]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26173/files
  - new: https://git.openjdk.org/jdk/pull/26173/files/336a5d3b..5c2f4091

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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  Fri Jul 18 20:04:57 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 18 Jul 2025 20:04:57 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v9]
In-Reply-To: <BJ6wcJNbVORQqbvBJc2O8XTuFPHbDpePRfYXiGAINS0=.af2c2e79-b392-469f-b11f-63b7a296effb@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <BJ6wcJNbVORQqbvBJc2O8XTuFPHbDpePRfYXiGAINS0=.af2c2e79-b392-469f-b11f-63b7a296effb@github.com>
Message-ID: <Sg2a0d-ru1rrJAdHt0umrLHRXxPA49XBaEHzGYbJA-8=.3359ab20-1c14-4219-91d8-a87e97746d84@github.com>

On Fri, 18 Jul 2025 02:47:04 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 [v8]

8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v9]
- `Info.plist` will be used as public name for the runtime bundle.

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

PR Comment: https://git.openjdk.org/jdk/pull/26173#issuecomment-3090579498

From asemenyuk at openjdk.org  Fri Jul 18 20:26:04 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 18 Jul 2025 20:26:04 GMT
Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG
 bundles [v10]
In-Reply-To: <7QIrNAzOUUNiaP7P33Q1ayQlE4gxDeBiKs9ip5CdZaE=.daad2f9d-60b0-4727-b847-676657d1b2f9@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <7QIrNAzOUUNiaP7P33Q1ayQlE4gxDeBiKs9ip5CdZaE=.daad2f9d-60b0-4727-b847-676657d1b2f9@github.com>
Message-ID: <95hx8OwZAX9hZl_2Nr7YPQj-MBiq7iR-bcQQVTX2QsA=.0ab70cad-63fd-41ed-a2b2-ee1b0bf96ff6@github.com>

On Fri, 18 Jul 2025 20:04:57 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 [v9]

Marked as reviewed by asemenyuk (Reviewer).

Looks good. Thank you for making an effort and getting it right!

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

PR Review: https://git.openjdk.org/jdk/pull/26173#pullrequestreview-3034750311
PR Comment: https://git.openjdk.org/jdk/pull/26173#issuecomment-3090627667

From naoto at openjdk.org  Fri Jul 18 20:42:49 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 18 Jul 2025 20:42:49 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v4]
In-Reply-To: <9xBPVwNt2eeaWZI4Ad4y81yIXdYcy4JUhWLYMyAWzec=.acef0109-8fa8-4d2b-863d-fb37702bcbf3@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
 <9xBPVwNt2eeaWZI4Ad4y81yIXdYcy4JUhWLYMyAWzec=.acef0109-8fa8-4d2b-863d-fb37702bcbf3@github.com>
Message-ID: <2lFCS0yJlMuFkLvbJtgTsQyMs_1fybkK4ZFPFtpTTB8=.d2cdf3d6-6d82-4618-854d-39ec925d9001@github.com>

On Fri, 18 Jul 2025 19:58:30 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed temporary comment from tests.

Looks good to me. Some minor comments for the test follow.

test/jdk/java/text/Format/DecimalFormat/DoubleFormattingTest.java line 28:

> 26:  * @bug 8362448
> 27:  * @summary Verify DecimalFormat::format on doubles.
> 28:  * @run junit/othervm DoubleFormattingTest

`othervm` can be removed

test/jdk/java/text/Format/DecimalFormat/DoubleFormattingTest.java line 45:

> 43:     private static final boolean COMPAT = Boolean.getBoolean("jdk.compat.DecimalFormat");
> 44: 
> 45:     @Test

Using `@ParameterizedTest` would eliminate the duplication of code

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

PR Review: https://git.openjdk.org/jdk/pull/26364#pullrequestreview-3034782721
PR Review Comment: https://git.openjdk.org/jdk/pull/26364#discussion_r2216886702
PR Review Comment: https://git.openjdk.org/jdk/pull/26364#discussion_r2216886783

From almatvee at openjdk.org  Fri Jul 18 20:47:10 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 18 Jul 2025 20:47:10 GMT
Subject: Integrated: 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: <4hEHzhtqGX5S7g5ahHpUXXLYmyF8h1HhneWdORGUBHU=.370ad914-5be9-498e-bc2a-cad3b5976f25@github.com>

On Mon, 7 Jul 2025 22:19:12 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.

This pull request has now been integrated.

Changeset: 03230f85
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/03230f8565a4eea41ce13827165b6bbff5eaec68
Stats:     481 lines in 18 files changed: 414 ins; 25 del; 42 mod

8351073: [macos] jpackage produces invalid Java runtime DMG bundles

Reviewed-by: asemenyuk

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

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

From rgiulietti at openjdk.org  Fri Jul 18 20:52:42 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 18 Jul 2025 20:52:42 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v3]
In-Reply-To: <g4d3FJdMpKMbXjRRdxEExWWYxe7ASA9Widz9R5MZ9ek=.8f6090ed-bac7-4461-a898-6330035a0799@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <tCyx-XkttQoAnJcEOtC8SITb9NaurEROV_OjT-E3Imc=.320d74bc-5aa1-4d8a-9867-c767dea379c5@github.com>
 <KPkEWeFIcUBE3Xw611x9c2LDSucL0gO3BBQNS9tcd5w=.6302fefc-3bc0-48c7-aac4-83676ce7cd66@github.com>
 <Vc9wAIM3m7VI_LqEzNWAQNsdt9pMiVR53ztfEBFrBpk=.dddfa782-d044-4090-98b7-c1fdd068481d@github.com>
 <g4d3FJdMpKMbXjRRdxEExWWYxe7ASA9Widz9R5MZ9ek=.8f6090ed-bac7-4461-a898-6330035a0799@github.com>
Message-ID: <uHkmFlloUaqkL1i8JQtuP6qIfRDVeEjnFe3S7Oy_OMY=.3ee94822-4ba4-4a55-adde-5eeea8aef11f@github.com>

On Thu, 17 Jul 2025 23:15:44 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Yep, to distinguish access and the encapsulated read-modify-write atomicity, I decided to avoid using "atomic"/"non-atomic" altogether - now it is just "make no atomicity guarantee"
>
> Not sure this is relevant, but isn't "opaque" access the way to request atomicity "by all means possible"?  So a user who cares can use `VH::getOpaque` if the requirement is atomicity aligned to `CAS`.
> 
> I still agree that it is good to specify the meaning of plain `VH::get` and `VH::set` as much as possible.

Opaque mode indeed ensures atomic access to primitive and reference variables.
In addition, it ensures coherence on that variable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26258#discussion_r2216902696

From rgiulietti at openjdk.org  Fri Jul 18 21:12:41 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 18 Jul 2025 21:12:41 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v5]
In-Reply-To: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
Message-ID: <r58MnxoHF_qtVlYVTY75oJb0y67ZBgGKTRQj2IZKr4Y=.d7a0b896-7bac-4c78-a120-1c1ef40985a2@github.com>

> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.

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

  Refactoring to paramaterized tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26364/files
  - new: https://git.openjdk.org/jdk/pull/26364/files/8a14ef2e..9cafedd1

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

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

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

From naoto at openjdk.org  Fri Jul 18 21:31:44 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 18 Jul 2025 21:31:44 GMT
Subject: RFR: 8362448: Make use of the Double.toString(double) algorithm in
 java.text.DecimalFormat [v5]
In-Reply-To: <r58MnxoHF_qtVlYVTY75oJb0y67ZBgGKTRQj2IZKr4Y=.d7a0b896-7bac-4c78-a120-1c1ef40985a2@github.com>
References: <bTBU6P9VVLASAsFBv-umje6X9u4Vwc3aknN_ft5GwNw=.4d881722-4acd-41ca-ad1f-1f62d7e86693@github.com>
 <r58MnxoHF_qtVlYVTY75oJb0y67ZBgGKTRQj2IZKr4Y=.d7a0b896-7bac-4c78-a120-1c1ef40985a2@github.com>
Message-ID: <8G6nlcFszmDeiGfZ3wyLr4uN1l6bcpKbdKBPawQG8kM=.79383c87-a262-4ef5-8e01-6f65b92bd77c@github.com>

On Fri, 18 Jul 2025 21:12:41 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring to paramaterized tests.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26364#pullrequestreview-3034862374

From iklam at openjdk.org  Fri Jul 18 21:34:45 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Jul 2025 21:34:45 GMT
Subject: RFR: 8345836: Stable annotation documentation is incomplete
In-Reply-To: <KBZuUyH9Y5SgkRpPhJl1hNaH0vwbnHzDe_xPKn-Ym0k=.c95834fe-80b5-4b33-a008-8ef2fee35f59@github.com>
References: <5MPznGbnl6jsZ-og3SMtakdoHRjfRf8xZTKUUCCFqvk=.6e785ddf-cb06-48a1-ad40-70faaa7e8ee4@github.com>
 <KBZuUyH9Y5SgkRpPhJl1hNaH0vwbnHzDe_xPKn-Ym0k=.c95834fe-80b5-4b33-a008-8ef2fee35f59@github.com>
Message-ID: <Q0ferx_aCIVTn5Lvc4-1_v6sgy2ngJXdd89HdnnjL2o=.67b53c4f-5484-4572-af95-b9865a32f20a@github.com>

On Thu, 17 Jul 2025 17:07:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this documentation update, authored by @rose00 and originally pushed to the Leyden repo in [this PR](https://github.com/openjdk/leyden/pull/26), where more comments can be found regarding this update.
>
> Marked as reviewed by liach (Reviewer).

Thanks @liach for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/26355#issuecomment-3090765234

From iklam at openjdk.org  Fri Jul 18 21:34:46 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Jul 2025 21:34:46 GMT
Subject: Integrated: 8345836: Stable annotation documentation is incomplete
In-Reply-To: <5MPznGbnl6jsZ-og3SMtakdoHRjfRf8xZTKUUCCFqvk=.6e785ddf-cb06-48a1-ad40-70faaa7e8ee4@github.com>
References: <5MPznGbnl6jsZ-og3SMtakdoHRjfRf8xZTKUUCCFqvk=.6e785ddf-cb06-48a1-ad40-70faaa7e8ee4@github.com>
Message-ID: <q2q-Mr0dcIk0VR6Z7uNGdlyLESMp0rzO8T1lVzEp0BQ=.7abf2d02-459b-403f-a36e-e3c45363bbc4@github.com>

On Wed, 16 Jul 2025 17:45:23 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this documentation update, authored by @rose00 and originally pushed to the Leyden repo in [this PR](https://github.com/openjdk/leyden/pull/26), where more comments can be found regarding this update.

This pull request has now been integrated.

Changeset: d83346dc
Author:    John R Rose <jrose at openjdk.org>
Committer: Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d83346dcff0824575d580ec421476c0ea5c6e783
Stats:     326 lines in 1 file changed: 280 ins; 12 del; 34 mod

8345836: Stable annotation documentation is incomplete

Reviewed-by: liach

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

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

From jrose at openjdk.org  Fri Jul 18 23:20:40 2025
From: jrose at openjdk.org (John R Rose)
Date: Fri, 18 Jul 2025 23:20:40 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v8]
In-Reply-To: <PmH2X0PiqCK7Zz7HQ5d9948bfKM950ziS9VN2Epf6Dk=.fab73b5d-5511-47ef-9f93-4b9496820a1d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
 <yu8kjKN35lgZh1rQGK-KCpNHObLQlkPLrzWVpQ9Gnc8=.e9684b18-ec3e-4164-a22e-1b5fdde7344f@github.com>
 <PmH2X0PiqCK7Zz7HQ5d9948bfKM950ziS9VN2Epf6Dk=.fab73b5d-5511-47ef-9f93-4b9496820a1d@github.com>
Message-ID: <y6gChA5bfJ_60QKdjCI6Jn_4KQloanQuOhmoz8JLGZE=.afa18245-5eb0-4353-9c57-cff9ec749da6@github.com>

On Thu, 17 Jul 2025 15:33:37 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> What is the thinking when an `@IntrinsicCandidate` method invokes another `@IntrinsicCandidate` method? Which part is responsible for the checks?

This is a good question.  Suppose IC1 calls IC2 and both are intrinsic candidates, and suppose that M1 and M2 are their checked "front doors".

I think the answer has to be that, once you start executing IC1, you cannot expect any further checks.  Probably some assembler macro implements IC2 and it may be called from more than one place.  The tricky thing to prove is that all uses of IC2's intrinsic code, whether direct (via M2) or indirect (via things like M1) have adequate checks.

If intrinsics are factored this way (as they are for string methods) I think that IC1 has to advertise that it calls IC2, so that the front door method M1 is responsible for validity checks for both IC1 and IC2.  That is because after intrinsic expansion, IC2 is reached without going through M2; the entry was indirectly from M1.  So M1 has to duplicate M2's front door checks.

To make this workable, it may be that M2's front door checks are factored into a subroutine FD2, so that M1 can refer to FD2, rather than do risky code duplication.

If (as in this case) IC2 loops over calls to IC1, then perhaps M2 should have a companion method FD2R which checks a range a range of inputs to IC2, so that M1 can call FD2R.  If all goes well, then FD2R has a range check that duplicates the front door logic of M1, so that the JIT can remove the duplicate checking.

In the case of `StringUTF16.getChar`, I see it is marked as trusted, and it does not have a front-door method, and does have many callers.  In the terms of this PR, perhaps it should be renamed `getChar0` (or the like) to make it more clear (at non-local use points) that it must be called from trusted code.  Perhaps it should also have a range check method associated with it, so that some callers can use that range check method, so that the non-local responsibility is more clearly fulfilled.

Maybe some callers (if less performance critical) should be changed to call a properly checked front-door method, `getChar` (as opposed to `getChar0`).  Remaining callers of `getChar0` should be clearly linked to the front-door checks required by `getChar0`.

The above seems to be the principled way to deal with an unchecked intrinsic called from many trusted use sites.  The basic idea is that every trusted use site should reaffirm its responsibility locally, not just hope that a non-local assert will catch a bug.  We want some kind of reviewable (static/local) proof that each use site (of an unchecked private intrinsics) has correct checks.

Some examples:  A new front-door `getChar` method can be used in less important places like `AbstractStringBuilder::getChar`.

In trusted loops over `getChar` like `String::encodeASCII`, the loop containing `getChar` can be prefaced by a range check which is batched for all the loop iterations, something like `StringUTF16.getCharChecks(val, 0, len)`.  The same pattern occurs in `String::encode8859_1` and `encodeUTF8_UTF16` and `computeSizeUTF8_UTF16` and maybe elsewhere.  The `val` reference and limit variable `len` or `sl` should be marked `final` to ensure that the batched range check remains correct (because it should not take loop-variant inputs).

As I read through `String.java` I see that a batched range check would cover a lot of use cases?  I haven't read though all the uses of `getChar`, however.

The intrinsic `encodeISOArray0` (was `implEncodeISOArray`) calls `getChar`.  This is an example where its front door method (now `encodeISOArray` with no "0") should call a batched check method like `getCharBatchChecks`.  Let's look at this in detail.  The `getCharBatchChecks` method could look like this:


//non-public
void getCharBatchChecks(byte[] val, int charStart, int charSize) {
  Objects.requireNonNull(val, "val");  // *** what style guide mandates this line??
  Preconditions.checkFromIndexSize(charStart << 1, charSize << 1, val.length, Preconditions.AIOOBE_FORMATTER);
  // *** using "char" in the names helps reduce confusion from the mix of byte and char indexes
}
?
static int encodeISOArray(?) {
    ?
    StringUTF16.getCharBatchChecks(sa, sp, len);  // next method loops over getChar(sa, sp++)
    return encodeISOArray0(sa, sp, da, dp, len);
}


Note that after inlining, the batch checks exactly match pre-existing checks for the caller intrinsic.  Perhaps the caller's checks could be removed manually, or perhaps the JIT removes the duplication.

Actually, I think you got this documentation wrong:


@param sp the index of the <em>byte (not character!)</em> from the source array to start reading from


AFAICT, `sp` is a char index; note that `getChar` scales it as `(index=sp)<<1`.

Note that `getChar` has zero javadoc, so you are left to guess helplessly about its index operand.

This stuff is complicated to get right.  The above exercise in wiring up the checking logic tends to uncover bugs and misconceptions, I think.

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

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3091231708

From duke at openjdk.org  Sat Jul 19 01:33:49 2025
From: duke at openjdk.org (duke)
Date: Sat, 19 Jul 2025 01:33:49 GMT
Subject: Withdrawn: 8355223: Improve documentation on @IntrinsicCandidate
In-Reply-To: <dm6o-XRNWecHjZeenCSRhAOEYI7L_mOOqfguvjlk_Bc=.cdb4e2e5-3500-48d5-8c05-749ff01f06f1@github.com>
References: <dm6o-XRNWecHjZeenCSRhAOEYI7L_mOOqfguvjlk_Bc=.cdb4e2e5-3500-48d5-8c05-749ff01f06f1@github.com>
Message-ID: <NzjupGoXbqzXZsFbsvFPbgBVrgkMkVdjpNcPwECE_0Y=.116dc0e0-874e-410f-a3de-9d3df6a92536@github.com>

On Mon, 21 Apr 2025 19:29:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".

This pull request has been closed without being integrated.

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

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

From liach at openjdk.org  Sat Jul 19 01:36:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 19 Jul 2025 01:36:51 GMT
Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v7]
In-Reply-To: <vfDsc33Hcmqn4buhdw7ZV-jVSMPUkrkNOcCTdkEulCU=.74cb83d5-f2d4-4bc3-96f6-e245ee7f3842@github.com>
References: <dm6o-XRNWecHjZeenCSRhAOEYI7L_mOOqfguvjlk_Bc=.cdb4e2e5-3500-48d5-8c05-749ff01f06f1@github.com>
 <vfDsc33Hcmqn4buhdw7ZV-jVSMPUkrkNOcCTdkEulCU=.74cb83d5-f2d4-4bc3-96f6-e245ee7f3842@github.com>
Message-ID: <5_qPhVu2mYEDcDhm-xAgdB75_852NRgbkZBvYx2l50w=.930af007-8d62-4c9e-9f48-cbeaebc98cf3@github.com>

On Wed, 21 May 2025 21:31:16 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list".
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - More review updates
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
>  - Move intrinsic to be a subsection; just one most common function of the annotation
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate
>  - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>  - Shorter first sentence
>  - Updates, thanks to John
>  - Refine validation and defensive copying
>  - 8355223: Improve documentation on @IntrinsicCandidate

I think I will move this to a separate design document as Roger suggested.

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

PR Comment: https://git.openjdk.org/jdk/pull/24777#issuecomment-3091360211

From jrose at openjdk.org  Sat Jul 19 06:25:46 2025
From: jrose at openjdk.org (John R Rose)
Date: Sat, 19 Jul 2025 06:25:46 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v8]
In-Reply-To: <y6gChA5bfJ_60QKdjCI6Jn_4KQloanQuOhmoz8JLGZE=.afa18245-5eb0-4353-9c57-cff9ec749da6@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
 <yu8kjKN35lgZh1rQGK-KCpNHObLQlkPLrzWVpQ9Gnc8=.e9684b18-ec3e-4164-a22e-1b5fdde7344f@github.com>
 <PmH2X0PiqCK7Zz7HQ5d9948bfKM950ziS9VN2Epf6Dk=.fab73b5d-5511-47ef-9f93-4b9496820a1d@github.com>
 <y6gChA5bfJ_60QKdjCI6Jn_4KQloanQuOhmoz8JLGZE=.afa18245-5eb0-4353-9c57-cff9ec749da6@github.com>
Message-ID: <-Slk7vUMDszUJMCmtPgaiWeUdmBszJpUOmkkxTGTe38=.f460e240-44d5-4e44-b0c3-ad073315c8c8@github.com>

On Fri, 18 Jul 2025 23:18:16 GMT, John R Rose <jrose at openjdk.org> wrote:

> If (as in this case) IC2 loops over calls to IC1
Correction; I meant IC1 calls IC2, in a loop, N times.  We don't want a pre-loop in M1 that checks each of N distinct arguments to IC2 (like N calls to M2 would), but rather a batch check routine which checks all of the arguments to IC2, in O(1) time.

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

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3091934621

From duke at openjdk.org  Sat Jul 19 07:15:54 2025
From: duke at openjdk.org (duke)
Date: Sat, 19 Jul 2025 07:15:54 GMT
Subject: Withdrawn: 8354799: ZipInputStream doesn't verify CRC for ZIP entry
 with empty file data
In-Reply-To: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
References: <OaL-9YF7LzjvnlBLrdRWpza5vv6d9lMllxmVRBQR0lI=.84fdfdf1-88e4-459c-aa9c-67bf596ec96e@github.com>
Message-ID: <aZCKp2NFrdIpS_l9XphYsgWqQl9OozWgly0J7vRJn7M=.5623b865-ea11-46b5-9540-82b3632494de@github.com>

On Thu, 8 May 2025 12:08:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8354799?
> 
> `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size was missing a CRC check for that entry. The change in this PR addresses that and introduces a new jtreg test which reproduces the issue and verifies the fix.
> 
> tier testing is currently in progress.

This pull request has been closed without being integrated.

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

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

From jpai at openjdk.org  Sat Jul 19 09:06:45 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 19 Jul 2025 09:06:45 GMT
Subject: RFR: 8361587: AssertionError in File.listFiles() when path is
 empty and -esa is enabled [v8]
In-Reply-To: <CZboh0l2JIXaw4kzPpiVVZCKM4Ic_EMbwni0XKaVrTA=.6f5b4655-2456-416d-a4ba-f32d4be6361d@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <CZboh0l2JIXaw4kzPpiVVZCKM4Ic_EMbwni0XKaVrTA=.6f5b4655-2456-416d-a4ba-f32d4be6361d@github.com>
Message-ID: <e2g_S-TUGX3x02JJ2RO9w8gxLGCD99RsQwmbQbSwgiQ=.ef2a1f14-5f9f-41f1-8485-1ce79863a670@github.com>

On Tue, 15 Jul 2025 17:36:22 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: Fix mkdirs sub-test

Thank you Brian for addressing these issues very quickly.

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

PR Comment: https://git.openjdk.org/jdk/pull/26224#issuecomment-3092194348

From brett.okken.os at gmail.com  Sat Jul 19 19:33:58 2025
From: brett.okken.os at gmail.com (Brett Okken)
Date: Sat, 19 Jul 2025 14:33:58 -0500
Subject: String.charAt vs StringBuilder.charAt performance
Message-ID: <CANBJVOHxaDv5q3GJPX8dn2GepcU9de39phavquaxKNXGZrMRrA@mail.gmail.com>

I was looking at the performance of StringCharBuffer for various
backing CharSequence types and was surprised to see a significant
performance difference between String and StringBuffer. I wrote a
small jmh which shows that the String implementation of charAt is
significantly slower than StringBuilder. Is this expected?

Benchmark                            (data)      (source)  Mode  Cnt
  Score       Error  Units
CharSequenceCharAtBenchmark.test      ascii        String  avgt    3
2537.311 ??  8952.197  ns/op
CharSequenceCharAtBenchmark.test      ascii  StringBuffer  avgt    3
852.004 ??  2532.958  ns/op
CharSequenceCharAtBenchmark.test  non-ascii        String  avgt    3
5115.381 ?? 13822.592  ns/op
CharSequenceCharAtBenchmark.test  non-ascii  StringBuffer  avgt    3
836.230 ??  1154.191  ns/op



@Measurement(iterations = 3, time = 5, timeUnit = TimeUnit.SECONDS)
@Warmup(iterations = 2, time = 7, timeUnit = TimeUnit.SECONDS)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
@Fork(value = 1, jvmArgsPrepend = {"-Xms512M", "-Xmx512M"})
public class CharSequenceCharAtBenchmark {

    @Param(value = {"ascii", "non-ascii"})
    public String data;

    @Param(value = {"String", "StringBuffer"})
    public String source;

    private CharSequence sequence;

    @Setup(Level.Trial)
    public void setup() throws Exception {
        StringBuilder sb = new StringBuilder(3152);
        for (int i=0; i<3152; ++i) {
            char c = (char) i;
            if ("ascii".equals(data)) {
                c = (char) (i & 0x7f);
            }
            sb.append(c);
        }

        switch(source) {
            case "String":
                sequence = sb.toString();
                break;
            case "StringBuffer":
                sequence = sb;
                break;
            default:
                throw new IllegalArgumentException(source);
        }
    }

    @Benchmark
    public int test() {
        int sum = 0;
        for (int i=0, j=sequence.length(); i<j; ++i) {
            sum += sequence.charAt(i);
        }
        return sum;
    }
}

From liangchenblue at gmail.com  Sat Jul 19 21:17:24 2025
From: liangchenblue at gmail.com (Chen Liang)
Date: Sat, 19 Jul 2025 16:17:24 -0500
Subject: String.charAt vs StringBuilder.charAt performance
In-Reply-To: <CANBJVOHxaDv5q3GJPX8dn2GepcU9de39phavquaxKNXGZrMRrA@mail.gmail.com>
References: <CANBJVOHxaDv5q3GJPX8dn2GepcU9de39phavquaxKNXGZrMRrA@mail.gmail.com>
Message-ID: <CABe8uE0UJ_=Vb842cTTnE4tuGPWDMKDb0bkD9CCvqNKQfXF20Q@mail.gmail.com>

Without looking at C2 IRs, I think there are a few potential culprits we
can look into:
1. JDK-8351000 and JDK-8351443 updated StringBuilder
2. Sequence field is read in the loop; I wonder if making it an explicit
immutable local variable changes anything here.

On Sat, Jul 19, 2025 at 2:34?PM Brett Okken <brett.okken.os at gmail.com>
wrote:

> I was looking at the performance of StringCharBuffer for various
> backing CharSequence types and was surprised to see a significant
> performance difference between String and StringBuffer. I wrote a
> small jmh which shows that the String implementation of charAt is
> significantly slower than StringBuilder. Is this expected?
>
> Benchmark                            (data)      (source)  Mode  Cnt
>   Score       Error  Units
> CharSequenceCharAtBenchmark.test      ascii        String  avgt    3
> 2537.311 ??  8952.197  ns/op
> CharSequenceCharAtBenchmark.test      ascii  StringBuffer  avgt    3
> 852.004 ??  2532.958  ns/op
> CharSequenceCharAtBenchmark.test  non-ascii        String  avgt    3
> 5115.381 ?? 13822.592  ns/op
> CharSequenceCharAtBenchmark.test  non-ascii  StringBuffer  avgt    3
> 836.230 ??  1154.191  ns/op
>
>
>
> @Measurement(iterations = 3, time = 5, timeUnit = TimeUnit.SECONDS)
> @Warmup(iterations = 2, time = 7, timeUnit = TimeUnit.SECONDS)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @State(Scope.Benchmark)
> @Fork(value = 1, jvmArgsPrepend = {"-Xms512M", "-Xmx512M"})
> public class CharSequenceCharAtBenchmark {
>
>     @Param(value = {"ascii", "non-ascii"})
>     public String data;
>
>     @Param(value = {"String", "StringBuffer"})
>     public String source;
>
>     private CharSequence sequence;
>
>     @Setup(Level.Trial)
>     public void setup() throws Exception {
>         StringBuilder sb = new StringBuilder(3152);
>         for (int i=0; i<3152; ++i) {
>             char c = (char) i;
>             if ("ascii".equals(data)) {
>                 c = (char) (i & 0x7f);
>             }
>             sb.append(c);
>         }
>
>         switch(source) {
>             case "String":
>                 sequence = sb.toString();
>                 break;
>             case "StringBuffer":
>                 sequence = sb;
>                 break;
>             default:
>                 throw new IllegalArgumentException(source);
>         }
>     }
>
>     @Benchmark
>     public int test() {
>         int sum = 0;
>         for (int i=0, j=sequence.length(); i<j; ++i) {
>             sum += sequence.charAt(i);
>         }
>         return sum;
>     }
> }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250719/e0eb342f/attachment-0001.htm>

From brett.okken.os at gmail.com  Sat Jul 19 22:09:25 2025
From: brett.okken.os at gmail.com (Brett Okken)
Date: Sat, 19 Jul 2025 17:09:25 -0500
Subject: String.charAt vs StringBuilder.charAt performance
In-Reply-To: <CABe8uE0UJ_=Vb842cTTnE4tuGPWDMKDb0bkD9CCvqNKQfXF20Q@mail.gmail.com>
References: <CANBJVOHxaDv5q3GJPX8dn2GepcU9de39phavquaxKNXGZrMRrA@mail.gmail.com>
 <CABe8uE0UJ_=Vb842cTTnE4tuGPWDMKDb0bkD9CCvqNKQfXF20Q@mail.gmail.com>
Message-ID: <CANBJVOFUEEt1GdM59D27cXbEzG9ZZZaafPsJqt6uQ+gwjruVKw@mail.gmail.com>

Making sequence a local variable does improve things (especially for
ascii), but a substantial difference remains. It appears that the
performance difference for ascii goes all the way back to jdk 11. The
difference for non-ascii showed up in jdk 21. I wonder if this is related
to the index checks?

jdk 11

Benchmark  (data)      (source)  Mode  Cnt     Score      Error  Units
test        ascii        String  avgt    3  1137.348 ?   12.835  ns/op
test        ascii  StringBuffer  avgt    3   712.874 ?  509.320  ns/op
test    non-ascii        String  avgt    3   668.657 ?  246.550  ns/op
test    non-ascii  StringBuffer  avgt    3   897.344 ? 4353.414  ns/op


jdk 17
Benchmark  (data)      (source)  Mode  Cnt     Score      Error  Units
test        ascii        String  avgt    3  1321.497 ? 2107.466  ns/op
test        ascii  StringBuffer  avgt    3   715.936 ?  412.189  ns/op
test    non-ascii        String  avgt    3   722.986 ?  443.389  ns/op
test    non-ascii  StringBuffer  avgt    3   722.787 ?  771.816  ns/op


jdk 21
Benchmark  (data)      (source)  Mode  Cnt     Score       Error  Units
test        ascii        String  avgt    3  1150.301 ??   918.549  ns/op
test        ascii  StringBuffer  avgt    3   713.183 ??   543.850  ns/op
test    non-ascii        String  avgt    3  4642.667 ?? 11481.029  ns/op
test    non-ascii  StringBuffer  avgt    3   728.027 ??   936.521  ns/op


jdk 25
Benchmark  (data)      (source)  Mode  Cnt     Score      Error  Units
test        ascii        String  avgt    3  1184.513 ?? 2057.498  ns/op
test        ascii  StringBuffer  avgt    3   786.611 ??  411.657  ns/op
test    non-ascii        String  avgt    3  4197.585 ?? 2761.388  ns/op
test    non-ascii  StringBuffer  avgt    3   716.375 ??  815.349  ns/op


jdk 26
Benchmark  (data)      (source)  Mode  Cnt     Score     Error  Units
test        ascii        String  avgt    3  1107.207 ?? 423.072  ns/op
test        ascii  StringBuffer  avgt    3   742.780 ?? 178.890  ns/op
test    non-ascii        String  avgt    3  4043.914 ?? 498.439  ns/op
test    non-ascii  StringBuffer  avgt    3   712.535 ?? 583.255  ns/op


On Sat, Jul 19, 2025 at 4:17?PM Chen Liang <liangchenblue at gmail.com> wrote:

> Without looking at C2 IRs, I think there are a few potential culprits we
> can look into:
> 1. JDK-8351000 and JDK-8351443 updated StringBuilder
> 2. Sequence field is read in the loop; I wonder if making it an explicit
> immutable local variable changes anything here.
>
> On Sat, Jul 19, 2025 at 2:34?PM Brett Okken <brett.okken.os at gmail.com>
> wrote:
>
>> I was looking at the performance of StringCharBuffer for various
>> backing CharSequence types and was surprised to see a significant
>> performance difference between String and StringBuffer. I wrote a
>> small jmh which shows that the String implementation of charAt is
>> significantly slower than StringBuilder. Is this expected?
>>
>> Benchmark                            (data)      (source)  Mode  Cnt
>>   Score       Error  Units
>> CharSequenceCharAtBenchmark.test      ascii        String  avgt    3
>> 2537.311 ??  8952.197  ns/op
>> CharSequenceCharAtBenchmark.test      ascii  StringBuffer  avgt    3
>> 852.004 ??  2532.958  ns/op
>> CharSequenceCharAtBenchmark.test  non-ascii        String  avgt    3
>> 5115.381 ?? 13822.592  ns/op
>> CharSequenceCharAtBenchmark.test  non-ascii  StringBuffer  avgt    3
>> 836.230 ??  1154.191  ns/op
>>
>>
>>
>> @Measurement(iterations = 3, time = 5, timeUnit = TimeUnit.SECONDS)
>> @Warmup(iterations = 2, time = 7, timeUnit = TimeUnit.SECONDS)
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @State(Scope.Benchmark)
>> @Fork(value = 1, jvmArgsPrepend = {"-Xms512M", "-Xmx512M"})
>> public class CharSequenceCharAtBenchmark {
>>
>>     @Param(value = {"ascii", "non-ascii"})
>>     public String data;
>>
>>     @Param(value = {"String", "StringBuffer"})
>>     public String source;
>>
>>     private CharSequence sequence;
>>
>>     @Setup(Level.Trial)
>>     public void setup() throws Exception {
>>         StringBuilder sb = new StringBuilder(3152);
>>         for (int i=0; i<3152; ++i) {
>>             char c = (char) i;
>>             if ("ascii".equals(data)) {
>>                 c = (char) (i & 0x7f);
>>             }
>>             sb.append(c);
>>         }
>>
>>         switch(source) {
>>             case "String":
>>                 sequence = sb.toString();
>>                 break;
>>             case "StringBuffer":
>>                 sequence = sb;
>>                 break;
>>             default:
>>                 throw new IllegalArgumentException(source);
>>         }
>>     }
>>
>>     @Benchmark
>>     public int test() {
>>         int sum = 0;
>>         for (int i=0, j=sequence.length(); i<j; ++i) {
>>             sum += sequence.charAt(i);
>>         }
>>         return sum;
>>     }
>> }
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250719/4b445f95/attachment.htm>

From liach at openjdk.org  Sun Jul 20 03:00:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 20 Jul 2025 03:00:53 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal [v3]
In-Reply-To: <q1GKDvad3GF4chYQRDF28JvCV9nJ6QmllaoaP3WJBGs=.960db4f5-8c1b-44e1-aa19-b5424120f493@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
 <98Ars6Qebvn48y6VXmJUmWnL2TlFUPlvhrjkKVB2MvM=.8b3d7ad7-7f9e-4e82-8189-3767ed5e1188@github.com>
 <q1GKDvad3GF4chYQRDF28JvCV9nJ6QmllaoaP3WJBGs=.960db4f5-8c1b-44e1-aa19-b5424120f493@github.com>
Message-ID: <LUbgbR-dANW03LaNZzIivq5W2mAF8wPrgYC5dYWfOpg=.c9e29915-c64c-4162-ba3a-2c75b2e3b895@github.com>

On Wed, 4 Jun 2025 12:08:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   BigInteger::mag remove Stable
>
> The newly marked arrays are indeed only updated once. Can we see any benchmark showing a performance gain?

Re performance gain argument from @minborg: See #26341 for context; sometimes the constant values aren't immediately used by C2, but at least this will cause no regression and unlocks future gains.

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

PR Comment: https://git.openjdk.org/jdk/pull/25437#issuecomment-3092715850

From liach at openjdk.org  Sun Jul 20 03:00:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 20 Jul 2025 03:00:53 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal [v4]
In-Reply-To: <nOyjL13Gw7c91vi9NtdXLyLpyI9VpoFTRaWzHcM9Quk=.c9ed3ca3-fe1a-4e69-a058-dcc13e5a0f4f@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
 <nOyjL13Gw7c91vi9NtdXLyLpyI9VpoFTRaWzHcM9Quk=.c9ed3ca3-fe1a-4e69-a058-dcc13e5a0f4f@github.com>
Message-ID: <3pYLEBAlr1qFcYj1b3EYgo2C6Z2DRWX1LqBczv51eCo=.aeb29f15-be11-411b-bed4-ff68682ab485@github.com>

On Wed, 4 Jun 2025 13:12:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Some static final arrays of BigInteger and BigDecimal are stable and immutable. We should add `@Stable` to give the optimizer more information
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into math_stable_202505
>  - BigInteger::mag remove Stable
>  - bug fix, from @minborg
>  - BigInteger::mag add `@Stable`
>  - add stable

Looks okay to me

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25437#pullrequestreview-3035674378

From duke at openjdk.org  Sun Jul 20 06:40:03 2025
From: duke at openjdk.org (ExE Boss)
Date: Sun, 20 Jul 2025 06:40:03 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
 [v3]
In-Reply-To: <ZgjRJGyu9IFgCsZyFF3D1cswr9nJD3vq7hWeX6Qumdk=.a8a46b00-108f-4d0f-9d47-cb4932e07d29@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
 <ZgjRJGyu9IFgCsZyFF3D1cswr9nJD3vq7hWeX6Qumdk=.a8a46b00-108f-4d0f-9d47-cb4932e07d29@github.com>
Message-ID: <qzpp4YtuM9UxyPU6IGsNYSeUGVHqS0gNLD1Bof4cy7w=.a2b6d6d5-f477-4d0c-8cde-d8b43295cfd9@github.com>

On Thu, 17 Jul 2025 21:40:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review feedback.

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

> 457:         @Stable
> 458:         private static final double
> 459:             T[] = {

The?legacy **C**?like array?field?syntax is?confusing in?**Java**, and?it?s?not?used for?the?`@Stable?int[]` arrays?below.

Suggestion:

        @Stable
        private static final double[] T = {


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

Or?at?least put?the?`T[]` on?the?same?line so?that it?s?clear why?this?field has?`@Stable`, since?regular `static?final?double`s are?already constant?folded and?@wenshao?s?comment[^1] confused?me on?the??**Conversation**??tab, since?it?was missing?the?`T[]`?there.

Suggestion:

        @Stable
        private static final double T[] = {


[^1]: https://github.com/openjdk/jdk/pull/26341#discussion_r2213012163

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26341#discussion_r2217624377

From alanb at openjdk.org  Sun Jul 20 06:48:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 20 Jul 2025 06:48:38 GMT
Subject: RFR: 8361972: Clarify the condition of System.console() about
 standard input/output [v2]
In-Reply-To: <PMI4a2USZ3ox-Oijc6Cu2xF8tCn6b2PdjRvGcWbBYl4=.17364eb2-cd38-47ea-b7d1-9d58c62767d4@github.com>
References: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
 <TKnCmtTeM0-f1yunDtO8zRno4ZbVWxhiWN0kagttFns=.3f8e4e55-84f4-4eee-924a-e04e46485c12@github.com>
 <HD9ktp88gpejD3h9DLO6HMAHiRNoTnHV-U5fW0xJPhk=.6a3b8a69-4c1b-43f5-ad6a-18f10196c70e@github.com>
 <YXJTMmkw39pSM87RT9BqXM9rwE0KHTcZF7pG3rUfvL8=.ac8e50b0-524f-4f64-8e2f-1e8999909860@github.com>
 <PMI4a2USZ3ox-Oijc6Cu2xF8tCn6b2PdjRvGcWbBYl4=.17364eb2-cd38-47ea-b7d1-9d58c62767d4@github.com>
Message-ID: <nIpdmbTaSvUxRjRO9TTrvjYg9kVVPMgYJ_WA18JOOTc=.1bc8dbca-de3e-42d9-8e2d-5d03e87b5359@github.com>

On Thu, 17 Jul 2025 17:39:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> I was considering the case for `jshell`, where its `System.console()` returns a `Console` instance regardless of the `isTTY` state:
>> 
>> https://github.com/openjdk/jdk/blob/bd55d7a49514da9fa4de0d4a372956e21deab4d2/src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java#L70
>> 
>> That led me to use `may` in the updated spec. I'd appreciate your suggestions on wording.
>
> Since the decision of whether a console exists is dependent on the implementation as specified,
> 
>> Whether a virtual machine has a console is dependent upon the underlying platform
> 
> And the existing wording in this paragraph uses open-ended words such as "may" and "typically", it makes sense to me that this change would follow the same style of wording. If you wanted to concretely define what this implementation does, using one of the `@impl` tags to describe the behavior could be an option?

Okay, so the intent is to specify that it is implementation or configuration specific as to whether there is a Console when standard input or output, but not both, are redirected, is that right? What should users expect isTerminal to return in this case?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26299#discussion_r2217642624

From duke at openjdk.org  Sun Jul 20 17:04:14 2025
From: duke at openjdk.org (fabioromano1)
Date: Sun, 20 Jul 2025 17:04:14 GMT
Subject: RFR: 8077587: BigInteger Roots [v24]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <hvYDM7wvQvtgYvDJxy83Q81phonmmlHUn-f7K_VgIGg=.a2300bb0-1a26-4ac1-a3e1-b331c9db3e40@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

 - Removed trailingwhitespace
 - Revision changes
   
   Revision changes, with explanation comment for initial estimate's computation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/e2a3f402..953b31a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=22-23

  Stats: 65 lines in 2 files changed: 23 ins; 12 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

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

From mdonovan at openjdk.org  Sun Jul 20 17:21:41 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Sun, 20 Jul 2025 17:21:41 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <_aliNvujYU-gs7CUS7oB8VPK595xV4OLnd82vJwYTIY=.6b041c7e-3907-4217-b8ef-a59404ac0a08@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
 <_aliNvujYU-gs7CUS7oB8VPK595xV4OLnd82vJwYTIY=.6b041c7e-3907-4217-b8ef-a59404ac0a08@github.com>
Message-ID: <NGriatYqq8l8ITZXKZRgM2um-GumOBDjsABJatlBR2o=.3a57360e-34c8-467b-8ca3-619c62d4abe4@github.com>

On Wed, 18 Jun 2025 04:41:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

> 
> I see a few tests that do that, nearly all of which are network tests. It is not something I was familiar with. But it doesn't seem right to me that a particular test would use that property to change the behaviour of `OutputAnalyzer`. I also don't think the test should have to opt-in to this kind of behaviour rather than it being directly controlled by the person running the tests. To that end I would see `OutputAnalyzer` examining a specific property, e.g. `OutputAnalyzer.printToStdStreams` to control this.

I didn't mean to suggest that `OutputAnalyzer` uses the `test.debug` property directly, only that if `OutpuAnalyzer` had a constructor that took a boolean argument, the argument _could_ be set based on the value of `test.debug`...

`OutputAnalyzer oa = new OutputAnalyzer(myProcess, Boolean.getBoolean("test.debug"));`

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

PR Comment: https://git.openjdk.org/jdk/pull/25587#issuecomment-3094659115

From duke at openjdk.org  Sun Jul 20 19:03:48 2025
From: duke at openjdk.org (fabioromano1)
Date: Sun, 20 Jul 2025 19:03:48 GMT
Subject: RFR: 8077587: BigInteger Roots [v25]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <opAxIIrKBcZnalLJ_8MpoU9XBovPOJ4RPk6bLwWKG1A=.18a33b27-86e9-4ee5-ae81-333425d487c9@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

  Minor change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/953b31a8..51408575

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=23-24

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

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

From duke at openjdk.org  Sun Jul 20 22:28:48 2025
From: duke at openjdk.org (simon)
Date: Sun, 20 Jul 2025 22:28:48 GMT
Subject: RFR: 8355652: Parse ClassFileFormatVersion from ClassFileVersion
Message-ID: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>

8355652: add new method to return ClassFileFormatVersion from ClassFileVersion.
---------
### 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

### Error
&nbsp;?? The pull request body must not be empty.

### Integration blocker
&nbsp;?? Title mismatch between PR and JBS for issue [JDK-8355652](https://bugs.openjdk.org/browse/JDK-8355652)

### Warning
&nbsp;?? Found trailing period in issue title for `8355652: add new method to return ClassFileFormatVersion from ClassFileVersion.`
Found leading lowercase letter in issue title for `8355652: add new method to return ClassFileFormatVersion from ClassFileVersion.`



### Reviewing
<details><summary>Using <code>git</code></summary>

Checkout this PR locally: \
`$ git fetch https://git.openjdk.org/jdk.git pull/26406/head:pull/26406` \
`$ git checkout pull/26406`

Update a local copy of the PR: \
`$ git checkout pull/26406` \
`$ git pull https://git.openjdk.org/jdk.git pull/26406/head`

</details>
<details><summary>Using Skara CLI tools</summary>

Checkout this PR locally: \
`$ git pr checkout 26406`

View PR using the GUI difftool: \
`$ git pr show -t 26406`

</details>
<details><summary>Using diff file</summary>

Download this PR as a diff file: \
<a href="https://git.openjdk.org/jdk/pull/26406.diff">https://git.openjdk.org/jdk/pull/26406.diff</a>

</details>

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

Commit messages:
 - 8355652: add new method to return ClassFileFormatVersion from ClassFileVersion.

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

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

From duke at openjdk.org  Sun Jul 20 22:49:19 2025
From: duke at openjdk.org (fabioromano1)
Date: Sun, 20 Jul 2025 22:49:19 GMT
Subject: RFR: 8077587: BigInteger Roots [v26]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <fyA_0fZLHSTJ6Hl0fGNVf3hwnn82JhXRLy84YwKuimw=.c89a4fd2-5be6-4981-8238-8958727f8948@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

  Minor change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/51408575..73611cd4

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

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

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

From duke at openjdk.org  Sun Jul 20 23:02:37 2025
From: duke at openjdk.org (fabioromano1)
Date: Sun, 20 Jul 2025 23:02:37 GMT
Subject: RFR: 8077587: BigInteger Roots [v27]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <0x6N_IsMlVMac_rqNFHrPiOScobTNDWu5Q00eoDo3RM=.0d3c4058-d61e-4b8a-ba48-c2095b71eb7d@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

  Formatting changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/73611cd4..06456caa

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

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

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

From duke at openjdk.org  Sun Jul 20 23:33:39 2025
From: duke at openjdk.org (simon)
Date: Sun, 20 Jul 2025 23:33:39 GMT
Subject: RFR: 8355652: Parse ClassFileFormatVersion from ClassFileVersion
In-Reply-To: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
References: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
Message-ID: <1SnIOzJsyWrBHdfrsQh7mT6_ImIeGx1QoifHfHwqo_w=.977f95f8-3a62-4643-8b70-e6f6a1e2934e@github.com>

On Sun, 20 Jul 2025 22:19:07 GMT, simon <duke at openjdk.org> wrote:

> 8355652: add new method to return ClassFileFormatVersion from ClassFileVersion.
> ---------
> ### 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/26406/head:pull/26406` \
> `$ git checkout pull/26406`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/26406` \
> `$ git pull https://git.openjdk.org/jdk.git pull/26406/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 26406`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 26406`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/26406.diff">https://git.openjdk.org/jdk/pull/26406.diff</a>
> 
> </details>
> <details><summary>Using Webrev</summary>
> 
> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/26406#issuecomment-3094832141)
> </details>

@liach I know that I'm commenting on a weekend but it's to you see tomorrow. 

I'm commiting a 1.0 version for this implementation - to get your feedback about

I think we should create some unit tests for this API and classes involved. Where do you think that is the most apprpriate location in the project to do it?

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

PR Comment: https://git.openjdk.org/jdk/pull/26406#issuecomment-3094860148

From liach at openjdk.org  Sun Jul 20 23:41:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 20 Jul 2025 23:41:38 GMT
Subject: RFR: 8355652: Parse ClassFileFormatVersion from ClassFileVersion
In-Reply-To: <1SnIOzJsyWrBHdfrsQh7mT6_ImIeGx1QoifHfHwqo_w=.977f95f8-3a62-4643-8b70-e6f6a1e2934e@github.com>
References: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
 <1SnIOzJsyWrBHdfrsQh7mT6_ImIeGx1QoifHfHwqo_w=.977f95f8-3a62-4643-8b70-e6f6a1e2934e@github.com>
Message-ID: <lrGc0T402-YGh15BhxlTRnuWqjNYYWBPYd9G-oxHZfU=.e46b94a0-0807-4882-8aea-6464d3e47e07@github.com>

On Sun, 20 Jul 2025 23:30:50 GMT, simon <duke at openjdk.org> wrote:

> I think we should create some unit tests for this API and classes involved. Where do you think that is the most appropriate location in the project to do it?

Unit tests for `java.lang.classfile` reside in `test/jdk/jdk/classfile`. They can be run with `make test TEST=jdk/jdk/classfile`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26406#issuecomment-3094863298

From duke at openjdk.org  Sun Jul 20 23:41:39 2025
From: duke at openjdk.org (simon)
Date: Sun, 20 Jul 2025 23:41:39 GMT
Subject: RFR: 8355652: Parse ClassFileFormatVersion from ClassFileVersion
In-Reply-To: <lrGc0T402-YGh15BhxlTRnuWqjNYYWBPYd9G-oxHZfU=.e46b94a0-0807-4882-8aea-6464d3e47e07@github.com>
References: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
 <1SnIOzJsyWrBHdfrsQh7mT6_ImIeGx1QoifHfHwqo_w=.977f95f8-3a62-4643-8b70-e6f6a1e2934e@github.com>
 <lrGc0T402-YGh15BhxlTRnuWqjNYYWBPYd9G-oxHZfU=.e46b94a0-0807-4882-8aea-6464d3e47e07@github.com>
Message-ID: <WRciWArD8dqL6C08SFiaxfdtSvBl2vYX_d_TJ1B9xAI=.eb449c85-42ef-4490-ae28-6c22de7ff16b@github.com>

On Sun, 20 Jul 2025 23:36:53 GMT, Chen Liang <liach at openjdk.org> wrote:

> > I think we should create some unit tests for this API and classes involved. Where do you think that is the most appropriate location in the project to do it?
> 
> Unit tests for `java.lang.classfile` reside in `test/jdk/jdk/classfile`. They can be run with `make test TEST=jdk/jdk/classfile`.

Great! Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/26406#issuecomment-3094864531

From liach at openjdk.org  Mon Jul 21 00:13:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Jul 2025 00:13:41 GMT
Subject: RFR: 8355652: Parse ClassFileFormatVersion from ClassFileVersion
In-Reply-To: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
References: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
Message-ID: <9boUuajMR4dXTViK0qwYubQU1_oPAXXZijdQ8K8aTN0=.733c561d-6ea2-4b6c-b7a7-c38c05ca32a8@github.com>

On Sun, 20 Jul 2025 22:19:07 GMT, simon <duke at openjdk.org> wrote:

> 8355652: add new method to return ClassFileFormatVersion from ClassFileVersion.
> ---------
> ### 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/26406/head:pull/26406` \
> `$ git checkout pull/26406`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/26406` \
> `$ git pull https://git.openjdk.org/jdk.git pull/26406/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 26406`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 26406`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/26406.diff">https://git.openjdk.org/jdk/pull/26406.diff</a>
> 
> </details>
> <details><summary>Using Webrev</summary>
> 
> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/26406#issuecomment-3094832141)
> </details>

src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileVersionImpl.java line 54:

> 52:     public Optional<ClassFileFormatVersion> formatVersion() {
> 53:         try {
> 54:             return Optional.of(ClassFileFormatVersion.fromMajor(majorVersion));

You should check the minor version to be 0 for major versions 54 and later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26406#discussion_r2218013444

From duke at openjdk.org  Mon Jul 21 00:37:43 2025
From: duke at openjdk.org (simon)
Date: Mon, 21 Jul 2025 00:37:43 GMT
Subject: RFR: 8355652: Parse ClassFileFormatVersion from ClassFileVersion
In-Reply-To: <9boUuajMR4dXTViK0qwYubQU1_oPAXXZijdQ8K8aTN0=.733c561d-6ea2-4b6c-b7a7-c38c05ca32a8@github.com>
References: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
 <9boUuajMR4dXTViK0qwYubQU1_oPAXXZijdQ8K8aTN0=.733c561d-6ea2-4b6c-b7a7-c38c05ca32a8@github.com>
Message-ID: <DZP8zTjNIbID298YbVbW4f7P-orWDGsASTq9oE7wvPQ=.87eaf865-023a-49db-ac44-06994d67e081@github.com>

On Mon, 21 Jul 2025 00:11:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 8355652: add new method to return ClassFileFormatVersion from ClassFileVersion.
>> ---------
>> ### 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/26406/head:pull/26406` \
>> `$ git checkout pull/26406`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/26406` \
>> `$ git pull https://git.openjdk.org/jdk.git pull/26406/head`
>> 
>> </details>
>> <details><summary>Using Skara CLI tools</summary>
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 26406`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 26406`
>> 
>> </details>
>> <details><summary>Using diff file</summary>
>> 
>> Download this PR as a diff file: \
>> <a href="https://git.openjdk.org/jdk/pull/26406.diff">https://git.openjdk.org/jdk/pull/26406.diff</a>
>> 
>> </details>
>> <details><summary>Using Webrev</summary>
>> 
>> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/26406#issuecomment-3094832141)
>> </details>
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileVersionImpl.java line 54:
> 
>> 52:     public Optional<ClassFileFormatVersion> formatVersion() {
>> 53:         try {
>> 54:             return Optional.of(ClassFileFormatVersion.fromMajor(majorVersion));
> 
> You should check the minor version to be 0 for major versions 54 and later.

Do you mean something like this? 


@Override
    public Optional<ClassFileFormatVersion> formatVersion() {
        if (majorVersion >= 54 || minorVersion == 0) {
            return Optional.empty();
        }
        try {
            return Optional.of(ClassFileFormatVersion.fromMajor(majorVersion));
        } catch (IllegalArgumentException e) {
            return Optional.empty();
        }
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26406#discussion_r2218024287

From liach at openjdk.org  Mon Jul 21 02:53:39 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Jul 2025 02:53:39 GMT
Subject: RFR: 8355652: Parse ClassFileFormatVersion from ClassFileVersion
In-Reply-To: <DZP8zTjNIbID298YbVbW4f7P-orWDGsASTq9oE7wvPQ=.87eaf865-023a-49db-ac44-06994d67e081@github.com>
References: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
 <9boUuajMR4dXTViK0qwYubQU1_oPAXXZijdQ8K8aTN0=.733c561d-6ea2-4b6c-b7a7-c38c05ca32a8@github.com>
 <DZP8zTjNIbID298YbVbW4f7P-orWDGsASTq9oE7wvPQ=.87eaf865-023a-49db-ac44-06994d67e081@github.com>
Message-ID: <ZC0BL34yfdWC03OXMVCkD0TsgL9XekhDvMvNnxfT7ss=.c024c1bf-728e-4e8c-8a03-4b7fce7edd68@github.com>

On Mon, 21 Jul 2025 00:32:24 GMT, simon <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileVersionImpl.java line 54:
>> 
>>> 52:     public Optional<ClassFileFormatVersion> formatVersion() {
>>> 53:         try {
>>> 54:             return Optional.of(ClassFileFormatVersion.fromMajor(majorVersion));
>> 
>> You should check the minor version to be 0 for major versions 54 and later.
>
> Do you mean something like this? 
> 
> 
> @Override
>     public Optional<ClassFileFormatVersion> formatVersion() {
>         if (majorVersion < 54 || minorVersion != 0) {
>             return Optional.empty();
>         }
>         try {
>             return Optional.of(ClassFileFormatVersion.fromMajor(majorVersion));
>         } catch (IllegalArgumentException e) {
>             return Optional.empty();
>         }
>     }

No, this logic is wrong. It's more like the check in https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.base/share/classes/jdk/internal/misc/VM.java#L174-L180


 public Optional<ClassFileFormatVersion> formatVersion() { 
     if (majorVersion < ClassFile.JAVA_1_VERSION || majorVersion > ClassFile.latestMajorVersion()) return Optional.empty(); 
     // for major version is between 45 and 55 inclusive, the minor version may be any value 
     if (majorVersion >= ClassFile.JAVA_12_VERSION && minorVersion != 0) return Optional.empty(); 
     // otherwise, only minor version 0 is a defined, persistent format
     return Optional.of(ClassFileFormatVersion.fromMajor(majorVersion)); 
 }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26406#discussion_r2218095625

From swen at openjdk.org  Mon Jul 21 06:57:43 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 21 Jul 2025 06:57:43 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal [v4]
In-Reply-To: <nOyjL13Gw7c91vi9NtdXLyLpyI9VpoFTRaWzHcM9Quk=.c9ed3ca3-fe1a-4e69-a058-dcc13e5a0f4f@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
 <nOyjL13Gw7c91vi9NtdXLyLpyI9VpoFTRaWzHcM9Quk=.c9ed3ca3-fe1a-4e69-a058-dcc13e5a0f4f@github.com>
Message-ID: <ZV8inAsRf3TZ4XS97juH36brpecj_9idbfZk9KTj530=.9358fbc0-02dc-41f1-8a68-21db96c797d1@github.com>

On Wed, 4 Jun 2025 13:12:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Some static final arrays of BigInteger and BigDecimal are stable and immutable. We should add `@Stable` to give the optimizer more information
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into math_stable_202505
>  - BigInteger::mag remove Stable
>  - bug fix, from @minborg
>  - BigInteger::mag add `@Stable`
>  - add stable

I will integrate it in 24 hours, @minberg do you have any other questions?

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

PR Comment: https://git.openjdk.org/jdk/pull/25437#issuecomment-3095466954

From jiangli at openjdk.org  Mon Jul 21 07:18:55 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 21 Jul 2025 07:18:55 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: <q4R1OCIUVggI3nVK3IK_DM1Fmgcu7xO3cdnY5xvn1Iw=.17fb68ac-5056-4199-b60f-b10ac106c427@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

@liach Sorry for the delay. I looked through your changes and it's good to see that we are moving away from the hard-code list of classes, etc in the VM code for archiving/caching initialized states. The mechanism of marking class/methods/fields in the Java source is a good start for the more general support.

A few suggestions (or comments) for future considerations not don't necessarily to be included in your current PR:

- heapShared.cpp contains a list of hard coded classes & fields for archiving the initialized states in CDS archive. With the support for using annotation for pre-init being added to the mainline, the support can be applied to those classes as well.
- There could be cases where AOTC is not enabled but CDS or heap archiving with pre-initialization is enabled, it's good to consider more general naming for the annotations rather than using AOT-only-context based annotations, like `AOTSafeClassInitializer` and `AOTRuntimeSetup`.
- As discussed during Leyden/premain meetings, there are classes/fields that are not suitable for pre-init and caching, such as Thread, Random, System, etc. We want to annotate or mark them so AOTC or CDS archiving ensures those states are not cached.
- It's important to enhance the heap archiving mechanism to safeguard the cached object graphs to make sure they can be materialized safely for runtime usages without any unexpected side-effects. Restrictions/assumptions such as the ones that you documented in AOTSafeClassInitializer.java should be built into the heap archiving and ensured at AOT assembling phase or CDS archive time. We can look into extracting some of the parts from https://github.com/jianglizhou/jdk11u-fast-startup-incubator for the heap archiving related enhancements.


/// `@AOTSafeClassInitializer`. This should be done when:
///
/// 1. It's possible for an artifact used in the linking java.lang.invoke primitives
///    (usually a MethodHandle) to directly or indirectly remember the value of a static
///    field in this class.
/// 2. You have validated that the static initializer of this class doesn't depend on
///    transient states (i.e., names of temporary directories) that cannot be carried over
///    to a future production run.
/// 3. All supertypes of this class must also have the `@AOTSafeClassInitializer`
///    annotation.

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

PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-3036852633

From myankelevich at openjdk.org  Mon Jul 21 09:02:45 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 21 Jul 2025 09:02:45 GMT
Subject: RFR: 8355652: Parse ClassFileFormatVersion from ClassFileVersion
In-Reply-To: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
References: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
Message-ID: <MpW4C_foCl5UrDH2PhleuaCwvToMtHf3yvki3SysQDo=.0f006b61-1af3-462f-bc79-717d84cd1740@github.com>

On Sun, 20 Jul 2025 22:19:07 GMT, simon <duke at openjdk.org> wrote:

> 8355652: add new method to return ClassFileFormatVersion from ClassFileVersion.
> ---------
> ### 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/26406/head:pull/26406` \
> `$ git checkout pull/26406`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/26406` \
> `$ git pull https://git.openjdk.org/jdk.git pull/26406/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 26406`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 26406`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/26406.diff">https://git.openjdk.org/jdk/pull/26406.diff</a>
> 
> </details>
> <details><summary>Using Webrev</summary>
> 
> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/26406#issuecomment-3094832141)
> </details>

src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileVersionImpl.java line 28:

> 26: 
> 27: import java.lang.classfile.ClassFileVersion;
> 28: import java.lang.reflect.ClassFileFormatVersion;

Nitpick: copyright year :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26406#discussion_r2218575571

From pminborg at openjdk.org  Mon Jul 21 09:09:41 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 21 Jul 2025 09:09:41 GMT
Subject: RFR: 8357913: Add `@Stable` to BigInteger and BigDecimal [v4]
In-Reply-To: <ZV8inAsRf3TZ4XS97juH36brpecj_9idbfZk9KTj530=.9358fbc0-02dc-41f1-8a68-21db96c797d1@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
 <nOyjL13Gw7c91vi9NtdXLyLpyI9VpoFTRaWzHcM9Quk=.c9ed3ca3-fe1a-4e69-a058-dcc13e5a0f4f@github.com>
 <ZV8inAsRf3TZ4XS97juH36brpecj_9idbfZk9KTj530=.9358fbc0-02dc-41f1-8a68-21db96c797d1@github.com>
Message-ID: <XlG6dl6ZlWPDmaZ38bvkkrJd0tYK7ekODE2zIuID5PM=.8610a17c-0b5a-4fec-b605-8fb837dbf82f@github.com>

On Mon, 21 Jul 2025 06:54:46 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> I will integrate it in 24 hours, @minberg do you have any other questions?

No further comments from me. Please go ahead and integrate.

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

PR Comment: https://git.openjdk.org/jdk/pull/25437#issuecomment-3095820477

From swen at openjdk.org  Mon Jul 21 09:40:47 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 21 Jul 2025 09:40:47 GMT
Subject: Integrated: 8357913: Add `@Stable` to BigInteger and BigDecimal
In-Reply-To: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
References: <SME9iDz3X9ocBp4NPr4Cm6891zZk5qZ8mdGhvPBdbdY=.4038f035-a27e-4887-bf04-ef0bb6de00b8@github.com>
Message-ID: <lxPyXateOcZOI9kPsiLDvrTORPwfhb6puYKAywEj3Bw=.25bc4af7-1331-4071-ae8d-b3436c808928@github.com>

On Sun, 25 May 2025 22:35:56 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Some static final arrays of BigInteger and BigDecimal are stable and immutable. We should add `@Stable` to give the optimizer more information

This pull request has now been integrated.

Changeset: 8f1bb59e
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f1bb59e1a0137fe9a5d4477971d21e645735b4d
Stats:     10 lines in 2 files changed: 10 ins; 0 del; 0 mod

8357913: Add `@Stable` to BigInteger and BigDecimal

Reviewed-by: rgiulietti, liach

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

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

From duke at openjdk.org  Mon Jul 21 11:43:54 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 21 Jul 2025 11:43:54 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v12]
In-Reply-To: <yQoWs6r3QYoNoA9vfCM-DwasBs_pRFAecZulKJpKoCg=.133fb988-9647-4fb6-8102-8f82c209066e@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <eRJU5NDSnIIlE9ssz_zq_CrbyGAvaaWf7W6bzI0uDiU=.f4b4907c-ae6b-431d-81fd-bd97c1f81231@github.com>
 <yQoWs6r3QYoNoA9vfCM-DwasBs_pRFAecZulKJpKoCg=.133fb988-9647-4fb6-8102-8f82c209066e@github.com>
Message-ID: <ogI0LDJwH7ochb54mGArTep8RqX0lnDPrffe9vFaHx4=.4c6560aa-583e-4679-9fdb-228a76198723@github.com>

On Fri, 18 Jul 2025 16:43:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   Resync after benchmark.
>
> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 543:
> 
>> 541:         // As such, non-directory nodes are always complete.
>> 542:         boolean isCompleted() {
>> 543:             return true;
> 
> Seems like a risky default to have this be a concrete method/default that is not required to be overridden.
> A subclass (not that many here) could forget to override and have a default wrong answer. YMMV.

Hmm, fair. The protected constructor only exists because of ExplodedImage (and I had hoped to be able to get rid of that completely with this work, but sadly couldn't). I added a clear warning to not create other subtypes. I could move this to an abstract method, but honestly I don't think it fixes anything since "completeness" is a concept that only makes sense internally for the implementation in this class (it's package access, so cannot be seen elsewhere). Making it abstract would mean that it needs to be more visible, which I dislike.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2218946364

From duke at openjdk.org  Mon Jul 21 11:56:22 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 21 Jul 2025 11:56:22 GMT
Subject: RFR: 8077587: BigInteger Roots [v28]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <Xed-HiU4Ehc4XZcMwziv-9KNCGrIiy8TweLpQNQF2RE=.ff9ab771-b311-4e53-8c22-98cb21895373@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

  Discard wrong bits from the initial estimate

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/06456caa..5357825c

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

  Stats: 53 lines in 1 file changed: 10 ins; 20 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

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

From duke at openjdk.org  Mon Jul 21 12:03:11 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 21 Jul 2025 12:03:11 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v13]
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: <J-JqNtmP25GS9ovkcbl-IWtEZ2Oa8iGSROlZTuVAHJQ=.7c38d62a-020c-4edc-baac-c42833e5ca97@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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26054/files
  - new: https://git.openjdk.org/jdk/pull/26054/files/75fff5e5..12f34994

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

  Stats: 15 lines in 1 file changed: 9 ins; 4 del; 2 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  Mon Jul 21 12:03:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 21 Jul 2025 12:03:12 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v12]
In-Reply-To: <yQoWs6r3QYoNoA9vfCM-DwasBs_pRFAecZulKJpKoCg=.133fb988-9647-4fb6-8102-8f82c209066e@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <eRJU5NDSnIIlE9ssz_zq_CrbyGAvaaWf7W6bzI0uDiU=.f4b4907c-ae6b-431d-81fd-bd97c1f81231@github.com>
 <yQoWs6r3QYoNoA9vfCM-DwasBs_pRFAecZulKJpKoCg=.133fb988-9647-4fb6-8102-8f82c209066e@github.com>
Message-ID: <_xr23bKDmLusU-_TXQICLnk4Y11GBrIA5jvK-r4GL74=.97a4be69-1de6-4d18-bd2d-21ace429b985@github.com>

On Fri, 18 Jul 2025 16:01:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   Resync after benchmark.
>
> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 28:
> 
>> 26: 
>> 27: import java.io.IOException;
>> 28: import java.io.UncheckedIOException;
> 
> Unused, can be removed

Done, thank's for the spot (I miss auto-import arrange and auto-format on save).

> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 279:
> 
>> 277:         }
>> 278: 
>> 279:         /// Returns a node in the JRT filesystem namespace, or null if no resource or
> 
> Using the standard javadoc tags for @param, @return can give some consistency and readability even for internal methods.

Absolutely. This sort of thing is always a balance between clarity and conciseness. But here I think you're right so I pulled the `name` into a `@param`. I dislike doing it for the return types in most cases though, since that encourages duplication with the method's first sentence.

> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 532:
> 
>> 530:     public abstract static class Node {
>> 531:         private final String name;
>> 532:         private final BasicFileAttributes fileAttrs;
> 
> It seems a bit wasteful to cache the same attributes in every Node.
> But its no more expensive (size-wise) than a referernce to the ImageReader and the indirection.

Quite, if I had to add any more fields here I'd have suggested making `Node` an inner class. This opens up better API options (get buffer directly from the node without going back to the reader) but also means that any users who keep nodes beyond the scope of the reader that spawned then end up in trouble (since the reader can be explicitly closed). I erred on the side of "don't change it" since I didn't need a new field here.

> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 611:
> 
>> 609:          *
>> 610:          * <p>If this node is not a directory ({@code isDirectory() == false})
>> 611:          * then this method will throw {@link IllegalStateException}.
> 
> A mismatch in overriding could give inconsistent results (since the impl does not call `isDirectory()`.

True, though would you prefer to change the comment ("by default this method throws... and is overridden by directory subclasses...") or the implementation of things like `getChildNames()` so they call `isDirectory()` ?

Personally I dislike this "test and call" approach and would rather have restructured the API to be more object-oriented, and have callers use a more structured dispatch mechanism (but this would incur cost of lambdas etc.), but that's a really disruptive change.

Alternatively a type token/enum of some sort could be used to define node type. This is all internal/trusted API though, so I'm happy with trusting that things "do what they say" (it's going to be really obvious if something claims to be a directory and then throws when asks for its child names, and that's almost exclusively why anyone calls isDirectory() to start with).

So in summary, apart from maybe tweaking the comment slightly, I think this is fine as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2218984216
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2218982421
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2218978525
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2218973869

From duke at openjdk.org  Mon Jul 21 12:10:06 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 21 Jul 2025 12:10:06 GMT
Subject: RFR: 8077587: BigInteger Roots [v29]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <Chf8E6IiGrey3-rHaspoDPG3BADeQr3v52e860hY7vg=.346830c2-cca8-4714-84e0-850be720f914@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

  Make sure to round up

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/5357825c..e305c9f6

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

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

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

From duke at openjdk.org  Mon Jul 21 12:14:24 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 21 Jul 2025 12:14:24 GMT
Subject: RFR: 8077587: BigInteger Roots [v30]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <_GP8cKJp8cu05R7BNpUkP5kGoUo1CQigv8VkqP2pSFk=.c377d918-90bb-4717-a942-15533104abdc@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

  Revert "Make sure to round up"
  
  This reverts commit e305c9f68914553421f2fdd8b4389eaf03946fea.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/e305c9f6..5107ac2e

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

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

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

From vyazici at openjdk.org  Mon Jul 21 12:33:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 21 Jul 2025 12:33:30 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v9]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <S0kkg0joILnLyfYl7XQDdmmxv4PsyNtK3wpeLR3X6eA=.e76494c6-e275-4ae3-a5f6-b624294bfb12@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` 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");
>         }
>     }
> }
> ...

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

 - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
 - Make `StringCoding` encoding intrinsics lenient
 - Fix `encodeISOArray` bounds checks and Javadoc
 - Disable `TestVerifyIntrinsicChecks` for GraalVM
 - Relax target array capacity check for intrinsic Java wrappers
   
   It's not possible to determine the required capacity of the target
   array in constant time, as Unicode code points may occupy either one
   or two `char` values. As a result, existing implementations typically
   invoke encoding methods in a loop, handling each unmappable character
   on a case-by-case basis. For an example, see
   `sun.nio.cs.DoubleByte.Encoder::encode`.
 - Fix out-of-bounds in `sun.nio.cs.SingleByte.Encoder::encodeArrayLoop`
 - Replace casting with `as_Region()` in `generate_string_range_check`
 - Duplicate affected tests with `-XX:+VerifyIntrinsicChecks` variants
 - Fix compiler error in `generate_string_range_check`
 - Add test verifying the effectiveness of `VerifyIntrinsicChecks`
 - ... and 13 more: https://git.openjdk.org/jdk/compare/c179d680...f69374fb

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/db1ed388..f69374fb

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

  Stats: 13609 lines in 414 files changed: 10649 ins; 1054 del; 1906 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 vyazici at openjdk.org  Mon Jul 21 12:41:45 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 21 Jul 2025 12:41:45 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v3]
In-Reply-To: <4zqK_rAHpX2bdDGf_kw2TOXtdOgONZykPs7mlR-rDrA=.d7d2bcd4-1e48-40ed-9628-46a681a5c4bb@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <8vCbaelpmz8qseHlyYRYiF0iDIycfg63fnthX52ZqJk=.3fa6d066-4a5b-4dae-8bcd-d25a336ccb94@github.com>
 <4zqK_rAHpX2bdDGf_kw2TOXtdOgONZykPs7mlR-rDrA=.d7d2bcd4-1e48-40ed-9628-46a681a5c4bb@github.com>
Message-ID: <vTTemkuBpipqCFqjjT42XgDO3LKVEhSwCZFLgiYYu5o=.600dfb3b-f433-4783-98a3-be207b52241b@github.com>

On Wed, 16 Jul 2025 05:28:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>>  - Apply review feedback (styling changes)
>>  - Minimize the number of touched lines in `vmIntrinsics.hpp`
>>  - Remove Markdown-styling in comments
>>  - Improve wording of the `VerifyIntrinsicChecks` flag
>>  - 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
>>    
>>    This reverts commit 196fc5d406851b8e7070c97ac53ca59c4615aad9.
>>  - Improve intrinsics in `StringCoding`
>>  - Add `StringCodingCountPositives` benchmark
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/c4b2ddec...85f19864
>
> src/hotspot/share/opto/c2_globals.hpp line 665:
> 
>> 663:           "prints attempted and successful inlining of intrinsics")         \
>> 664:                                                                             \
>> 665:   develop(bool, VerifyIntrinsicChecks, false,                               \
> 
> We should add testing that uses this new flag. Maybe we could add a run to the tests that check the affected intrinsics? We could also add it to our (Oracle internal) stress test jobs at higher tiers.

Given @TobiHartmann's later approval, I'm marking this as resolved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2219089077

From vyazici at openjdk.org  Mon Jul 21 12:46:43 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 21 Jul 2025 12:46:43 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v8]
In-Reply-To: <MXCeeaIUUckQu-h3Q0vdW1LZg9LDaJGCxmREH-DLTnk=.bafc71a3-6bc4-4118-aa0c-0a0cda81881c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
 <MXCeeaIUUckQu-h3Q0vdW1LZg9LDaJGCxmREH-DLTnk=.bafc71a3-6bc4-4118-aa0c-0a0cda81881c@github.com>
Message-ID: <hRPSasIDVR6ergOr_PqzMio-teConjBQ3eb0qXMyEmk=.2aaec7cb-36b3-4f9d-949d-e81c8f3f55df@github.com>

On Thu, 17 Jul 2025 13:58:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace casting with `as_Region()` in `generate_string_range_check`
>
> src/java.base/share/classes/java/lang/StringCoding.java line 130:
> 
>> 128:      * <p>
>> 129:      * This method assumes that {@code sa} is encoded in UTF-16, and hence,
>> 130:      * each {@code char} maps to 2 bytes.
> 
> Since `sa` is assumed to be encoded in UTF-16, what's the point of the previous paragraph?

It might be obvious to some, but some (incl. myself) got really confused on what input arguments actually denote, and how they are operated. I'm inclined to keep the for-dummies explanation, unless there is a strong objection.

> src/java.base/share/classes/java/lang/StringCoding.java line 150:
> 
>> 148:         Objects.requireNonNull(sa, "sa");
>> 149:         Objects.requireNonNull(da, "da");
>> 150:         Preconditions.checkFromIndexSize(sp, len << 1, sa.length, Preconditions.AIOOBE_FORMATTER);
> 
> Since `sp` is a character index and `len` counts characters but `sa.length` is in bytes, this should look like so
> Suggestion:
> 
>         Preconditions.checkFromIndexSize(sp, len, sa.length >>> 1, Preconditions.AIOOBE_FORMATTER);
> 
> or something similar.

Very sharp of you @rgiulietti! Thanks so much! ? Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2219097580
PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2219099452

From vyazici at openjdk.org  Mon Jul 21 12:46:45 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 21 Jul 2025 12:46:45 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v8]
In-Reply-To: <RT93K6Emgyktk7vf53EKMZrKIp4zGqVus9x5V7mmGAI=.e05a92eb-4911-4dcc-bbae-8e4a38cf0723@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
 <RT93K6Emgyktk7vf53EKMZrKIp4zGqVus9x5V7mmGAI=.e05a92eb-4911-4dcc-bbae-8e4a38cf0723@github.com>
Message-ID: <z5DWubj_VZ1lPSLtqXMxZ2eLA_O293UoO7a75VVb4B4=.728ced9b-a203-47fa-8c6f-a8ce7f5361d4@github.com>

On Thu, 17 Jul 2025 15:02:21 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace casting with `as_Region()` in `generate_string_range_check`
>
> test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 25:
> 
>> 23: 
>> 24: /*
>> 25:  * @test
> 
> could you please add ` * @requires !vm.graal.enabled`? Graal is failing this test

@mur47x111 added in 4016c7a1fe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2219101443

From vyazici at openjdk.org  Mon Jul 21 12:52:40 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 21 Jul 2025 12:52:40 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v10]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <LtJhO7a1IgjmD5zAKXBEdQFkrat31lyzQCmDicOJIls=.8b45fc4f-5d9d-494f-8bb3-1f2070dd0807@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` 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");
>         }
>     }
> }
> ...

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

  Remove superseded `@throws` Javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/f69374fb..86e3ed8d

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

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 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 vyazici at openjdk.org  Mon Jul 21 12:52:43 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 21 Jul 2025 12:52:43 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v9]
In-Reply-To: <S0kkg0joILnLyfYl7XQDdmmxv4PsyNtK3wpeLR3X6eA=.e76494c6-e275-4ae3-a5f6-b624294bfb12@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <S0kkg0joILnLyfYl7XQDdmmxv4PsyNtK3wpeLR3X6eA=.e76494c6-e275-4ae3-a5f6-b624294bfb12@github.com>
Message-ID: <IEqpJSNVHphgf3oTw6QcCE_T6xlQjxhx5CTv-KvxWOY=.1e27b168-f0fa-4bc6-8712-c1b371f0e489@github.com>

On Mon, 21 Jul 2025 12:33:30 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 IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` 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...
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 23 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Make `StringCoding` encoding intrinsics lenient
>  - Fix `encodeISOArray` bounds checks and Javadoc
>  - Disable `TestVerifyIntrinsicChecks` for GraalVM
>  - Relax target array capacity check for intrinsic Java wrappers
>    
>    It's not possible to determine the required capacity of the target
>    array in constant time, as Unicode code points may occupy either one
>    or two `char` values. As a result, existing implementations typically
>    invoke encoding methods in a loop, handling each unmappable character
>    on a case-by-case basis. For an example, see
>    `sun.nio.cs.DoubleByte.Encoder::encode`.
>  - Fix out-of-bounds in `sun.nio.cs.SingleByte.Encoder::encodeArrayLoop`
>  - Replace casting with `as_Region()` in `generate_string_range_check`
>  - Duplicate affected tests with `-XX:+VerifyIntrinsicChecks` variants
>  - Fix compiler error in `generate_string_range_check`
>  - Add test verifying the effectiveness of `VerifyIntrinsicChecks`
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/514f29e4...f69374fb

Needed to replace all `Preconditions` invocations throwing `AIOOB` on failure with a more lenient approach that returns 0 on out-of-bounds, because,

1. this matches the compiler intrinsic behavior
2. there are several (i.e., ~7) `sun.nio.cs` classes that depend on this lenient behavior. I needed to either fix(?) these 7 classes or make the intrinsic wrappers more lenient

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

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3096649239

From vyazici at openjdk.org  Mon Jul 21 12:54:50 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 21 Jul 2025 12:54:50 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v9]
In-Reply-To: <S0kkg0joILnLyfYl7XQDdmmxv4PsyNtK3wpeLR3X6eA=.e76494c6-e275-4ae3-a5f6-b624294bfb12@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <S0kkg0joILnLyfYl7XQDdmmxv4PsyNtK3wpeLR3X6eA=.e76494c6-e275-4ae3-a5f6-b624294bfb12@github.com>
Message-ID: <yY_P2SdSfsmzi5cbyKNGc9SDG51PucXPQkIXSBqIJwQ=.c8f111a9-13e6-458e-8695-0a8009421689@github.com>

On Mon, 21 Jul 2025 12:33:30 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 IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` 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...
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 23 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Make `StringCoding` encoding intrinsics lenient
>  - Fix `encodeISOArray` bounds checks and Javadoc
>  - Disable `TestVerifyIntrinsicChecks` for GraalVM
>  - Relax target array capacity check for intrinsic Java wrappers
>    
>    It's not possible to determine the required capacity of the target
>    array in constant time, as Unicode code points may occupy either one
>    or two `char` values. As a result, existing implementations typically
>    invoke encoding methods in a loop, handling each unmappable character
>    on a case-by-case basis. For an example, see
>    `sun.nio.cs.DoubleByte.Encoder::encode`.
>  - Fix out-of-bounds in `sun.nio.cs.SingleByte.Encoder::encodeArrayLoop`
>  - Replace casting with `as_Region()` in `generate_string_range_check`
>  - Duplicate affected tests with `-XX:+VerifyIntrinsicChecks` variants
>  - Fix compiler error in `generate_string_range_check`
>  - Add test verifying the effectiveness of `VerifyIntrinsicChecks`
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/343fc72a...f69374fb

> > What is the thinking when an `@IntrinsicCandidate` method invokes another `@IntrinsicCandidate` method? Which part is responsible for the checks?
> 
> ...
> In the case of `StringUTF16.getChar`, ...

@rgiulietti, thanks so much for this crucial question. @rose00, thanks so much for the elaborate response. I will work on `StringUTF16` in a separate PR and use these guidelines provided. ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3096668620

From alanb at openjdk.org  Mon Jul 21 12:56:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Jul 2025 12:56:46 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v13]
In-Reply-To: <J-JqNtmP25GS9ovkcbl-IWtEZ2Oa8iGSROlZTuVAHJQ=.7c38d62a-020c-4edc-baac-c42833e5ca97@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <J-JqNtmP25GS9ovkcbl-IWtEZ2Oa8iGSROlZTuVAHJQ=.7c38d62a-020c-4edc-baac-c42833e5ca97@github.com>
Message-ID: <HV66te5AESNS360CXwal9hHiK1D1now6KmKGsHupsG4=.4b361d1d-3e9e-4235-8d39-a5373e35e572@github.com>

On Mon, 21 Jul 2025 12:03: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...
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback changes.

I had a brief chat with Sundar about these changes so one or both of us will review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26054#issuecomment-3096681513

From vyazici at openjdk.org  Mon Jul 21 13:28:00 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 21 Jul 2025 13:28:00 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v11]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <_YafZXn8pIbA-zuOFNN5sVGBM-uKKy47RPhgRod9Tf4=.1927921f-59af-44a2-be6d-18ce70779f51@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` 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");
>         }
>     }
> }
> ...

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

  Fix bit shifting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/86e3ed8d..025c7ef7

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 vyazici at openjdk.org  Mon Jul 21 13:56:42 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 21 Jul 2025 13:56:42 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v8]
In-Reply-To: <PmH2X0PiqCK7Zz7HQ5d9948bfKM950ziS9VN2Epf6Dk=.fab73b5d-5511-47ef-9f93-4b9496820a1d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <mU0GH2Q6PdT1UwUMBT4lTntH9meY6W2pmuDUK3-lrus=.c1cf8f42-c298-40d1-8cb5-58e1d2e10e6d@github.com>
 <yu8kjKN35lgZh1rQGK-KCpNHObLQlkPLrzWVpQ9Gnc8=.e9684b18-ec3e-4164-a22e-1b5fdde7344f@github.com>
 <PmH2X0PiqCK7Zz7HQ5d9948bfKM950ziS9VN2Epf6Dk=.fab73b5d-5511-47ef-9f93-4b9496820a1d@github.com>
Message-ID: <Blo9pDxu4WBRhzk6vqcKJ75-W1BhkhONP-zoBDM182Y=.40b7806b-d5b8-49b1-83fe-62f8745fac71@github.com>

On Thu, 17 Jul 2025 15:33:37 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> What is the thinking when an `@IntrinsicCandidate` method invokes another `@IntrinsicCandidate` method?
>> Which part is responsible for the checks?
>> 
>> For example, the Java code of `StringCoding.encodeISOArray0()` invokes `StringUTF16.getChar()`, another `@IntrinsicCandidate` method. The latter does not check its arguments (OK, there's an `assert`, but this is a weak check). The invocation from `encodeISOArray0()` is fine and safe, but `getChar()` is invoked by other parts of the code.
>> 
>> So what is the general strategy? Add checks to `getChar()` and rely on the runtime to eliminate redundant checks?
>
>> What is the thinking when an `@IntrinsicCandidate` method invokes another `@IntrinsicCandidate` method? Which part is responsible for the checks?
>> 
>> For example, the Java code of `StringCoding.encodeISOArray0()` invokes `StringUTF16.getChar()`, another `@IntrinsicCandidate` method. The latter does not check its arguments (OK, there's an `assert`, but this is a weak check). The invocation from `encodeISOArray0()` is fine and safe, but `getChar()` is invoked by other parts of the code.
>> 
>> So what is the general strategy? Add checks to `getChar()` and rely on the runtime to eliminate redundant checks?
> 
> To reformulate my confusing question for the above example, there are apparently around 75-80 invocations of `getChar()`. How to make sure that they are all safe? Some are easy to verify, but others are not.

Even though the `tier1,tier2,tier3,tier4,tier5,hs-comp-stress,hs-precheckin-comp` tests pass on several platforms, @rgiulietti pointed me other shortcomings regarding the recent lenient approach taken. Please allow me some time with this PR. I will keep this PR updated. :popcorn:

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

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3096882515

From mbaesken at openjdk.org  Mon Jul 21 14:19:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 21 Jul 2025 14:19:09 GMT
Subject: RFR: 8362889: [GCC static analyzer] leak in libstringPlatformChars.c
Message-ID: <ordEhGmC8cdl8LQKu-tmqNlvKSAK3ek3FUH6TMnpc-M=.b8c73a08-d65d-42ee-82a7-f3a0fd95d4db@github.com>

This is reported by the gcc static analyzer (-fanalyzer); it is just test coding so not very critical but probably should still be adjusted .


/jdk/test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c:74:12: warning: leak of 'str' [CWE-401] [-Wanalyzer-malloc-leak]
   74 | return JNU_NewStringPlatform(env, str);

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

Commit messages:
 - JDK-8362889

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

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

From per-ake.minborg at oracle.com  Mon Jul 21 15:02:22 2025
From: per-ake.minborg at oracle.com (Per-Ake Minborg)
Date: Mon, 21 Jul 2025 15:02:22 +0000
Subject: FFM - Optimizing string reads in MemorySegment
In-Reply-To: <CAL4QsgvQ-O4JeLEjKjZH_p5+SAO5hCWdWJPFtBRDL-r3d_fULA@mail.gmail.com>
References: <CAL4QsgvQ-O4JeLEjKjZH_p5+SAO5hCWdWJPFtBRDL-r3d_fULA@mail.gmail.com>
Message-ID: <SA1PR10MB7832CEACC3EBC0517BEDC4DEDA5DA@SA1PR10MB7832.namprd10.prod.outlook.com>

Hi Liam!

Thank you for your comments on MemorySegment::getString !

The intention was that the creation of the intermediate array should be elided, but as you point out, that is (at least sometimes) not the case. I've made an experimental patch where I've used JavaLangAccess::uncheckedNewStringNoRepl in StringSupport which looks promising:


Base:
ToJavaStringTest.panama_readString   5 avgt 30 13.559 ? 0.246 ns/op
ToJavaStringTest.panama_readString  20 avgt 30 67.047 ? 7.541 ns/op <- Slow
ToJavaStringTest.panama_readString 100 avgt 30 28.092 ? 0.547 ns/op
ToJavaStringTest.panama_readString 200 avgt 30 37.679 ? 0.645 ns/op
ToJavaStringTest.panama_readString 451 avgt 30 64.544 ? 1.096 ns/op

Experimental Patch:
ToJavaStringTest.panama_readString   5 avgt 30 8.847 ? 0.178 ns/op
ToJavaStringTest.panama_readString  20 avgt 30 20.332 ? 4.495 ns/op
ToJavaStringTest.panama_readString 100 avgt 30 21.808 ? 0.315 ns/op
ToJavaStringTest.panama_readString 200 avgt 30 28.711 ? 0.105 ns/op
ToJavaStringTest.panama_readString 451 avgt 30 51.806 ? 1.067 ns/op


So, this indicates that there are gains to be made here, although the ultimate solution might be something else (such as improving inlining). I have raised an issue for this<https://bugs.openjdk.org/browse/JDK-8362893>.

Thanks again for bringing this to the general knowledge.

Best,
Per Minborg
Oracle Core Libraries
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Liam Miller-Cushon <cushon at google.com>
Sent: Friday, July 18, 2025 7:26 PM
To: OpenJDK Core Libs Developers <core-libs-dev at openjdk.java.net>
Subject: FFM - Optimizing string reads in MemorySegment

Hi,

I have a question about the performance of string reads in MemorySegment.

There was some discussion about reading strings with known lengths in JDK-8333843, and the outcome was to update the getString javadoc to recommend:

byte[] bytes = new byte[length];
MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
return new String(bytes, charset);

As I understand it that's as efficient as what MemorySegment#getString is doing under the hood, the main difference with getString is that it's first reading the length of a null-terminated string, but after that it just uses MemorySegment.copy and calls the String constructor.

Has avoiding the byte[] copy in the String constructor been considered?

In theory it might be possible for the runtime to inline the String constructor, see that the byte[] doesn't escape, and skip the copy. In practice, based on some benchmarking my colleague Louis Wasserman was doing, that doesn't seem to be happening.

Would it make sense to consider using JavaLangAccess#uncheckedNewStringNoRepl here to avoid having to copy the byte[]?

Thanks,
Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250721/75a23eef/attachment.htm>

From rriggs at openjdk.org  Mon Jul 21 15:29:26 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 21 Jul 2025 15:29:26 GMT
Subject: RFR: 8362889: [GCC static analyzer] leak in
 libstringPlatformChars.c
In-Reply-To: <ordEhGmC8cdl8LQKu-tmqNlvKSAK3ek3FUH6TMnpc-M=.b8c73a08-d65d-42ee-82a7-f3a0fd95d4db@github.com>
References: <ordEhGmC8cdl8LQKu-tmqNlvKSAK3ek3FUH6TMnpc-M=.b8c73a08-d65d-42ee-82a7-f3a0fd95d4db@github.com>
Message-ID: <FiYPoe4CTB9_ot0gus8MtEU3EtyepVY3MuOGFGO7-9A=.ddf1b5de-28b4-43e6-b64c-7aafc729b1ff@github.com>

On Mon, 21 Jul 2025 14:12:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> This is reported by the gcc static analyzer (-fanalyzer); it is just test coding so not very critical but probably should still be adjusted .
> 
> 
> /jdk/test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c:74:12: warning: leak of 'str' [CWE-401] [-Wanalyzer-malloc-leak]
>    74 | return JNU_NewStringPlatform(env, str);

test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c line 74:

> 72:     (*env)->ReleasePrimitiveArrayCritical(env, bytes, (void*)jbytes, 0);
> 73: 
> 74:     jstring res = JNU_NewStringPlatform(env, str);

At line 66: where it returns null, it seem like it should also be freeing `str`.  (The analyzer didn't catch that?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26415#discussion_r2219548259

From mbaesken at openjdk.org  Mon Jul 21 15:38:15 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 21 Jul 2025 15:38:15 GMT
Subject: RFR: 8362889: [GCC static analyzer] leak in
 libstringPlatformChars.c [v2]
In-Reply-To: <ordEhGmC8cdl8LQKu-tmqNlvKSAK3ek3FUH6TMnpc-M=.b8c73a08-d65d-42ee-82a7-f3a0fd95d4db@github.com>
References: <ordEhGmC8cdl8LQKu-tmqNlvKSAK3ek3FUH6TMnpc-M=.b8c73a08-d65d-42ee-82a7-f3a0fd95d4db@github.com>
Message-ID: <MefnH6VYego7xUu4r3DviN5ZjY_GGyqogc1P0KzX3ns=.3881767d-2a5d-49ae-9768-e855f1abc69e@github.com>

> This is reported by the gcc static analyzer (-fanalyzer); it is just test coding so not very critical but probably should still be adjusted .
> 
> 
> /jdk/test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c:74:12: warning: leak of 'str' [CWE-401] [-Wanalyzer-malloc-leak]
>    74 | return JNU_NewStringPlatform(env, str);

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

  Another early return needs a free too

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26415/files
  - new: https://git.openjdk.org/jdk/pull/26415/files/7d2eae0b..e2f902f6

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

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

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

From mbaesken at openjdk.org  Mon Jul 21 15:41:24 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 21 Jul 2025 15:41:24 GMT
Subject: RFR: 8362889: [GCC static analyzer] leak in
 libstringPlatformChars.c [v2]
In-Reply-To: <FiYPoe4CTB9_ot0gus8MtEU3EtyepVY3MuOGFGO7-9A=.ddf1b5de-28b4-43e6-b64c-7aafc729b1ff@github.com>
References: <ordEhGmC8cdl8LQKu-tmqNlvKSAK3ek3FUH6TMnpc-M=.b8c73a08-d65d-42ee-82a7-f3a0fd95d4db@github.com>
 <FiYPoe4CTB9_ot0gus8MtEU3EtyepVY3MuOGFGO7-9A=.ddf1b5de-28b4-43e6-b64c-7aafc729b1ff@github.com>
Message-ID: <4N5AG59caGFsuYYcBqot0VhnWpkQ2AbLqTj3Z0qprns=.dad00183-e9e5-4da4-8187-7cfe0eeca693@github.com>

On Mon, 21 Jul 2025 15:27:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Another early return needs a free too
>
> test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c line 74:
> 
>> 72:     (*env)->ReleasePrimitiveArrayCritical(env, bytes, (void*)jbytes, 0);
>> 73: 
>> 74:     jstring res = JNU_NewStringPlatform(env, str);
> 
> At line 66: where it returns null, it seem like it should also be freeing `str`.  (The analyzer didn't catch that?)

It catches that too 

/jdk/test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c:65:8: warning: leak of 'str' [CWE-401] [-Wanalyzer-malloc-leak]
   65 |     if (jbytes == NULL) {


and also


/jdk/test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c:69:16: warning: dereference of possibly-NULL 'str' [CWE-690] [-Wanalyzer-possible-null-dereference]
   69 |         str[i] = (char)jbytes[i];
      |         ~~~~~~~^~~~~~~~~~~~~~~~~


I just overlooked it because a  log of a full build  with '-fanalyzer'  enabled contains quite a lot of output  (the event explanations of every finding are rather long).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26415#discussion_r2219573324

From myankelevich at openjdk.org  Mon Jul 21 15:42:27 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 21 Jul 2025 15:42:27 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v11]
In-Reply-To: <_YafZXn8pIbA-zuOFNN5sVGBM-uKKy47RPhgRod9Tf4=.1927921f-59af-44a2-be6d-18ce70779f51@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <_YafZXn8pIbA-zuOFNN5sVGBM-uKKy47RPhgRod9Tf4=.1927921f-59af-44a2-be6d-18ce70779f51@github.com>
Message-ID: <EgGnsBKXnK2hdKfTx0M2HtRpTMKOcRlEDpmFSwUOF_0=.28fce127-a8da-4cdd-b655-bc96c76a6513@github.com>

On Mon, 21 Jul 2025 13:28:00 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 IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` 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...
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit shifting

Minor: could you please add a bug id to the `@bug` annotations in tests?

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

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3097286276

From cushon at google.com  Mon Jul 21 15:52:23 2025
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 21 Jul 2025 08:52:23 -0700
Subject: FFM - Optimizing string reads in MemorySegment
In-Reply-To: <SA1PR10MB7832CEACC3EBC0517BEDC4DEDA5DA@SA1PR10MB7832.namprd10.prod.outlook.com>
References: <CAL4QsgvQ-O4JeLEjKjZH_p5+SAO5hCWdWJPFtBRDL-r3d_fULA@mail.gmail.com>
 <SA1PR10MB7832CEACC3EBC0517BEDC4DEDA5DA@SA1PR10MB7832.namprd10.prod.outlook.com>
Message-ID: <CAL4Qsgs=Yvh69-C8AYMnLWihJY+9MJYdemkVAke+08X4JT5ozg@mail.gmail.com>

Thank you! I will follow along in the bug.

On Mon, Jul 21, 2025 at 8:02?AM Per-Ake Minborg <per-ake.minborg at oracle.com>
wrote:

> Hi Liam!
>
> Thank you for your comments on MemorySegment::getString !
>
> The intention was that the creation of the intermediate array should be
> elided, but as you point out, that is (at least sometimes) not the case.
> I've made an experimental patch where I've used
> JavaLangAccess::uncheckedNewStringNoRepl in StringSupport which looks
> promising:
>
>
> Base:
> ToJavaStringTest.panama_readString   5 avgt 30 13.559 ? 0.246 ns/op
> ToJavaStringTest.panama_readString  20 avgt 30 67.047 ? 7.541 ns/op <-
> Slow
> ToJavaStringTest.panama_readString 100 avgt 30 28.092 ? 0.547 ns/op
> ToJavaStringTest.panama_readString 200 avgt 30 37.679 ? 0.645 ns/op
> ToJavaStringTest.panama_readString 451 avgt 30 64.544 ? 1.096 ns/op
>
> Experimental Patch:
> ToJavaStringTest.panama_readString   5 avgt 30 8.847 ? 0.178 ns/op
> ToJavaStringTest.panama_readString  20 avgt 30 20.332 ? 4.495 ns/op
> ToJavaStringTest.panama_readString 100 avgt 30 21.808 ? 0.315 ns/op
> ToJavaStringTest.panama_readString 200 avgt 30 28.711 ? 0.105 ns/op
> ToJavaStringTest.panama_readString 451 avgt 30 51.806 ? 1.067 ns/op
>
>
> So, this indicates that there are gains to be made here, although the
> ultimate solution might be something else (such as improving inlining). I
> have raised an issue for this
> <https://bugs.openjdk.org/browse/JDK-8362893>.
>
> Thanks again for bringing this to the general knowledge.
>
> Best,
> Per Minborg
> Oracle Core Libraries
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Liam
> Miller-Cushon <cushon at google.com>
> *Sent:* Friday, July 18, 2025 7:26 PM
> *To:* OpenJDK Core Libs Developers <core-libs-dev at openjdk.java.net>
> *Subject:* FFM - Optimizing string reads in MemorySegment
>
> Hi,
>
> I have a question about the performance of string reads in MemorySegment.
>
> There was some discussion about reading strings with known lengths
> in JDK-8333843, and the outcome was to update the getString javadoc to
> recommend:
>
> byte[] bytes = new byte[length];
> MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length);
> return new String(bytes, charset);
>
> As I understand it that's as efficient as what MemorySegment#getString is
> doing under the hood, the main difference with getString is that it's first
> reading the length of a null-terminated string, but after that it just uses
> MemorySegment.copy and calls the String constructor.
>
> Has avoiding the byte[] copy in the String constructor been considered?
>
> In theory it might be possible for the runtime to inline the String
> constructor, see that the byte[] doesn't escape, and skip the copy. In
> practice, based on some benchmarking my colleague Louis Wasserman was
> doing, that doesn't seem to be happening.
>
> Would it make sense to consider using
> JavaLangAccess#uncheckedNewStringNoRepl here to avoid having to copy the
> byte[]?
>
> Thanks,
> Liam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250721/0a13d4d7/attachment-0001.htm>

From duke at openjdk.org  Mon Jul 21 16:08:32 2025
From: duke at openjdk.org (simon)
Date: Mon, 21 Jul 2025 16:08:32 GMT
Subject: RFR: 8355652: Parse ClassFileFormatVersion from ClassFileVersion
In-Reply-To: <ZC0BL34yfdWC03OXMVCkD0TsgL9XekhDvMvNnxfT7ss=.c024c1bf-728e-4e8c-8a03-4b7fce7edd68@github.com>
References: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
 <9boUuajMR4dXTViK0qwYubQU1_oPAXXZijdQ8K8aTN0=.733c561d-6ea2-4b6c-b7a7-c38c05ca32a8@github.com>
 <DZP8zTjNIbID298YbVbW4f7P-orWDGsASTq9oE7wvPQ=.87eaf865-023a-49db-ac44-06994d67e081@github.com>
 <ZC0BL34yfdWC03OXMVCkD0TsgL9XekhDvMvNnxfT7ss=.c024c1bf-728e-4e8c-8a03-4b7fce7edd68@github.com>
Message-ID: <y2PSOzc2DKWuDN4TXFF5bbvduAhQLGT83jFwaYXrbhs=.57f95d8b-fefd-4c8d-aa4f-b71436a3fd4f@github.com>

On Mon, 21 Jul 2025 02:50:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Do you mean something like this? 
>> 
>> 
>> @Override
>>     public Optional<ClassFileFormatVersion> formatVersion() {
>>         if (majorVersion < 54 || minorVersion != 0) {
>>             return Optional.empty();
>>         }
>>         try {
>>             return Optional.of(ClassFileFormatVersion.fromMajor(majorVersion));
>>         } catch (IllegalArgumentException e) {
>>             return Optional.empty();
>>         }
>>     }
>
> No, this logic is wrong. It's more like the check in https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.base/share/classes/jdk/internal/misc/VM.java#L174-L180
> 
> 
>  public Optional<ClassFileFormatVersion> formatVersion() { 
>      if (majorVersion < ClassFile.JAVA_1_VERSION || majorVersion > ClassFile.latestMajorVersion()) return Optional.empty(); 
>      // for major version is between 45 and 55 inclusive, the minor version may be any value 
>      if (majorVersion >= ClassFile.JAVA_12_VERSION && minorVersion != 0) return Optional.empty(); 
>      // otherwise, only minor version 0 is a defined, persistent format
>      return Optional.of(ClassFileFormatVersion.fromMajor(majorVersion)); 
>  }

Got it. Could you have this hook in a private class method or a static public method? 
Maybe it can be reused in another points?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26406#discussion_r2219638656

From aph at openjdk.org  Mon Jul 21 17:08:31 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 21 Jul 2025 17:08:31 GMT
Subject: Integrated: 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: <baxvkMVm7koFjb5DygrbA_Niddisi-T4-i0SkBgiXQ4=.2cb68941-c45d-4b91-a307-0235e114cb95@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`.

This pull request has now been integrated.

Changeset: 9dd93c6a
Author:    Andrew Haley <aph at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9dd93c6a2c5fb4c3a9f2a063a7ab402f9292ad03
Stats:     100 lines in 2 files changed: 85 ins; 0 del; 15 mod

8361497: Scoped Values: orElse and orElseThrow do not access the cache

Reviewed-by: alanb

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

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

From roger.riggs at oracle.com  Mon Jul 21 17:34:01 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 21 Jul 2025 13:34:01 -0400
Subject: String.charAt vs StringBuilder.charAt performance
In-Reply-To: <CANBJVOFUEEt1GdM59D27cXbEzG9ZZZaafPsJqt6uQ+gwjruVKw@mail.gmail.com>
References: <CANBJVOHxaDv5q3GJPX8dn2GepcU9de39phavquaxKNXGZrMRrA@mail.gmail.com>
 <CABe8uE0UJ_=Vb842cTTnE4tuGPWDMKDb0bkD9CCvqNKQfXF20Q@mail.gmail.com>
 <CANBJVOFUEEt1GdM59D27cXbEzG9ZZZaafPsJqt6uQ+gwjruVKw@mail.gmail.com>
Message-ID: <fd0e5706-7c69-42e1-8b58-da5281569cda@oracle.com>

Hi Brett,

The labeling of the output is confusing, the test output labeled as 
StringBuffer but the jmh creates StringBuilder.
(StringBuffer methods are all synchronized and could explain why they 
are slower).

Also, I would not be surprised that C2 has more optimizations for String 
than for StringBuilder.

Regards, Roger

On 7/19/25 6:09 PM, Brett Okken wrote:
> Making sequence a local variable does improve things (especially for 
> ascii), but a substantial difference remains. It appears that the 
> performance difference for ascii goes all the way back to jdk 11. The 
> difference for non-ascii showed up in jdk 21. I wonder if this is 
> related to the index checks?
>
> jdk 11
>
> Benchmark ?(data) ? ? ?(source) ?Mode ?Cnt ? ? Score ?Error ?Units
> test ? ? ? ?ascii ? ? ? ?String ?avgt ? ?3 ?1137.348 ? 12.835 ?ns/op
> test ? ? ? ?ascii ?StringBuffer ?avgt ? ?3 ? 712.874 ? ?509.320 ?ns/op
> test ? ?non-ascii ? ? ? ?String ?avgt ? ?3 ? 668.657 ? ?246.550 ?ns/op
> test ? ?non-ascii ?StringBuffer ?avgt ? ?3 ? 897.344 ? 4353.414 ?ns/op
>
>
> jdk 17
> Benchmark ?(data) ? ? ?(source) ?Mode ?Cnt ? ? Score ?Error ?Units
> test ? ? ? ?ascii ? ? ? ?String ?avgt ? ?3 ?1321.497 ? 2107.466 ?ns/op
> test ? ? ? ?ascii ?StringBuffer ?avgt ? ?3 ? 715.936 ? ?412.189 ?ns/op
> test ? ?non-ascii ? ? ? ?String ?avgt ? ?3 ? 722.986 ? ?443.389 ?ns/op
> test ? ?non-ascii ?StringBuffer ?avgt ? ?3 ? 722.787 ? ?771.816 ?ns/op
>
>
> jdk 21
> Benchmark ?(data) ? ? ?(source) ?Mode ?Cnt ? ? Score Error ?Units
> test ? ? ? ?ascii ? ? ? ?String ?avgt ? ?3 ?1150.301 ?? 918.549 ?ns/op
> test ? ? ? ?ascii ?StringBuffer ?avgt ? ?3 ? 713.183 ?? 543.850 ?ns/op
> test ? ?non-ascii ? ? ? ?String ?avgt ? ?3 ?4642.667 ?? 11481.029 ?ns/op
> test ? ?non-ascii ?StringBuffer ?avgt ? ?3 ? 728.027 ?? 936.521 ?ns/op
>
>
> jdk 25
> Benchmark ?(data) ? ? ?(source) ?Mode ?Cnt ? ? Score ?Error ?Units
> test ? ? ? ?ascii ? ? ? ?String ?avgt ? ?3 ?1184.513 ?? 2057.498 ?ns/op
> test ? ? ? ?ascii ?StringBuffer ?avgt ? ?3 ? 786.611 ?? ?411.657 ?ns/op
> test ? ?non-ascii ? ? ? ?String ?avgt ? ?3 ?4197.585 ?? 2761.388 ?ns/op
> test ? ?non-ascii ?StringBuffer ?avgt ? ?3 ? 716.375 ?? ?815.349 ?ns/op
>
>
> jdk 26
> Benchmark ?(data) ? ? ?(source) ?Mode ?Cnt ? ? Score ? ? Error ?Units
> test ? ? ? ?ascii ? ? ? ?String ?avgt ? ?3 ?1107.207 ?? 423.072 ?ns/op
> test ? ? ? ?ascii ?StringBuffer ?avgt ? ?3 ? 742.780 ?? 178.890 ?ns/op
> test ? ?non-ascii ? ? ? ?String ?avgt ? ?3 ?4043.914 ?? 498.439 ?ns/op
> test ? ?non-ascii ?StringBuffer ?avgt ? ?3 ? 712.535 ?? 583.255 ?ns/op
>
>
> On Sat, Jul 19, 2025 at 4:17?PM Chen Liang <liangchenblue at gmail.com> 
> wrote:
>
>     Without looking at C2 IRs, I think there are a few potential
>     culprits we can look into:
>     1. JDK-8351000 and JDK-8351443 updated StringBuilder
>     2. Sequence field is read in the loop; I wonder if making it an
>     explicit immutable local variable changes anything here.
>
>     On Sat, Jul 19, 2025 at 2:34?PM Brett Okken
>     <brett.okken.os at gmail.com> wrote:
>
>         I was looking at the performance of StringCharBuffer for various
>         backing CharSequence types and was surprised to see a significant
>         performance difference between String and StringBuffer. I wrote a
>         small jmh which shows that the String implementation of charAt is
>         significantly slower than StringBuilder. Is this expected?
>
>         Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? (data) (source)? Mode? Cnt
>         ? Score? ? ? ?Error? Units
>         CharSequenceCharAtBenchmark.test? ? ? ascii String? avgt? ? 3
>         2537.311 ??? 8952.197? ns/op
>         CharSequenceCharAtBenchmark.test? ? ? ascii StringBuffer?
>         avgt? ? 3
>         852.004 ??? 2532.958? ns/op
>         CharSequenceCharAtBenchmark.test? non-ascii String? avgt? ? 3
>         5115.381 ?? 13822.592? ns/op
>         CharSequenceCharAtBenchmark.test? non-ascii StringBuffer?
>         avgt? ? 3
>         836.230 ??? 1154.191? ns/op
>
>
>
>         @Measurement(iterations = 3, time = 5, timeUnit =
>         TimeUnit.SECONDS)
>         @Warmup(iterations = 2, time = 7, timeUnit = TimeUnit.SECONDS)
>         @BenchmarkMode(Mode.AverageTime)
>         @OutputTimeUnit(TimeUnit.NANOSECONDS)
>         @State(Scope.Benchmark)
>         @Fork(value = 1, jvmArgsPrepend = {"-Xms512M", "-Xmx512M"})
>         public class CharSequenceCharAtBenchmark {
>
>         ? ? @Param(value = {"ascii", "non-ascii"})
>         ? ? public String data;
>
>         ? ? @Param(value = {"String", "StringBuffer"})
>         ? ? public String source;
>
>         ? ? private CharSequence sequence;
>
>         ? ? @Setup(Level.Trial)
>         ? ? public void setup() throws Exception {
>         ? ? ? ? StringBuilder sb = new StringBuilder(3152);
>         ? ? ? ? for (int i=0; i<3152; ++i) {
>         ? ? ? ? ? ? char c = (char) i;
>         ? ? ? ? ? ? if ("ascii".equals(data)) {
>         ? ? ? ? ? ? ? ? c = (char) (i & 0x7f);
>         ? ? ? ? ? ? }
>         ? ? ? ? ? ? sb.append(c);
>         ? ? ? ? }
>
>         ? ? ? ? switch(source) {
>         ? ? ? ? ? ? case "String":
>         ? ? ? ? ? ? ? ? sequence = sb.toString();
>         ? ? ? ? ? ? ? ? break;
>         ? ? ? ? ? ? case "StringBuffer":
>         ? ? ? ? ? ? ? ? sequence = sb;
>         ? ? ? ? ? ? ? ? break;
>         ? ? ? ? ? ? default:
>         ? ? ? ? ? ? ? ? throw new IllegalArgumentException(source);
>         ? ? ? ? }
>         ? ? }
>
>         ? ? @Benchmark
>         ? ? public int test() {
>         ? ? ? ? int sum = 0;
>         ? ? ? ? for (int i=0, j=sequence.length(); i<j; ++i) {
>         ? ? ? ? ? ? sum += sequence.charAt(i);
>         ? ? ? ? }
>         ? ? ? ? return sum;
>         ? ? }
>         }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250721/c9ef582b/attachment-0001.htm>

From brett.okken.os at gmail.com  Mon Jul 21 17:43:51 2025
From: brett.okken.os at gmail.com (Brett Okken)
Date: Mon, 21 Jul 2025 12:43:51 -0500
Subject: String.charAt vs StringBuilder.charAt performance
In-Reply-To: <fd0e5706-7c69-42e1-8b58-da5281569cda@oracle.com>
References: <CANBJVOHxaDv5q3GJPX8dn2GepcU9de39phavquaxKNXGZrMRrA@mail.gmail.com>
 <CABe8uE0UJ_=Vb842cTTnE4tuGPWDMKDb0bkD9CCvqNKQfXF20Q@mail.gmail.com>
 <CANBJVOFUEEt1GdM59D27cXbEzG9ZZZaafPsJqt6uQ+gwjruVKw@mail.gmail.com>
 <fd0e5706-7c69-42e1-8b58-da5281569cda@oracle.com>
Message-ID: <CANBJVOHbJxR9TCLW4OWuN2uMP4TN-ZKhJTvOwZeUvXYQOv0j6g@mail.gmail.com>

>  output labeled as StringBuffer but the jmh creates StringBuilder.

Ugh - sorry about that. But yes - this is about StringBuilder vs String.

> I would not be surprised that C2 has more optimizations for String than
for StringBuilder.

If that were true, it would not surprise me. However, these tests show the
opposite. String is /slower/ than StringBuilder.

On Mon, Jul 21, 2025 at 12:34?PM Roger Riggs <roger.riggs at oracle.com> wrote:

> Hi Brett,
>
> The labeling of the output is confusing, the test output labeled as
> StringBuffer but the jmh creates StringBuilder.
> (StringBuffer methods are all synchronized and could explain why they are
> slower).
>
> Also, I would not be surprised that C2 has more optimizations for String
> than for StringBuilder.
>
> Regards, Roger
>
> On 7/19/25 6:09 PM, Brett Okken wrote:
>
> Making sequence a local variable does improve things (especially for
> ascii), but a substantial difference remains. It appears that the
> performance difference for ascii goes all the way back to jdk 11. The
> difference for non-ascii showed up in jdk 21. I wonder if this is related
> to the index checks?
>
> jdk 11
>
> Benchmark  (data)      (source)  Mode  Cnt     Score      Error  Units
> test        ascii        String  avgt    3  1137.348 ?   12.835  ns/op
> test        ascii  StringBuffer  avgt    3   712.874 ?  509.320  ns/op
> test    non-ascii        String  avgt    3   668.657 ?  246.550  ns/op
> test    non-ascii  StringBuffer  avgt    3   897.344 ? 4353.414  ns/op
>
>
> jdk 17
> Benchmark  (data)      (source)  Mode  Cnt     Score      Error  Units
> test        ascii        String  avgt    3  1321.497 ? 2107.466  ns/op
> test        ascii  StringBuffer  avgt    3   715.936 ?  412.189  ns/op
> test    non-ascii        String  avgt    3   722.986 ?  443.389  ns/op
> test    non-ascii  StringBuffer  avgt    3   722.787 ?  771.816  ns/op
>
>
> jdk 21
> Benchmark  (data)      (source)  Mode  Cnt     Score       Error  Units
> test        ascii        String  avgt    3  1150.301 ??   918.549  ns/op
> test        ascii  StringBuffer  avgt    3   713.183 ??   543.850  ns/op
> test    non-ascii        String  avgt    3  4642.667 ?? 11481.029  ns/op
> test    non-ascii  StringBuffer  avgt    3   728.027 ??   936.521  ns/op
>
>
> jdk 25
> Benchmark  (data)      (source)  Mode  Cnt     Score      Error  Units
> test        ascii        String  avgt    3  1184.513 ?? 2057.498  ns/op
> test        ascii  StringBuffer  avgt    3   786.611 ??  411.657  ns/op
> test    non-ascii        String  avgt    3  4197.585 ?? 2761.388  ns/op
> test    non-ascii  StringBuffer  avgt    3   716.375 ??  815.349  ns/op
>
>
> jdk 26
> Benchmark  (data)      (source)  Mode  Cnt     Score     Error  Units
> test        ascii        String  avgt    3  1107.207 ?? 423.072  ns/op
> test        ascii  StringBuffer  avgt    3   742.780 ?? 178.890  ns/op
> test    non-ascii        String  avgt    3  4043.914 ?? 498.439  ns/op
> test    non-ascii  StringBuffer  avgt    3   712.535 ?? 583.255  ns/op
>
>
> On Sat, Jul 19, 2025 at 4:17?PM Chen Liang <liangchenblue at gmail.com>
> wrote:
>
>> Without looking at C2 IRs, I think there are a few potential culprits we
>> can look into:
>> 1. JDK-8351000 and JDK-8351443 updated StringBuilder
>> 2. Sequence field is read in the loop; I wonder if making it an explicit
>> immutable local variable changes anything here.
>>
>> On Sat, Jul 19, 2025 at 2:34?PM Brett Okken <brett.okken.os at gmail.com>
>> wrote:
>>
>>> I was looking at the performance of StringCharBuffer for various
>>> backing CharSequence types and was surprised to see a significant
>>> performance difference between String and StringBuffer. I wrote a
>>> small jmh which shows that the String implementation of charAt is
>>> significantly slower than StringBuilder. Is this expected?
>>>
>>> Benchmark                            (data)      (source)  Mode  Cnt
>>>   Score       Error  Units
>>> CharSequenceCharAtBenchmark.test      ascii        String  avgt    3
>>> 2537.311 ??  8952.197  ns/op
>>> CharSequenceCharAtBenchmark.test      ascii  StringBuffer  avgt    3
>>> 852.004 ??  2532.958  ns/op
>>> CharSequenceCharAtBenchmark.test  non-ascii        String  avgt    3
>>> 5115.381 ?? 13822.592  ns/op
>>> CharSequenceCharAtBenchmark.test  non-ascii  StringBuffer  avgt    3
>>> 836.230 ??  1154.191  ns/op
>>>
>>>
>>>
>>> @Measurement(iterations = 3, time = 5, timeUnit = TimeUnit.SECONDS)
>>> @Warmup(iterations = 2, time = 7, timeUnit = TimeUnit.SECONDS)
>>> @BenchmarkMode(Mode.AverageTime)
>>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>>> @State(Scope.Benchmark)
>>> @Fork(value = 1, jvmArgsPrepend = {"-Xms512M", "-Xmx512M"})
>>> public class CharSequenceCharAtBenchmark {
>>>
>>>     @Param(value = {"ascii", "non-ascii"})
>>>     public String data;
>>>
>>>     @Param(value = {"String", "StringBuffer"})
>>>     public String source;
>>>
>>>     private CharSequence sequence;
>>>
>>>     @Setup(Level.Trial)
>>>     public void setup() throws Exception {
>>>         StringBuilder sb = new StringBuilder(3152);
>>>         for (int i=0; i<3152; ++i) {
>>>             char c = (char) i;
>>>             if ("ascii".equals(data)) {
>>>                 c = (char) (i & 0x7f);
>>>             }
>>>             sb.append(c);
>>>         }
>>>
>>>         switch(source) {
>>>             case "String":
>>>                 sequence = sb.toString();
>>>                 break;
>>>             case "StringBuffer":
>>>                 sequence = sb;
>>>                 break;
>>>             default:
>>>                 throw new IllegalArgumentException(source);
>>>         }
>>>     }
>>>
>>>     @Benchmark
>>>     public int test() {
>>>         int sum = 0;
>>>         for (int i=0, j=sequence.length(); i<j; ++i) {
>>>             sum += sequence.charAt(i);
>>>         }
>>>         return sum;
>>>     }
>>> }
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250721/61654ce0/attachment.htm>

From coleenp at openjdk.org  Mon Jul 21 17:54:24 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 21 Jul 2025 17:54:24 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
In-Reply-To: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
Message-ID: <IBwASkspBPB4VCKVx3quHUdWnvtQskrSg5oT3k5qCXg=.9c1fc78b-853b-4bd7-8072-b668c1a87295@github.com>

On Wed, 2 Jul 2025 00:18:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

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

The code looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26082#pullrequestreview-3039130102

From coleenp at openjdk.org  Mon Jul 21 17:54:25 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 21 Jul 2025 17:54:25 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
In-Reply-To: <dwrToo7aFLg6SgqDSaYQkYvh-TPXWND7wZacVfp2QAY=.8420ecbe-362b-46a6-b583-4e5497b3c287@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
 <aTs018gQ4ULkVAXdGUZiX-g7gKJkHEbMjKCob8i9FYA=.208a442c-52dc-4569-9c27-596fd1f94121@github.com>
 <I6QtmOydf5-vfixmLTwYX2aO6cEM_GUjNaxnAELfFDs=.4ffabffc-a01a-4d7e-8b3a-26deac5120c6@github.com>
 <dwrToo7aFLg6SgqDSaYQkYvh-TPXWND7wZacVfp2QAY=.8420ecbe-362b-46a6-b583-4e5497b3c287@github.com>
Message-ID: <LEX_cIXqhLxxC2bGMRe1QT9qajhG6QzMY2UGUw3jCiI=.743b0785-0447-431c-8bac-595fa4d3123d@github.com>

On Thu, 17 Jul 2025 22:41:34 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> If you're storing the unnamed module oop in the archive should this method not be called?  If it is, what are you saving by archiving the unnamed module?
>
> The callstack is:
> 
> 
> jdk.internal.loader.BootLoader.setBootLoaderUnnamedModule0(java.base at 26-internal/Native Method)
> jdk.internal.loader.BootLoader.<clinit>(java.base at 26-internal/BootLoader.java:71)
> jdk.internal.module.ModuleBootstrap.boot(java.base at 26-internal/ModuleBootstrap.java:162)
> java.lang.System.initPhase2(java.base at 26-internal/System.java:1932)
> 
> 
> Both the Java code and the native code have a handle to this unnamed module oop. The `precond` checks that they indeed are pointing the same oop.
> 
> Also, even though the oop is archived, we still need to set up some native states inside the `unnamed_module->restore_archived_oops(boot_loader_data)` call. E.g., set up the `OopHandle` that binds the oop to the `ModuleEntry`.
> 
> ---------------
>> what are you saving by archiving the unnamed module?
> 
> It's for [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550)) -- I want to be able to reference the unnamed module before executing any Java code, so that archived classes can be loaded at the very beginning of `vmClasses::resolve_all()`. See my draft PR: https://github.com/openjdk/jdk/pull/26375
> 
> ---------------
> Currently, we still execute a lot of Java code when setting up the archived module graph (inside `ModuleBootstrap.boot()`. I am working on a way to enable the archived module graph without executing any Java code (which will be a few REFs after [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550)), so this call will eventually be gone.

Ok, I see.  At this point, you're just checking that what you've referred to before loading the unnamed module matches what you've previously saved in the shared archive. Did I get that right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26082#discussion_r2219870762

From duke at openjdk.org  Mon Jul 21 18:09:48 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 21 Jul 2025 18:09:48 GMT
Subject: RFR: 8077587: BigInteger Roots [v31]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <SJg3bwGu3xHmCYv45nUIUkmU8VG-pnkqKEMSa2BwkMg=.ce1780d4-4038-450c-8225-10cec1024de6@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

  Added tests for nth root

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/5107ac2e..68525801

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=29-30

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

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

From roger.riggs at oracle.com  Mon Jul 21 18:11:58 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 21 Jul 2025 14:11:58 -0400
Subject: String.charAt vs StringBuilder.charAt performance
In-Reply-To: <CANBJVOHbJxR9TCLW4OWuN2uMP4TN-ZKhJTvOwZeUvXYQOv0j6g@mail.gmail.com>
References: <CANBJVOHxaDv5q3GJPX8dn2GepcU9de39phavquaxKNXGZrMRrA@mail.gmail.com>
 <CABe8uE0UJ_=Vb842cTTnE4tuGPWDMKDb0bkD9CCvqNKQfXF20Q@mail.gmail.com>
 <CANBJVOFUEEt1GdM59D27cXbEzG9ZZZaafPsJqt6uQ+gwjruVKw@mail.gmail.com>
 <fd0e5706-7c69-42e1-8b58-da5281569cda@oracle.com>
 <CANBJVOHbJxR9TCLW4OWuN2uMP4TN-ZKhJTvOwZeUvXYQOv0j6g@mail.gmail.com>
Message-ID: <b443c697-c396-4bb4-8fb2-50304491dc58@oracle.com>

Hi Brett,

I'd suggest separate initialization and test methods for the two cases 
to get more reliable numbers.

By using @Trial and using a common field for the test data, I think you 
have handicapped C2.
The training runs JMH does to warm up C2 are 'seeing' two different 
types for the value of sequence.
Making the test runs independent will remov doubt about interactions due 
to the test setup.

Roger

On 7/21/25 1:43 PM, Brett Okken wrote:
> > output labeled as StringBuffer but the jmh creates StringBuilder.
>
> Ugh - sorry about that. But yes - this is about StringBuilder vs String.
>
> > I would not be surprised that C2 has more optimizations for String 
> than for StringBuilder.
>
> If that were true, it would not surprise me. However, these tests show 
> the opposite. String is /slower/ than StringBuilder.
>
> On Mon, Jul 21, 2025 at 12:34?PM Roger Riggs <roger.riggs at oracle.com> 
> wrote:
>
>     Hi Brett,
>
>     The labeling of the output is confusing, the test output labeled
>     as StringBuffer but the jmh creates StringBuilder.
>     (StringBuffer methods are all synchronized and could explain why
>     they are slower).
>
>     Also, I would not be surprised that C2 has more optimizations for
>     String than for StringBuilder.
>
>     Regards, Roger
>
>     On 7/19/25 6:09 PM, Brett Okken wrote:
>>     Making sequence a local variable does improve things (especially
>>     for ascii), but a substantial difference remains. It appears that
>>     the performance difference for ascii goes all the way back to jdk
>>     11. The difference for non-ascii showed up in jdk 21. I wonder if
>>     this is related to the index checks?
>>
>>     jdk 11
>>
>>     Benchmark ?(data) ? ? ?(source) ?Mode ?Cnt ? ? Score ? ?Error ?Units
>>     test ? ? ? ?ascii ? ? ? ?String ?avgt ? ?3 ?1137.348 ? ? 12.835
>>     ?ns/op
>>     test ? ? ? ?ascii ?StringBuffer ?avgt ? ?3 ? 712.874 ? ?509.320
>>     ?ns/op
>>     test ? ?non-ascii ? ? ? ?String ?avgt ? ?3 ? 668.657 ? ?246.550
>>     ?ns/op
>>     test ? ?non-ascii ?StringBuffer ?avgt ? ?3 ? 897.344 ? 4353.414
>>     ?ns/op
>>
>>
>>     jdk 17
>>     Benchmark ?(data) ? ? ?(source) ?Mode ?Cnt ? ? Score ? ?Error ?Units
>>     test ? ? ? ?ascii ? ? ? ?String ?avgt ? ?3 ?1321.497 ? 2107.466
>>     ?ns/op
>>     test ? ? ? ?ascii ?StringBuffer ?avgt ? ?3 ? 715.936 ? ?412.189
>>     ?ns/op
>>     test ? ?non-ascii ? ? ? ?String ?avgt ? ?3 ? 722.986 ? ?443.389
>>     ?ns/op
>>     test ? ?non-ascii ?StringBuffer ?avgt ? ?3 ? 722.787 ? ?771.816
>>     ?ns/op
>>
>>
>>     jdk 21
>>     Benchmark ?(data) ? ? ?(source) ?Mode ?Cnt ? ? Score ? ? Error ?Units
>>     test ? ? ? ?ascii ? ? ? ?String ?avgt ? ?3 ?1150.301 ?? ? 918.549
>>     ?ns/op
>>     test ? ? ? ?ascii ?StringBuffer ?avgt ? ?3 ? 713.183 ?? ? 543.850
>>     ?ns/op
>>     test ? ?non-ascii ? ? ? ?String ?avgt ? ?3 ?4642.667 ?? 11481.029
>>     ?ns/op
>>     test ? ?non-ascii ?StringBuffer ?avgt ? ?3 ? 728.027 ?? ? 936.521
>>     ?ns/op
>>
>>
>>     jdk 25
>>     Benchmark ?(data) ? ? ?(source) ?Mode ?Cnt ? ? Score ? ?Error ?Units
>>     test ? ? ? ?ascii ? ? ? ?String ?avgt ? ?3 ?1184.513 ?? 2057.498
>>     ?ns/op
>>     test ? ? ? ?ascii ?StringBuffer ?avgt ? ?3 ? 786.611 ?? ?411.657
>>     ?ns/op
>>     test ? ?non-ascii ? ? ? ?String ?avgt ? ?3 ?4197.585 ?? 2761.388
>>     ?ns/op
>>     test ? ?non-ascii ?StringBuffer ?avgt ? ?3 ? 716.375 ?? ?815.349
>>     ?ns/op
>>
>>
>>     jdk 26
>>     Benchmark ?(data) ? ? ?(source) ?Mode ?Cnt ? ? Score ? Error ?Units
>>     test ? ? ? ?ascii ? ? ? ?String ?avgt ? ?3 ?1107.207 ?? 423.072
>>     ?ns/op
>>     test ? ? ? ?ascii ?StringBuffer ?avgt ? ?3 ? 742.780 ?? 178.890
>>     ?ns/op
>>     test ? ?non-ascii ? ? ? ?String ?avgt ? ?3 ?4043.914 ?? 498.439
>>     ?ns/op
>>     test ? ?non-ascii ?StringBuffer ?avgt ? ?3 ? 712.535 ?? 583.255
>>     ?ns/op
>>
>>
>>     On Sat, Jul 19, 2025 at 4:17?PM Chen Liang
>>     <liangchenblue at gmail.com> wrote:
>>
>>         Without looking at C2 IRs, I think there are a few potential
>>         culprits we can look into:
>>         1. JDK-8351000 and JDK-8351443 updated StringBuilder
>>         2. Sequence field is read in the loop; I wonder if making it
>>         an explicit immutable local variable changes anything here.
>>
>>         On Sat, Jul 19, 2025 at 2:34?PM Brett Okken
>>         <brett.okken.os at gmail.com> wrote:
>>
>>             I was looking at the performance of StringCharBuffer for
>>             various
>>             backing CharSequence types and was surprised to see a
>>             significant
>>             performance difference between String and StringBuffer. I
>>             wrote a
>>             small jmh which shows that the String implementation of
>>             charAt is
>>             significantly slower than StringBuilder. Is this expected?
>>
>>             Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? (data) (source)?
>>             Mode? Cnt
>>             ? Score? ? ? ?Error? Units
>>             CharSequenceCharAtBenchmark.test? ? ? ascii ? String?
>>             avgt? ? 3
>>             2537.311 ??? 8952.197? ns/op
>>             CharSequenceCharAtBenchmark.test? ? ? ascii StringBuffer?
>>             avgt? ? 3
>>             852.004 ??? 2532.958? ns/op
>>             CharSequenceCharAtBenchmark.test? non-ascii ? String?
>>             avgt? ? 3
>>             5115.381 ?? 13822.592? ns/op
>>             CharSequenceCharAtBenchmark.test? non-ascii StringBuffer?
>>             avgt? ? 3
>>             836.230 ??? 1154.191? ns/op
>>
>>
>>
>>             @Measurement(iterations = 3, time = 5, timeUnit =
>>             TimeUnit.SECONDS)
>>             @Warmup(iterations = 2, time = 7, timeUnit =
>>             TimeUnit.SECONDS)
>>             @BenchmarkMode(Mode.AverageTime)
>>             @OutputTimeUnit(TimeUnit.NANOSECONDS)
>>             @State(Scope.Benchmark)
>>             @Fork(value = 1, jvmArgsPrepend = {"-Xms512M", "-Xmx512M"})
>>             public class CharSequenceCharAtBenchmark {
>>
>>             ? ? @Param(value = {"ascii", "non-ascii"})
>>             ? ? public String data;
>>
>>             ? ? @Param(value = {"String", "StringBuffer"})
>>             ? ? public String source;
>>
>>             ? ? private CharSequence sequence;
>>
>>             ? ? @Setup(Level.Trial)
>>             ? ? public void setup() throws Exception {
>>             ? ? ? ? StringBuilder sb = new StringBuilder(3152);
>>             ? ? ? ? for (int i=0; i<3152; ++i) {
>>             ? ? ? ? ? ? char c = (char) i;
>>             ? ? ? ? ? ? if ("ascii".equals(data)) {
>>             ? ? ? ? ? ? ? ? c = (char) (i & 0x7f);
>>             ? ? ? ? ? ? }
>>             ? ? ? ? ? ? sb.append(c);
>>             ? ? ? ? }
>>
>>             ? ? ? ? switch(source) {
>>             ? ? ? ? ? ? case "String":
>>             ? ? ? ? ? ? ? ? sequence = sb.toString();
>>             ? ? ? ? ? ? ? ? break;
>>             ? ? ? ? ? ? case "StringBuffer":
>>             ? ? ? ? ? ? ? ? sequence = sb;
>>             ? ? ? ? ? ? ? ? break;
>>             ? ? ? ? ? ? default:
>>             ? ? ? ? ? ? ? ? throw new IllegalArgumentException(source);
>>             ? ? ? ? }
>>             ? ? }
>>
>>             ? ? @Benchmark
>>             ? ? public int test() {
>>             ? ? ? ? int sum = 0;
>>             ? ? ? ? for (int i=0, j=sequence.length(); i<j; ++i) {
>>             ? ? ? ? ? ? sum += sequence.charAt(i);
>>             ? ? ? ? }
>>             ? ? ? ? return sum;
>>             ? ? }
>>             }
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250721/b89346f1/attachment-0001.htm>

From iklam at openjdk.org  Mon Jul 21 18:18:24 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Jul 2025 18:18:24 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
In-Reply-To: <LEX_cIXqhLxxC2bGMRe1QT9qajhG6QzMY2UGUw3jCiI=.743b0785-0447-431c-8bac-595fa4d3123d@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
 <aTs018gQ4ULkVAXdGUZiX-g7gKJkHEbMjKCob8i9FYA=.208a442c-52dc-4569-9c27-596fd1f94121@github.com>
 <I6QtmOydf5-vfixmLTwYX2aO6cEM_GUjNaxnAELfFDs=.4ffabffc-a01a-4d7e-8b3a-26deac5120c6@github.com>
 <dwrToo7aFLg6SgqDSaYQkYvh-TPXWND7wZacVfp2QAY=.8420ecbe-362b-46a6-b583-4e5497b3c287@github.com>
 <LEX_cIXqhLxxC2bGMRe1QT9qajhG6QzMY2UGUw3jCiI=.743b0785-0447-431c-8bac-595fa4d3123d@github.com>
Message-ID: <wcF3RwW9zi2dIkWfQq3JvpPNBtz0cLmxIF3sMnCxLSM=.baa296e9-2cc8-4fd6-a3d7-adee30ead821@github.com>

On Mon, 21 Jul 2025 17:51:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The callstack is:
>> 
>> 
>> jdk.internal.loader.BootLoader.setBootLoaderUnnamedModule0(java.base at 26-internal/Native Method)
>> jdk.internal.loader.BootLoader.<clinit>(java.base at 26-internal/BootLoader.java:71)
>> jdk.internal.module.ModuleBootstrap.boot(java.base at 26-internal/ModuleBootstrap.java:162)
>> java.lang.System.initPhase2(java.base at 26-internal/System.java:1932)
>> 
>> 
>> Both the Java code and the native code have a handle to this unnamed module oop. The `precond` checks that they indeed are pointing the same oop.
>> 
>> Also, even though the oop is archived, we still need to set up some native states inside the `unnamed_module->restore_archived_oops(boot_loader_data)` call. E.g., set up the `OopHandle` that binds the oop to the `ModuleEntry`.
>> 
>> ---------------
>>> what are you saving by archiving the unnamed module?
>> 
>> It's for [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550)) -- I want to be able to reference the unnamed module before executing any Java code, so that archived classes can be loaded at the very beginning of `vmClasses::resolve_all()`. See my draft PR: https://github.com/openjdk/jdk/pull/26375
>> 
>> ---------------
>> Currently, we still execute a lot of Java code when setting up the archived module graph (inside `ModuleBootstrap.boot()`. I am working on a way to enable the archived module graph without executing any Java code (which will be a few REFs after [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550)), so this call will eventually be gone.
>
> Ok, I see.  At this point, you're just checking that what you've referred to before loading the unnamed module matches what you've previously saved in the shared archive. Did I get that right?

Yes, it's checking that the Java and C++ code both found the same archived unnamed module.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26082#discussion_r2219925684

From liach at openjdk.org  Mon Jul 21 20:47:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Jul 2025 20:47:25 GMT
Subject: RFR: 8355652: Parse ClassFileFormatVersion from ClassFileVersion
In-Reply-To: <y2PSOzc2DKWuDN4TXFF5bbvduAhQLGT83jFwaYXrbhs=.57f95d8b-fefd-4c8d-aa4f-b71436a3fd4f@github.com>
References: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
 <9boUuajMR4dXTViK0qwYubQU1_oPAXXZijdQ8K8aTN0=.733c561d-6ea2-4b6c-b7a7-c38c05ca32a8@github.com>
 <DZP8zTjNIbID298YbVbW4f7P-orWDGsASTq9oE7wvPQ=.87eaf865-023a-49db-ac44-06994d67e081@github.com>
 <ZC0BL34yfdWC03OXMVCkD0TsgL9XekhDvMvNnxfT7ss=.c024c1bf-728e-4e8c-8a03-4b7fce7edd68@github.com>
 <y2PSOzc2DKWuDN4TXFF5bbvduAhQLGT83jFwaYXrbhs=.57f95d8b-fefd-4c8d-aa4f-b71436a3fd4f@github.com>
Message-ID: <eOD0d9mOjG8LDevyE4mKTi-8-1u6d1K0Dr2QTbX9dGg=.445fe1c0-644a-4e44-8397-dd889c6e43a3@github.com>

On Mon, 21 Jul 2025 16:05:59 GMT, simon <duke at openjdk.org> wrote:

> Maybe it can be reused in another points?

ClassFileFormatVersion and Optional are more user-oriented classes; internal code don't really ever use these two types, so I don't think you need to extract this logic specifically.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26406#discussion_r2220284604

From duke at openjdk.org  Mon Jul 21 20:57:03 2025
From: duke at openjdk.org (simon)
Date: Mon, 21 Jul 2025 20:57:03 GMT
Subject: RFR: 8355652: Parse ClassFileFormatVersion from ClassFileVersion
 [v2]
In-Reply-To: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
References: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
Message-ID: <d4eKNq628qw6wxeZxmhH8zeOb78fV0Y4C3U6eLyOFF0=.80069f4b-5d44-493b-99c7-b3e5170a788e@github.com>

> 8355652: add new method to return ClassFileFormatVersion from ClassFileVersion.
> ---------
> ### 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/26406/head:pull/26406` \
> `$ git checkout pull/26406`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/26406` \
> `$ git pull https://git.openjdk.org/jdk.git pull/26406/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 26406`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 26406`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/26406.diff">https://git.openjdk.org/jdk/pull/26406.diff</a>
> 
> </details>
> <details><summary>Using Webrev</summary>
> 
> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/26406#issuecomment-3094832141)
> </details>

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

 - 8355652: update copyright year to 2025 in ClassFileVersionImpl.java
 - 8355652: update copyright year to 2025 in ClassFileVersionImpl.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26406/files
  - new: https://git.openjdk.org/jdk/pull/26406/files/ab67e498..d4ff0b6d

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

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

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

From duke at openjdk.org  Mon Jul 21 20:57:03 2025
From: duke at openjdk.org (simon)
Date: Mon, 21 Jul 2025 20:57:03 GMT
Subject: RFR: 8355652: Parse ClassFileFormatVersion from ClassFileVersion
 [v2]
In-Reply-To: <eOD0d9mOjG8LDevyE4mKTi-8-1u6d1K0Dr2QTbX9dGg=.445fe1c0-644a-4e44-8397-dd889c6e43a3@github.com>
References: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
 <9boUuajMR4dXTViK0qwYubQU1_oPAXXZijdQ8K8aTN0=.733c561d-6ea2-4b6c-b7a7-c38c05ca32a8@github.com>
 <DZP8zTjNIbID298YbVbW4f7P-orWDGsASTq9oE7wvPQ=.87eaf865-023a-49db-ac44-06994d67e081@github.com>
 <ZC0BL34yfdWC03OXMVCkD0TsgL9XekhDvMvNnxfT7ss=.c024c1bf-728e-4e8c-8a03-4b7fce7edd68@github.com>
 <y2PSOzc2DKWuDN4TXFF5bbvduAhQLGT83jFwaYXrbhs=.57f95d8b-fefd-4c8d-aa4f-b71436a3fd4f@github.com>
 <eOD0d9mOjG8LDevyE4mKTi-8-1u6d1K0Dr2QTbX9dGg=.445fe1c0-644a-4e44-8397-dd889c6e43a3@github.com>
Message-ID: <PTMOm86ev6ztYo0dSfIycShRlZ_5VuXuM__ElhTnQM8=.a1c1c744-353e-4fd4-8ab4-fb711b357baf@github.com>

On Mon, 21 Jul 2025 20:44:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Got it. Could you have this hook in a private class method or a static public method? 
>> Maybe it can be reused in another points?
>
>> Maybe it can be reused in another points?
> 
> ClassFileFormatVersion and Optional are more user-oriented classes; internal code don't really ever use these two types, so I don't think you need to extract this logic specifically.

I mean about the rule the version - similar to isSupportedClassFileVersion method

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26406#discussion_r2220292747

From duke at openjdk.org  Mon Jul 21 20:57:27 2025
From: duke at openjdk.org (simon)
Date: Mon, 21 Jul 2025 20:57:27 GMT
Subject: RFR: 8355652: Parse ClassFileFormatVersion from ClassFileVersion
 [v2]
In-Reply-To: <MpW4C_foCl5UrDH2PhleuaCwvToMtHf3yvki3SysQDo=.0f006b61-1af3-462f-bc79-717d84cd1740@github.com>
References: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
 <MpW4C_foCl5UrDH2PhleuaCwvToMtHf3yvki3SysQDo=.0f006b61-1af3-462f-bc79-717d84cd1740@github.com>
Message-ID: <k0tlDSmFKwin22LP93vQxas6No9MsYn27S1zSezaXnk=.3bf3584e-ff94-444f-bfa2-530864921153@github.com>

On Mon, 21 Jul 2025 09:00:03 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> simon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8355652: update copyright year to 2025 in ClassFileVersionImpl.java
>>  - 8355652: update copyright year to 2025 in ClassFileVersionImpl.java
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileVersionImpl.java line 28:
> 
>> 26: 
>> 27: import java.lang.classfile.ClassFileVersion;
>> 28: import java.lang.reflect.ClassFileFormatVersion;
> 
> Nitpick: copyright year :)

@myankelev I updated the copyright year in ClassFileVersionImpl

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26406#discussion_r2220311729

From brett.okken.os at gmail.com  Mon Jul 21 21:01:46 2025
From: brett.okken.os at gmail.com (Brett Okken)
Date: Mon, 21 Jul 2025 16:01:46 -0500
Subject: String.charAt vs StringBuilder.charAt performance
In-Reply-To: <b443c697-c396-4bb4-8fb2-50304491dc58@oracle.com>
References: <CANBJVOHxaDv5q3GJPX8dn2GepcU9de39phavquaxKNXGZrMRrA@mail.gmail.com>
 <CABe8uE0UJ_=Vb842cTTnE4tuGPWDMKDb0bkD9CCvqNKQfXF20Q@mail.gmail.com>
 <CANBJVOFUEEt1GdM59D27cXbEzG9ZZZaafPsJqt6uQ+gwjruVKw@mail.gmail.com>
 <fd0e5706-7c69-42e1-8b58-da5281569cda@oracle.com>
 <CANBJVOHbJxR9TCLW4OWuN2uMP4TN-ZKhJTvOwZeUvXYQOv0j6g@mail.gmail.com>
 <b443c697-c396-4bb4-8fb2-50304491dc58@oracle.com>
Message-ID: <CANBJVOFNRcsSfAyT_AsS5Km=-uoA-rJLVJA1i4zrmJg4dEykPQ@mail.gmail.com>

Updating to have different test methods for each representation did remove
the difference for the non-ascii String case for the jdk 21+ releases.
However, the ascii (latin) strings are still slower with String than
StringBuilder.

How does C2 then handle something like StringCharBuffer wrapping a
CharSequence for all of it's get operations:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/StringCharBuffer.java#L88-L97

Which is then used by CharBufferSpliterator
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/CharBufferSpliterator.java

And by many CharsetEncoder impls when either source or destination is not
backed by array (which would be the case if StringCharBuffer used):
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/cs/UTF_8.java#L517
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/cs/UnicodeEncoder.java#L81



jdk 17
Benchmark                                         (data)  Mode  Cnt
Score     Error  Units
CharSequenceCharAtBenchmark.testString             ascii  avgt    3
 1429.358 ? 623.424  ns/op
CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3
705.282 ? 233.453  ns/op
CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3
724.138 ? 267.346  ns/op
CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3
718.357 ? 864.066  ns/op

jdk 21
Benchmark                                         (data)  Mode  Cnt
Score     Error  Units
CharSequenceCharAtBenchmark.testString             ascii  avgt    3
 1087.024 ?? 235.082  ns/op
CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3
687.520 ?? 747.532  ns/op
CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3
672.802 ??  29.740  ns/op
CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3
689.964 ?? 791.175  ns/op

jdk 25
Benchmark                                         (data)  Mode  Cnt
Score      Error  Units
CharSequenceCharAtBenchmark.testString             ascii  avgt    3
 1176.057 ?? 1157.979  ns/op
CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3
697.382 ??  231.144  ns/op
CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3
692.970 ??  105.112  ns/op
CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3
703.178 ??  446.019  ns/op

jdk 26
Benchmark                                         (data)  Mode  Cnt
Score     Error  Units
CharSequenceCharAtBenchmark.testString             ascii  avgt    3
 1132.971 ?? 350.786  ns/op
CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3
688.201 ?? 175.797  ns/op
CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3
704.380 ?? 101.763  ns/op
CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3
673.622 ??  51.462  ns/op


@Warmup(iterations = 2, time = 7, timeUnit = TimeUnit.SECONDS)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
@Fork(value = 1, jvmArgsPrepend = {"-Xms512M", "-Xmx512M"})
public class CharSequenceCharAtBenchmark {

    @Param(value = {"ascii", "non-ascii"})
    public String data;

    private String string;

    private StringBuilder stringBuilder;

    @Setup(Level.Trial)
    public void setup() throws Exception {
        StringBuilder sb = new StringBuilder(3152);
        for (int i=0; i<3152; ++i) {
            char c = (char) i;
            if ("ascii".equals(data)) {
                c = (char) (i & 0x7f);
            }
            sb.append(c);
        }

        string = sb.toString();
        stringBuilder = sb;
    }

    @Benchmark
    public int testString() {
        String sequence = this.string;
        int sum = 0;
        for (int i=0, j=sequence.length(); i<j; ++i) {
            sum += sequence.charAt(i);
        }
        return sum;
    }

    @Benchmark
    public int testStringBuilder() {
        StringBuilder sequence = this.stringBuilder;
        int sum = 0;
        for (int i=0, j=sequence.length(); i<j; ++i) {
            sum += sequence.charAt(i);
        }
        return sum;
    }
}

On Mon, Jul 21, 2025 at 1:12?PM Roger Riggs <roger.riggs at oracle.com> wrote:

> Hi Brett,
>
> I'd suggest separate initialization and test methods for the two cases to
> get more reliable numbers.
>
> By using @Trial and using a common field for the test data, I think you
> have handicapped C2.
> The training runs JMH does to warm up C2 are 'seeing' two different types
> for the value of sequence.
> Making the test runs independent will remov doubt about interactions due
> to the test setup.
>
> Roger
>
> On 7/21/25 1:43 PM, Brett Okken wrote:
>
> >  output labeled as StringBuffer but the jmh creates StringBuilder.
>
> Ugh - sorry about that. But yes - this is about StringBuilder vs String.
>
> > I would not be surprised that C2 has more optimizations for String than
> for StringBuilder.
>
> If that were true, it would not surprise me. However, these tests show the
> opposite. String is /slower/ than StringBuilder.
>
> On Mon, Jul 21, 2025 at 12:34?PM Roger Riggs <roger.riggs at oracle.com>
> wrote:
>
>> Hi Brett,
>>
>> The labeling of the output is confusing, the test output labeled as
>> StringBuffer but the jmh creates StringBuilder.
>> (StringBuffer methods are all synchronized and could explain why they are
>> slower).
>>
>> Also, I would not be surprised that C2 has more optimizations for String
>> than for StringBuilder.
>>
>> Regards, Roger
>>
>> On 7/19/25 6:09 PM, Brett Okken wrote:
>>
>> Making sequence a local variable does improve things (especially for
>> ascii), but a substantial difference remains. It appears that the
>> performance difference for ascii goes all the way back to jdk 11. The
>> difference for non-ascii showed up in jdk 21. I wonder if this is related
>> to the index checks?
>>
>> jdk 11
>>
>> Benchmark  (data)      (source)  Mode  Cnt     Score      Error  Units
>> test        ascii        String  avgt    3  1137.348 ?   12.835  ns/op
>> test        ascii  StringBuffer  avgt    3   712.874 ?  509.320  ns/op
>> test    non-ascii        String  avgt    3   668.657 ?  246.550  ns/op
>> test    non-ascii  StringBuffer  avgt    3   897.344 ? 4353.414  ns/op
>>
>>
>> jdk 17
>> Benchmark  (data)      (source)  Mode  Cnt     Score      Error  Units
>> test        ascii        String  avgt    3  1321.497 ? 2107.466  ns/op
>> test        ascii  StringBuffer  avgt    3   715.936 ?  412.189  ns/op
>> test    non-ascii        String  avgt    3   722.986 ?  443.389  ns/op
>> test    non-ascii  StringBuffer  avgt    3   722.787 ?  771.816  ns/op
>>
>>
>> jdk 21
>> Benchmark  (data)      (source)  Mode  Cnt     Score       Error  Units
>> test        ascii        String  avgt    3  1150.301 ??   918.549  ns/op
>> test        ascii  StringBuffer  avgt    3   713.183 ??   543.850  ns/op
>> test    non-ascii        String  avgt    3  4642.667 ?? 11481.029  ns/op
>> test    non-ascii  StringBuffer  avgt    3   728.027 ??   936.521  ns/op
>>
>>
>> jdk 25
>> Benchmark  (data)      (source)  Mode  Cnt     Score      Error  Units
>> test        ascii        String  avgt    3  1184.513 ?? 2057.498  ns/op
>> test        ascii  StringBuffer  avgt    3   786.611 ??  411.657  ns/op
>> test    non-ascii        String  avgt    3  4197.585 ?? 2761.388  ns/op
>> test    non-ascii  StringBuffer  avgt    3   716.375 ??  815.349  ns/op
>>
>>
>> jdk 26
>> Benchmark  (data)      (source)  Mode  Cnt     Score     Error  Units
>> test        ascii        String  avgt    3  1107.207 ?? 423.072  ns/op
>> test        ascii  StringBuffer  avgt    3   742.780 ?? 178.890  ns/op
>> test    non-ascii        String  avgt    3  4043.914 ?? 498.439  ns/op
>> test    non-ascii  StringBuffer  avgt    3   712.535 ?? 583.255  ns/op
>>
>>
>> On Sat, Jul 19, 2025 at 4:17?PM Chen Liang <liangchenblue at gmail.com>
>> wrote:
>>
>>> Without looking at C2 IRs, I think there are a few potential culprits we
>>> can look into:
>>> 1. JDK-8351000 and JDK-8351443 updated StringBuilder
>>> 2. Sequence field is read in the loop; I wonder if making it an explicit
>>> immutable local variable changes anything here.
>>>
>>> On Sat, Jul 19, 2025 at 2:34?PM Brett Okken <brett.okken.os at gmail.com>
>>> wrote:
>>>
>>>> I was looking at the performance of StringCharBuffer for various
>>>> backing CharSequence types and was surprised to see a significant
>>>> performance difference between String and StringBuffer. I wrote a
>>>> small jmh which shows that the String implementation of charAt is
>>>> significantly slower than StringBuilder. Is this expected?
>>>>
>>>> Benchmark                            (data)      (source)  Mode  Cnt
>>>>   Score       Error  Units
>>>> CharSequenceCharAtBenchmark.test      ascii        String  avgt    3
>>>> 2537.311 ??  8952.197  ns/op
>>>> CharSequenceCharAtBenchmark.test      ascii  StringBuffer  avgt    3
>>>> 852.004 ??  2532.958  ns/op
>>>> CharSequenceCharAtBenchmark.test  non-ascii        String  avgt    3
>>>> 5115.381 ?? 13822.592  ns/op
>>>> CharSequenceCharAtBenchmark.test  non-ascii  StringBuffer  avgt    3
>>>> 836.230 ??  1154.191  ns/op
>>>>
>>>>
>>>>
>>>> @Measurement(iterations = 3, time = 5, timeUnit = TimeUnit.SECONDS)
>>>> @Warmup(iterations = 2, time = 7, timeUnit = TimeUnit.SECONDS)
>>>> @BenchmarkMode(Mode.AverageTime)
>>>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>>>> @State(Scope.Benchmark)
>>>> @Fork(value = 1, jvmArgsPrepend = {"-Xms512M", "-Xmx512M"})
>>>> public class CharSequenceCharAtBenchmark {
>>>>
>>>>     @Param(value = {"ascii", "non-ascii"})
>>>>     public String data;
>>>>
>>>>     @Param(value = {"String", "StringBuffer"})
>>>>     public String source;
>>>>
>>>>     private CharSequence sequence;
>>>>
>>>>     @Setup(Level.Trial)
>>>>     public void setup() throws Exception {
>>>>         StringBuilder sb = new StringBuilder(3152);
>>>>         for (int i=0; i<3152; ++i) {
>>>>             char c = (char) i;
>>>>             if ("ascii".equals(data)) {
>>>>                 c = (char) (i & 0x7f);
>>>>             }
>>>>             sb.append(c);
>>>>         }
>>>>
>>>>         switch(source) {
>>>>             case "String":
>>>>                 sequence = sb.toString();
>>>>                 break;
>>>>             case "StringBuffer":
>>>>                 sequence = sb;
>>>>                 break;
>>>>             default:
>>>>                 throw new IllegalArgumentException(source);
>>>>         }
>>>>     }
>>>>
>>>>     @Benchmark
>>>>     public int test() {
>>>>         int sum = 0;
>>>>         for (int i=0, j=sequence.length(); i<j; ++i) {
>>>>             sum += sequence.charAt(i);
>>>>         }
>>>>         return sum;
>>>>     }
>>>> }
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250721/9c4acaba/attachment-0001.htm>

From liach at openjdk.org  Mon Jul 21 21:10:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Jul 2025 21:10:34 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v11]
In-Reply-To: <q4R1OCIUVggI3nVK3IK_DM1Fmgcu7xO3cdnY5xvn1Iw=.17fb68ac-5056-4199-b60f-b10ac106c427@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <l-0nLv2m8lEdI6wI7ukOFW4p-bDMASeWseu7gmYtUYU=.56c3fb4f-9d49-476d-91c3-e97e9bf89b73@github.com>
 <q4R1OCIUVggI3nVK3IK_DM1Fmgcu7xO3cdnY5xvn1Iw=.17fb68ac-5056-4199-b60f-b10ac106c427@github.com>
Message-ID: <G6sg9iGTcWF7bm2O8egD78jD9CiaknKqfHJFpUpKIO0=.1c827329-316c-4d5e-b058-b6b1531e9962@github.com>

On Mon, 21 Jul 2025 07:16:30 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> heapShared.cpp contains a list of hard coded classes & fields for archiving the initialized states in CDS archive. With the support for using annotation for pre-init being added to the mainline, the support can be applied to those classes as well.

I have looked into that; there is some difficulty, in particular, there are a lot of special handling for LMF classes, such as setting the protection domain, which distinguishes them from the LF/String concat classes. Since this is not as pure a migration, I am planning to do as a separate task; most likely, the string concat classes would be taken as the general hidden class template (which works for hidden classes like pattern matching, not sure about MethodHandleProxies, which also have publicly accessible instances like LMF)

> There could be cases where AOTC is not enabled but CDS or heap archiving with pre-initialization is enabled, it's good to consider more general naming for the annotations rather than using AOT-only-context based annotations, like `AOTSafeClassInitializer` and `AOTRuntimeSetup`.

Now we are using the term AOT not only to describe code compilation (like JIT), but for general preprocessing, like jlink. So the term AOT is suitable.

> As discussed during Leyden/premain meetings, there are classes/fields that are not suitable for pre-init and caching, such as Thread, Random, System, etc. We want to annotate or mark them so AOTC or CDS archiving ensures those states are not cached.

Also considered for a future patch. This relates to your safeguard proposal; we might add the safeguard implementation together with the warning annotation.

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

PR Comment: https://git.openjdk.org/jdk/pull/25922#issuecomment-3098961108

From vlivanov at openjdk.org  Mon Jul 21 21:12:26 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 21 Jul 2025 21:12:26 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
In-Reply-To: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
Message-ID: <WmxC5zkqBOGGvaND4mgSqT-nvNoWZf9-tXb__-7IVhg=.e415698b-8e67-4bf5-b8bd-3bc59c355a08@github.com>

On Wed, 2 Jul 2025 00:18:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

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

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26082#pullrequestreview-3039865524

From jlu at openjdk.org  Mon Jul 21 21:16:39 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 21 Jul 2025 21:16:39 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v6]
In-Reply-To: <JdxWpCBHtTssvz1lu08gRSrJr3So7vxoi5hiopLlxLo=.3931a767-c13c-455a-b631-616cbbd250ff@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <JdxWpCBHtTssvz1lu08gRSrJr3So7vxoi5hiopLlxLo=.3931a767-c13c-455a-b631-616cbbd250ff@github.com>
Message-ID: <7vuRjTHcLazcb58kpd2QUzqm5VZltpYSLpg2sLz_yL4=.3ac60ea1-3531-4ac1-827b-768291b4c904@github.com>

On Mon, 16 Jun 2025 21:19:45 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>> 
>> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
>> 
>> Testing:
>> - GHA
>> - Local run of tier 2 and jtreg:jdk/java/text
>> - New benchmark: DecimalFormatParseBench
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

The current form looks good to me. The long parsing did not change much on my machine performance wise, but I think it is a good simplification to include.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25644#pullrequestreview-3039876202

From jiangli at openjdk.org  Mon Jul 21 21:18:27 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 21 Jul 2025 21:18:27 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v11]
In-Reply-To: <G6sg9iGTcWF7bm2O8egD78jD9CiaknKqfHJFpUpKIO0=.1c827329-316c-4d5e-b058-b6b1531e9962@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <l-0nLv2m8lEdI6wI7ukOFW4p-bDMASeWseu7gmYtUYU=.56c3fb4f-9d49-476d-91c3-e97e9bf89b73@github.com>
 <q4R1OCIUVggI3nVK3IK_DM1Fmgcu7xO3cdnY5xvn1Iw=.17fb68ac-5056-4199-b60f-b10ac106c427@github.com>
 <G6sg9iGTcWF7bm2O8egD78jD9CiaknKqfHJFpUpKIO0=.1c827329-316c-4d5e-b058-b6b1531e9962@github.com>
Message-ID: <Im22N9iqozmTaU1ERvuZO4FxsQIFr7YtCXdqpoVYSbI=.84bdcde8-11fc-4098-889e-71b6a926dc60@github.com>

On Mon, 21 Jul 2025 21:08:13 GMT, Chen Liang <liach at openjdk.org> wrote:

> > heapShared.cpp contains a list of hard coded classes & fields for archiving the initialized states in CDS archive. With the support for using annotation for pre-init being added to the mainline, the support can be applied to those classes as well.
> 
> I have looked into that; there is some difficulty, in particular, there are a lot of special handling for LMF classes, such as setting the protection domain, which distinguishes them from the LF/String concat classes. Since this is not as pure a migration, I am planning to do as a separate task; most likely, the string concat classes would be taken as the general hidden class template (which works for hidden classes like pattern matching, not sure about MethodHandleProxies, which also have publicly accessible instances like LMF)

SG.

> 
> > There could be cases where AOTC is not enabled but CDS or heap archiving with pre-initialization is enabled, it's good to consider more general naming for the annotations rather than using AOT-only-context based annotations, like `AOTSafeClassInitializer` and `AOTRuntimeSetup`.
> 
> Now we are using the term AOT not only to describe code compilation (like JIT), but for general preprocessing, like jlink. So the term AOT is suitable.

Ok, that seems reasonable then.

> 
> > As discussed during Leyden/premain meetings, there are classes/fields that are not suitable for pre-init and caching, such as Thread, Random, System, etc. We want to annotate or mark them so AOTC or CDS archiving ensures those states are not cached.
> 
> Also considered for a future patch. This relates to your safeguard proposal; we might add the safeguard implementation together with the warning annotation.

SG.

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

PR Comment: https://git.openjdk.org/jdk/pull/25922#issuecomment-3099037148

From liach at openjdk.org  Mon Jul 21 21:29:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Jul 2025 21:29:24 GMT
Subject: RFR: 8355652: Parse ClassFileFormatVersion from ClassFileVersion
 [v2]
In-Reply-To: <PTMOm86ev6ztYo0dSfIycShRlZ_5VuXuM__ElhTnQM8=.a1c1c744-353e-4fd4-8ab4-fb711b357baf@github.com>
References: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
 <9boUuajMR4dXTViK0qwYubQU1_oPAXXZijdQ8K8aTN0=.733c561d-6ea2-4b6c-b7a7-c38c05ca32a8@github.com>
 <DZP8zTjNIbID298YbVbW4f7P-orWDGsASTq9oE7wvPQ=.87eaf865-023a-49db-ac44-06994d67e081@github.com>
 <ZC0BL34yfdWC03OXMVCkD0TsgL9XekhDvMvNnxfT7ss=.c024c1bf-728e-4e8c-8a03-4b7fce7edd68@github.com>
 <y2PSOzc2DKWuDN4TXFF5bbvduAhQLGT83jFwaYXrbhs=.57f95d8b-fefd-4c8d-aa4f-b71436a3fd4f@github.com>
 <eOD0d9mOjG8LDevyE4mKTi-8-1u6d1K0Dr2QTbX9dGg=.445fe1c0-644a-4e44-8397-dd889c6e43a3@github.com>
 <PTMOm86ev6ztYo0dSfIycShRlZ_5VuXuM__ElhTnQM8=.a1c1c744-353e-4fd4-8ab4-fb711b357baf@github.com>
Message-ID: <lS3nJdK735O_Qbgw8dyR5vJoTtQDjxdsQbxqaJSKRuQ=.45e705df-673c-4115-b115-5b4940fbad6a@github.com>

On Mon, 21 Jul 2025 20:48:12 GMT, simon <duke at openjdk.org> wrote:

>>> Maybe it can be reused in another points?
>> 
>> ClassFileFormatVersion and Optional are more user-oriented classes; internal code don't really ever use these two types, so I don't think you need to extract this logic specifically.
>
> I mean about the rule the version - similar to isSupportedClassFileVersion method

I still don't think so. I intentionally proposed the original RFE so we have one place where we can consolidate this handling, and that place should be here instead of some other place.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26406#discussion_r2220377268

From duke at openjdk.org  Mon Jul 21 21:29:24 2025
From: duke at openjdk.org (simon)
Date: Mon, 21 Jul 2025 21:29:24 GMT
Subject: RFR: 8355652: Parse ClassFileFormatVersion from ClassFileVersion
 [v2]
In-Reply-To: <lS3nJdK735O_Qbgw8dyR5vJoTtQDjxdsQbxqaJSKRuQ=.45e705df-673c-4115-b115-5b4940fbad6a@github.com>
References: <xqp1YapH3lPuuakLVeHEmdbkFqtpQqvU1GWDyxUqd44=.df0279e3-3d30-4dfe-a7e0-b20b4c61d5f8@github.com>
 <9boUuajMR4dXTViK0qwYubQU1_oPAXXZijdQ8K8aTN0=.733c561d-6ea2-4b6c-b7a7-c38c05ca32a8@github.com>
 <DZP8zTjNIbID298YbVbW4f7P-orWDGsASTq9oE7wvPQ=.87eaf865-023a-49db-ac44-06994d67e081@github.com>
 <ZC0BL34yfdWC03OXMVCkD0TsgL9XekhDvMvNnxfT7ss=.c024c1bf-728e-4e8c-8a03-4b7fce7edd68@github.com>
 <y2PSOzc2DKWuDN4TXFF5bbvduAhQLGT83jFwaYXrbhs=.57f95d8b-fefd-4c8d-aa4f-b71436a3fd4f@github.com>
 <eOD0d9mOjG8LDevyE4mKTi-8-1u6d1K0Dr2QTbX9dGg=.445fe1c0-644a-4e44-8397-dd889c6e43a3@github.com>
 <PTMOm86ev6ztYo0dSfIycShRlZ_5VuXuM__ElhTnQM8=.a1c1c744-353e-4fd4-8ab4-fb711b357baf@github.com>
 <lS3nJdK735O_Qbgw8dyR5vJoTtQDjxdsQbxqaJSKRuQ=.45e705df-673c-4115-b115-5b4940fbad6a@github.com>
Message-ID: <8MMIXxLMNtV6UUV3P0SawLcg-kbb-MUSjL5FftoE2rQ=.8dcd04e2-7f31-44dd-8c6b-b7299e0d4c49@github.com>

On Mon, 21 Jul 2025 21:24:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I mean about the rule the version - similar to isSupportedClassFileVersion method
>
> I still don't think so. I intentionally proposed the original RFE so we have one place where we can consolidate this handling, and that place should be here instead of some other place.

Great! I'll do this way

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26406#discussion_r2220381041

From chen.l.liang at oracle.com  Mon Jul 21 21:59:53 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Mon, 21 Jul 2025 21:59:53 +0000
Subject: String.charAt vs StringBuilder.charAt performance
In-Reply-To: <CANBJVOFNRcsSfAyT_AsS5Km=-uoA-rJLVJA1i4zrmJg4dEykPQ@mail.gmail.com>
References: <CANBJVOHxaDv5q3GJPX8dn2GepcU9de39phavquaxKNXGZrMRrA@mail.gmail.com>
 <CABe8uE0UJ_=Vb842cTTnE4tuGPWDMKDb0bkD9CCvqNKQfXF20Q@mail.gmail.com>
 <CANBJVOFUEEt1GdM59D27cXbEzG9ZZZaafPsJqt6uQ+gwjruVKw@mail.gmail.com>
 <fd0e5706-7c69-42e1-8b58-da5281569cda@oracle.com>
 <CANBJVOHbJxR9TCLW4OWuN2uMP4TN-ZKhJTvOwZeUvXYQOv0j6g@mail.gmail.com>
 <b443c697-c396-4bb4-8fb2-50304491dc58@oracle.com>
 <CANBJVOFNRcsSfAyT_AsS5Km=-uoA-rJLVJA1i4zrmJg4dEykPQ@mail.gmail.com>
Message-ID: <SJ2PR10MB76699AD4DCB8423D0DCE9306A25DA@SJ2PR10MB7669.namprd10.prod.outlook.com>

I finally came around and ran the benchmark on my linux-x64 device; however, I could not produce your results where String is significantly slower than StringBuilder.

This is the results I've got:

Benchmark                                         (data)  Mode  Cnt    Score    Error  Units
CharSequenceCharAtBenchmark.testString             ascii  avgt    5  668.649 ? 13.895  ns/op
CharSequenceCharAtBenchmark.testString         non-ascii  avgt    5  651.903 ?  7.240  ns/op
CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    5  673.802 ? 26.260  ns/op
CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    5  657.374 ? 35.785  ns/op

I think we might have more clue - are you testing on a macosx-aarch64 machine or some other platform? It might be that on some platforms, there are some problems in the hand-written assemblies for the intrinsics which contribute to this slowdown, instead of a problem with the C2 IR.

Chen
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Brett Okken <brett.okken.os at gmail.com>
Sent: Monday, July 21, 2025 4:01 PM
To: Roger Riggs <roger.riggs at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: String.charAt vs StringBuilder.charAt performance

Updating to have different test methods for each representation did remove the difference for the non-ascii String case for the jdk 21+ releases.
However, the ascii (latin) strings are still slower with String than StringBuilder.

How does C2 then handle something like StringCharBuffer wrapping a CharSequence for all of it's get operations:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/StringCharBuffer.java#L88-L97

Which is then used by CharBufferSpliterator
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/CharBufferSpliterator.java

And by many CharsetEncoder impls when either source or destination is not backed by array (which would be the case if StringCharBuffer used):
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/cs/UTF_8.java#L517
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/cs/UnicodeEncoder.java#L81



jdk 17
Benchmark                                         (data)  Mode  Cnt     Score     Error  Units
CharSequenceCharAtBenchmark.testString             ascii  avgt    3  1429.358 ? 623.424  ns/op
CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3   705.282 ? 233.453  ns/op
CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3   724.138 ? 267.346  ns/op
CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3   718.357 ? 864.066  ns/op

jdk 21
Benchmark                                         (data)  Mode  Cnt     Score     Error  Units
CharSequenceCharAtBenchmark.testString             ascii  avgt    3  1087.024 ?? 235.082  ns/op
CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3   687.520 ?? 747.532  ns/op
CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3   672.802 ??  29.740  ns/op
CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3   689.964 ?? 791.175  ns/op

jdk 25
Benchmark                                         (data)  Mode  Cnt     Score      Error  Units
CharSequenceCharAtBenchmark.testString             ascii  avgt    3  1176.057 ?? 1157.979  ns/op
CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3   697.382 ??  231.144  ns/op
CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3   692.970 ??  105.112  ns/op
CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3   703.178 ??  446.019  ns/op

jdk 26
Benchmark                                         (data)  Mode  Cnt     Score     Error  Units
CharSequenceCharAtBenchmark.testString             ascii  avgt    3  1132.971 ?? 350.786  ns/op
CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3   688.201 ?? 175.797  ns/op
CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3   704.380 ?? 101.763  ns/op
CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3   673.622 ??  51.462  ns/op


@Warmup(iterations = 2, time = 7, timeUnit = TimeUnit.SECONDS)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
@Fork(value = 1, jvmArgsPrepend = {"-Xms512M", "-Xmx512M"})
public class CharSequenceCharAtBenchmark {

    @Param(value = {"ascii", "non-ascii"})
    public String data;

    private String string;

    private StringBuilder stringBuilder;

    @Setup(Level.Trial)
    public void setup() throws Exception {
        StringBuilder sb = new StringBuilder(3152);
        for (int i=0; i<3152; ++i) {
            char c = (char) i;
            if ("ascii".equals(data)) {
                c = (char) (i & 0x7f);
            }
            sb.append(c);
        }

        string = sb.toString();
        stringBuilder = sb;
    }

    @Benchmark
    public int testString() {
        String sequence = this.string;
        int sum = 0;
        for (int i=0, j=sequence.length(); i<j; ++i) {
            sum += sequence.charAt(i);
        }
        return sum;
    }

    @Benchmark
    public int testStringBuilder() {
        StringBuilder sequence = this.stringBuilder;
        int sum = 0;
        for (int i=0, j=sequence.length(); i<j; ++i) {
            sum += sequence.charAt(i);
        }
        return sum;
    }
}

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

From msheppar at openjdk.org  Mon Jul 21 22:11:26 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 21 Jul 2025 22:11:26 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: <H44KKyG-abTiO8fhZSxDIMSCwAmfY4VM7MVZgtHDlrQ=.9f2a8610-93a3-4ba1-a7ea-e6e90dee400e@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

Marked as reviewed by msheppar (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26193#pullrequestreview-3040011489

From brett.okken.os at gmail.com  Mon Jul 21 22:13:51 2025
From: brett.okken.os at gmail.com (Brett Okken)
Date: Mon, 21 Jul 2025 17:13:51 -0500
Subject: String.charAt vs StringBuilder.charAt performance
In-Reply-To: <SJ2PR10MB76699AD4DCB8423D0DCE9306A25DA@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CANBJVOHxaDv5q3GJPX8dn2GepcU9de39phavquaxKNXGZrMRrA@mail.gmail.com>
 <CABe8uE0UJ_=Vb842cTTnE4tuGPWDMKDb0bkD9CCvqNKQfXF20Q@mail.gmail.com>
 <CANBJVOFUEEt1GdM59D27cXbEzG9ZZZaafPsJqt6uQ+gwjruVKw@mail.gmail.com>
 <fd0e5706-7c69-42e1-8b58-da5281569cda@oracle.com>
 <CANBJVOHbJxR9TCLW4OWuN2uMP4TN-ZKhJTvOwZeUvXYQOv0j6g@mail.gmail.com>
 <b443c697-c396-4bb4-8fb2-50304491dc58@oracle.com>
 <CANBJVOFNRcsSfAyT_AsS5Km=-uoA-rJLVJA1i4zrmJg4dEykPQ@mail.gmail.com>
 <SJ2PR10MB76699AD4DCB8423D0DCE9306A25DA@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <CANBJVOEhj97O-iNzEAq+pckhRD8FmzThetowJS9V_mFWpRGgOQ@mail.gmail.com>

I am running Windows x64. Windows 11 Pro 24H2

Intel(R) Core(TM) i7-1370P

On Mon, Jul 21, 2025 at 4:59?PM Chen Liang <chen.l.liang at oracle.com> wrote:

> I finally came around and ran the benchmark on my linux-x64 device;
> however, I could not produce your results where String is significantly
> slower than StringBuilder.
>
> This is the results I've got:
>
> Benchmark                                         (data)  Mode  Cnt
>  Score    Error  Units
> CharSequenceCharAtBenchmark.testString             ascii  avgt    5
>  668.649 ? 13.895  ns/op
> CharSequenceCharAtBenchmark.testString         non-ascii  avgt    5
>  651.903 ?  7.240  ns/op
> CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    5
>  673.802 ? 26.260  ns/op
> CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    5
>  657.374 ? 35.785  ns/op
>
> I think we might have more clue - are you testing on a macosx-aarch64
> machine or some other platform? It might be that on some platforms, there
> are some problems in the hand-written assemblies for the intrinsics which
> contribute to this slowdown, instead of a problem with the C2 IR.
>
> Chen
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Brett
> Okken <brett.okken.os at gmail.com>
> *Sent:* Monday, July 21, 2025 4:01 PM
> *To:* Roger Riggs <roger.riggs at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: String.charAt vs StringBuilder.charAt performance
>
> Updating to have different test methods for each representation did remove
> the difference for the non-ascii String case for the jdk 21+ releases.
> However, the ascii (latin) strings are still slower with String than
> StringBuilder.
>
> How does C2 then handle something like StringCharBuffer wrapping a
> CharSequence for all of it's get operations:
>
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/StringCharBuffer.java#L88-L97
>
> Which is then used by CharBufferSpliterator
>
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/CharBufferSpliterator.java
>
> And by many CharsetEncoder impls when either source or destination is not
> backed by array (which would be the case if StringCharBuffer used):
>
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/cs/UTF_8.java#L517
>
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/cs/UnicodeEncoder.java#L81
>
>
>
> jdk 17
> Benchmark                                         (data)  Mode  Cnt
> Score     Error  Units
> CharSequenceCharAtBenchmark.testString             ascii  avgt    3
>  1429.358 ? 623.424  ns/op
> CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3
> 705.282 ? 233.453  ns/op
> CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3
> 724.138 ? 267.346  ns/op
> CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3
> 718.357 ? 864.066  ns/op
>
> jdk 21
> Benchmark                                         (data)  Mode  Cnt
> Score     Error  Units
> CharSequenceCharAtBenchmark.testString             ascii  avgt    3
>  1087.024 ?? 235.082  ns/op
> CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3
> 687.520 ?? 747.532  ns/op
> CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3
> 672.802 ??  29.740  ns/op
> CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3
> 689.964 ?? 791.175  ns/op
>
> jdk 25
> Benchmark                                         (data)  Mode  Cnt
> Score      Error  Units
> CharSequenceCharAtBenchmark.testString             ascii  avgt    3
>  1176.057 ?? 1157.979  ns/op
> CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3
> 697.382 ??  231.144  ns/op
> CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3
> 692.970 ??  105.112  ns/op
> CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3
> 703.178 ??  446.019  ns/op
>
> jdk 26
> Benchmark                                         (data)  Mode  Cnt
> Score     Error  Units
> CharSequenceCharAtBenchmark.testString             ascii  avgt    3
>  1132.971 ?? 350.786  ns/op
> CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3
> 688.201 ?? 175.797  ns/op
> CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3
> 704.380 ?? 101.763  ns/op
> CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3
> 673.622 ??  51.462  ns/op
>
>
> @Warmup(iterations = 2, time = 7, timeUnit = TimeUnit.SECONDS)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @State(Scope.Benchmark)
> @Fork(value = 1, jvmArgsPrepend = {"-Xms512M", "-Xmx512M"})
> public class CharSequenceCharAtBenchmark {
>
>     @Param(value = {"ascii", "non-ascii"})
>     public String data;
>
>     private String string;
>
>     private StringBuilder stringBuilder;
>
>     @Setup(Level.Trial)
>     public void setup() throws Exception {
>         StringBuilder sb = new StringBuilder(3152);
>         for (int i=0; i<3152; ++i) {
>             char c = (char) i;
>             if ("ascii".equals(data)) {
>                 c = (char) (i & 0x7f);
>             }
>             sb.append(c);
>         }
>
>         string = sb.toString();
>         stringBuilder = sb;
>     }
>
>     @Benchmark
>     public int testString() {
>         String sequence = this.string;
>         int sum = 0;
>         for (int i=0, j=sequence.length(); i<j; ++i) {
>             sum += sequence.charAt(i);
>         }
>         return sum;
>     }
>
>     @Benchmark
>     public int testStringBuilder() {
>         StringBuilder sequence = this.stringBuilder;
>         int sum = 0;
>         for (int i=0, j=sequence.length(); i<j; ++i) {
>             sum += sequence.charAt(i);
>         }
>         return sum;
>     }
> }
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250721/fa2c950e/attachment-0001.htm>

From naoto at openjdk.org  Mon Jul 21 23:02:19 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 21 Jul 2025 23:02:19 GMT
Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system property
Message-ID: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>

This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well

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

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/26419/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26419&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355522
  Stats: 93 lines in 6 files changed: 1 ins; 61 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/26419.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26419/head:pull/26419

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

From duke at openjdk.org  Mon Jul 21 23:45:24 2025
From: duke at openjdk.org (duke)
Date: Mon, 21 Jul 2025 23:45:24 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: <x0WBJc3wWbj-80ESi0A_S5UzBVc-a0nahR8txNMCpyg=.43939002-6ce2-4f09-951b-1c0d46375545@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

@DarraghConway 
Your change (at version ba78184ecd4195663832166b06225c670ac00b38) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26193#issuecomment-3099946680

From dholmes at openjdk.org  Tue Jul 22 03:08:33 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Jul 2025 03:08:33 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <I79KijRZOM7Stzc7Sax_hFgxyPD_sEV2xaHZVipl2y4=.6f2fbe79-555c-4d04-9c38-25cea18075c5@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
 <NBeas7VSHxEynwU9LXuGy-p9Lg9Tm5I9auSaHBExzRA=.effd0ad3-a5f2-4049-b4df-49030a0502ef@github.com>
 <v45mu9Zly3T9l94b-WP1p_4oB_Y2Pe0gdU6C3w_vRqM=.ebaa8261-3d70-43a1-82b2-bba9def061a2@github.com>
 <8pLm1mah1JKonu3z5tWwIpU_J5jEggSiBst-PNEdG4s=.931782e4-3e34-4535-bc71-622d76b871a7@github.com>
 <I79KijRZOM7Stzc7Sax_hFgxyPD_sEV2xaHZVipl2y4=.6f2fbe79-555c-4d04-9c38-25cea18075c5@github.com>
Message-ID: <e3ycLg1tKUV8ZSN7SMUwI-nF4pGkOp248Q1Y4xshAzE=.fb15e3c4-23ec-42ea-b2e6-724bef08c21e@github.com>

On Tue, 17 Jun 2025 17:33:31 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> To add on this, I should mention that I noticed a lot of tests are using OutputAnalyzer indirectly, returned as a result of a utility function, for example `ProcessTools.execute{Process,Command}`
>> 
>> 
>> git grep -E "ProcessTools.execute((Process)|(Command))" | wc -l
>>      351
>> 
>> 
>> Instead of calling one of OutputAnalyzer's constructors (700 invocations, but many of them are with the Eager, string based and not process based, constructor, which we don't care about)
>> 
>> 
>> I'm not sure adding additional parameters also to that code is an ideal solution, I'd much prefer adding the command line parameter to the docs of the OutputAnalyzer class, so that one knows to enable it when running the single test through jtreg
>> 
>> ---
>> 
>> That said, if there are multiple OutputAnalyzers going in a single test, then it makes perfect sense to have (or at least use) a constructor argument
>
>> But isn't it the person running the tests that wants to set this, not an inherent property of a test itself?
> 
> I'm not sure if I completely understand your question. A lot of tests use the `test.debug` system property to enable more verbose test output. It's enabled when someone runs the test e.g., `jtreg -Dtest.debug=true ...`
> 
> As you pointed out, a lot of tests may not care if the subprocess's output is cached or not, but for those that do, having to specify a second property could be onerous and using the same `test.debug` property inside OutputBuffer could result in unexpected output. If the OutputAnalyzer ctor took a boolean , a test could enable (or not) with something like `new OutputAnalyzer(childProc, Boolean.getBoolean("test.debug"))`
> 
>> I'm not sure adding additional parameters also to that code is an ideal solution,
> 
> There are two constructors that take Process objects as arguments. I was thinking that you could overload them to take the extra argument. 
> 
> 
> public OutputAnalyzer(Process process, Charset cs, boolean flushOutput)
> public OutputAnalyzer(Process process, boolean flushOutput)
> 
> 
> None of the existing tests would be affected and those tests that could benefit from inline output could specify it as needed. You're right that the use of OutputAnalyzer is usually indirect so that would cause some other code to be changed as well, but it only has to change when it becomes necessary to enable it. (And it can be updated in the same way i.e., overloading the methods to take an extra argument.)

As noted above, it is not usual for test to create an instance of `OutputAnalyzer` directly, so the extra constructor argument would seem of little general value. But okay, it might be useful in some case.

In terms of the existing PR to control the behaviour via System property, I'll repeat my comment that "verbose" is not really the right word here. This does not change the amount of output only where it also gets sent to, and that is hard-wired to stdout/err so the name should reflect that e.g. printToStdStreams ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2220910786

From liach at openjdk.org  Tue Jul 22 04:06:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Jul 2025 04:06:26 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v8]
In-Reply-To: <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
Message-ID: <sE0TFDey2bGBWZgaYZYT-TL2MU7vzHolAliJFcBE9-w=.42ae0a78-eece-4529-a901-9de3917a16b1@github.com>

On Fri, 27 Jun 2025 01:04:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string.
>> 
>> For these scenarios, we can Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed.
>> 
>> @RogerRiggs completed the optimization when the encoder is LATIN1 in PR #24967. This PR continues to complete the optimization when the encoder is UTF16.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/StringUTF16.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

I just noticed there is `LibraryCallKit::inline_string_getCharsU` that is for byte -> char conversion. I wonder if we can slightly update it for char -> byte conversion.

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

PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-3100796762

From dholmes at openjdk.org  Tue Jul 22 05:53:30 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Jul 2025 05:53:30 GMT
Subject: RFR: 8362889: [GCC static analyzer] leak in
 libstringPlatformChars.c [v2]
In-Reply-To: <4N5AG59caGFsuYYcBqot0VhnWpkQ2AbLqTj3Z0qprns=.dad00183-e9e5-4da4-8187-7cfe0eeca693@github.com>
References: <ordEhGmC8cdl8LQKu-tmqNlvKSAK3ek3FUH6TMnpc-M=.b8c73a08-d65d-42ee-82a7-f3a0fd95d4db@github.com>
 <FiYPoe4CTB9_ot0gus8MtEU3EtyepVY3MuOGFGO7-9A=.ddf1b5de-28b4-43e6-b64c-7aafc729b1ff@github.com>
 <4N5AG59caGFsuYYcBqot0VhnWpkQ2AbLqTj3Z0qprns=.dad00183-e9e5-4da4-8187-7cfe0eeca693@github.com>
Message-ID: <J2H_j9bcurtgVMUeujZTp6vLAQiBMXcVmtExsHzlFkU=.c270e8ac-f58c-4272-90bc-243bea910169@github.com>

On Mon, 21 Jul 2025 15:38:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c line 74:
>> 
>>> 72:     (*env)->ReleasePrimitiveArrayCritical(env, bytes, (void*)jbytes, 0);
>>> 73: 
>>> 74:     jstring res = JNU_NewStringPlatform(env, str);
>> 
>> At line 66: where it returns null, it seem like it should also be freeing `str`.  (The analyzer didn't catch that?)
>
> It catches that too 
> 
> /jdk/test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c:65:8: warning: leak of 'str' [CWE-401] [-Wanalyzer-malloc-leak]
>    65 |     if (jbytes == NULL) {
> 
> 
> and also
> 
> 
> /jdk/test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c:69:16: warning: dereference of possibly-NULL 'str' [CWE-690] [-Wanalyzer-possible-null-dereference]
>    69 |         str[i] = (char)jbytes[i];
>       |         ~~~~~~~^~~~~~~~~~~~~~~~~
> 
> 
> I just overlooked it because a  log of a full build  with '-fanalyzer'  enabled contains quite a lot of output  (the event explanations of every finding are rather long).

Seems better to defer the `malloc` until after you know `jbytes` is not null; and also check the `malloc` result for null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26415#discussion_r2221292734

From xgong at openjdk.org  Tue Jul 22 06:20:34 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 22 Jul 2025 06:20:34 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: <r0GXxjunWG8C7D1Sa_ff6vygQCyLUOMfJqjAD42Avu4=.5695c224-02da-42b6-81d8-96b83d1a2afa@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

ping~ 
Hi @theRealAph, could you please help take a look at the latest commit? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3101230913

From aturbanov at openjdk.org  Tue Jul 22 06:20:32 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 22 Jul 2025 06:20:32 GMT
Subject: RFR: 8345836: Stable annotation documentation is incomplete
In-Reply-To: <5MPznGbnl6jsZ-og3SMtakdoHRjfRf8xZTKUUCCFqvk=.6e785ddf-cb06-48a1-ad40-70faaa7e8ee4@github.com>
References: <5MPznGbnl6jsZ-og3SMtakdoHRjfRf8xZTKUUCCFqvk=.6e785ddf-cb06-48a1-ad40-70faaa7e8ee4@github.com>
Message-ID: <Sn79xhox-sN7slKLurMD_2e78fJiVVfsBZrjdqb5JHA=.674d0682-926e-4b22-a38a-1bc595f802d4@github.com>

On Wed, 16 Jul 2025 17:45:23 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this documentation update, authored by @rose00 and originally pushed to the Leyden repo in [this PR](https://github.com/openjdk/leyden/pull/26), where more comments can be found regarding this update.

src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java line 310:

> 308:  * atomic operation such as {@code compareAndExchange},
> 309:  * {@code setRelease}, {@code releaseFence}, or the like.
> 310:  * </li><li> using regular variable access under explicit sychronization

typo `sychronization`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26355#discussion_r2221343585

From duke at openjdk.org  Tue Jul 22 07:03:11 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 22 Jul 2025 07:03:11 GMT
Subject: RFR: 8077587: BigInteger Roots [v32]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <Ayynz1toJdrBfEtZWv7Kw2hyu5lEMDEMS8tqzbl4PMY=.636aacbc-771b-4d7b-8cbf-a09708f9e68d@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

  Include one more possible correct bit in initial estimate

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/68525801..6a79f624

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=30-31

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

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

From pminborg at openjdk.org  Tue Jul 22 07:10:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Jul 2025 07:10:14 GMT
Subject: RFR: 8359936: StableValues can release the underlying function
 after complete computation [v4]
In-Reply-To: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
References: <TU7ZUwRq8HmcAZo4q9XYZOrGVhIVxtLRi_cUK1lbr6M=.553f6763-3ff3-42b0-9a8b-0222cbb50ee1@github.com>
Message-ID: <IdEWGHdhWdofu6j-Y329-DNlNUMuxcMud1oeMpzy508=.c7f8d3c6-a6c8-4971-bebb-0b034652e65b@github.com>

> This PR proposes to release the underlying function if a stable function or collection has invoked its underlying supplier exhaustively so that it can be collected.
> 
> This PR passes tier1, tier2, and tier3 testing on multiple platforms.

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

  Add a new method to StableValueImpl for improved speed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25878/files
  - new: https://git.openjdk.org/jdk/pull/25878/files/d585f712..f9fd6ebb

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

  Stats: 82 lines in 7 files changed: 26 ins; 29 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/25878.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25878/head:pull/25878

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

From alanb at openjdk.org  Tue Jul 22 07:16:26 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Jul 2025 07:16:26 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: <G_D_OSofvFIchtIGYXvsCXARFv9NadXQE_ibiX3yN_o=.3c41a6a2-ba13-42f7-a5bf-6f6e86baab93@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

test/jdk/java/io/File/MaxPathLength.java line 62:

> 60: 
> 61:         // test long paths on windows
> 62:         // And these long pathes cannot be handled on Solaris and Mac platforms

I assume this command should be updated to say Linux.

test/jdk/java/io/File/MaxPathLength.java line 196:

> 194:     }
> 195: 
> 196:     private static void testLongPathOnWindows () throws Exception {

Just a drive-by comment to say that naming it testLongPath and keeping the isWindows check in main would be a bit more readable. That will fit with the existing comment in main.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26193#discussion_r2221456217
PR Review Comment: https://git.openjdk.org/jdk/pull/26193#discussion_r2221455815

From aph at openjdk.org  Tue Jul 22 07:54:29 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Jul 2025 07:54:29 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: <BYov5K1D4jbFTpanBnt-JmxbrbyT-8mwq5fdWRfoQTY=.96078c2e-387e-4531-8f88-e2b97b9ab4ee@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

Looks good, thanks.

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

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26057#pullrequestreview-3041615796

From xgong at openjdk.org  Tue Jul 22 07:54:29 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 22 Jul 2025 07:54:29 GMT
Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short
 vectors [v4]
In-Reply-To: <BYov5K1D4jbFTpanBnt-JmxbrbyT-8mwq5fdWRfoQTY=.96078c2e-387e-4531-8f88-e2b97b9ab4ee@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <AmBFKMPlYw61TAK96M1JnZ7XFjGdicZcL4MVJ6GvNjo=.544eab42-4050-4317-b54d-999512605720@github.com>
 <BYov5K1D4jbFTpanBnt-JmxbrbyT-8mwq5fdWRfoQTY=.96078c2e-387e-4531-8f88-e2b97b9ab4ee@github.com>
Message-ID: <oVMmJSh_akrjEmNT4oyFfHUtgax5VgxVyXWceCp2-vA=.6a221b3b-17a3-4a1a-a778-482c7eb3e998@github.com>

On Tue, 22 Jul 2025 07:50:48 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Looks good, thanks.

Thanks so much for your review!

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

PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3101502718

From mbaesken at openjdk.org  Tue Jul 22 08:32:06 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 22 Jul 2025 08:32:06 GMT
Subject: RFR: 8362889: [GCC static analyzer] leak in
 libstringPlatformChars.c [v3]
In-Reply-To: <ordEhGmC8cdl8LQKu-tmqNlvKSAK3ek3FUH6TMnpc-M=.b8c73a08-d65d-42ee-82a7-f3a0fd95d4db@github.com>
References: <ordEhGmC8cdl8LQKu-tmqNlvKSAK3ek3FUH6TMnpc-M=.b8c73a08-d65d-42ee-82a7-f3a0fd95d4db@github.com>
Message-ID: <FqPWyHqzvqOaxLjKKn9IrsLxBuJ5dBeKjJqO9OMmENg=.26d89d3f-123e-410f-ac7d-31da69f94f48@github.com>

> This is reported by the gcc static analyzer (-fanalyzer); it is just test coding so not very critical but probably should still be adjusted .
> 
> 
> /jdk/test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c:74:12: warning: leak of 'str' [CWE-401] [-Wanalyzer-malloc-leak]
>    74 | return JNU_NewStringPlatform(env, str);

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

  Adjust Java_StringPlatformChars_newString

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26415/files
  - new: https://git.openjdk.org/jdk/pull/26415/files/e2f902f6..de4f7881

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

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

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

From xgong at openjdk.org  Tue Jul 22 09:09:36 2025
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 22 Jul 2025 09:09:36 GMT
Subject: Integrated: 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: <lB2PertrrcASM127s9nREYAEuZD87Gj0b1iKbl6wjgw=.e0f28466-4d84-4de3-8504-c542c3c4ec2c@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...

This pull request has now been integrated.

Changeset: ac141c2f
Author:    Xiaohong Gong <xgong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac141c2fa1d818858e7a12a50837bb282282ecac
Stats:     359 lines in 10 files changed: 231 ins; 9 del; 119 mod

8359419: AArch64: Relax min vector length to 32-bit for short vectors

Reviewed-by: aph, fgao, bkilambi, dlunden

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

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

From aturbanov at openjdk.org  Tue Jul 22 11:03:26 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 22 Jul 2025 11:03:26 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
 [v3]
In-Reply-To: <ZgjRJGyu9IFgCsZyFF3D1cswr9nJD3vq7hWeX6Qumdk=.a8a46b00-108f-4d0f-9d47-cb4932e07d29@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
 <ZgjRJGyu9IFgCsZyFF3D1cswr9nJD3vq7hWeX6Qumdk=.a8a46b00-108f-4d0f-9d47-cb4932e07d29@github.com>
Message-ID: <f8If1NOmSZ06zkSz3_ijPvLt_D2FTFQ4S48502fpVqw=.48c956df-653f-4517-90e5-97097934d68c@github.com>

On Thu, 17 Jul 2025 21:40:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review feedback.

src/java.base/share/classes/java/lang/FdLibm.java line 2263:

> 2261:                 // final double DP_H[]  = {0.0,
> 2262:                 //                        0x1.2b80_34p-1};        // 5.84962487220764160156e-01
> 2263:                 final double DP_H1   = 0x1.2b80_34p-1;

Suggestion:

                final double DP_H1 = 0x1.2b80_34p-1;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26341#discussion_r2222176314

From duke at openjdk.org  Tue Jul 22 11:21:46 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 22 Jul 2025 11:21:46 GMT
Subject: RFR: 8077587: BigInteger Roots [v33]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <6uhQJh06jrg54tH-SVHLj1lZ-K2jfNFupJls9-oUe5I=.b5990534-7dbc-4e07-9c1e-26e294125ae4@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

  No need to check for root's shift overflow

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/6a79f624..eab46d0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=31-32

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

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

From brett.okken.os at gmail.com  Tue Jul 22 11:44:05 2025
From: brett.okken.os at gmail.com (Brett Okken)
Date: Tue, 22 Jul 2025 06:44:05 -0500
Subject: String.charAt vs StringBuilder.charAt performance
In-Reply-To: <CANBJVOEhj97O-iNzEAq+pckhRD8FmzThetowJS9V_mFWpRGgOQ@mail.gmail.com>
References: <CANBJVOHxaDv5q3GJPX8dn2GepcU9de39phavquaxKNXGZrMRrA@mail.gmail.com>
 <CABe8uE0UJ_=Vb842cTTnE4tuGPWDMKDb0bkD9CCvqNKQfXF20Q@mail.gmail.com>
 <CANBJVOFUEEt1GdM59D27cXbEzG9ZZZaafPsJqt6uQ+gwjruVKw@mail.gmail.com>
 <fd0e5706-7c69-42e1-8b58-da5281569cda@oracle.com>
 <CANBJVOHbJxR9TCLW4OWuN2uMP4TN-ZKhJTvOwZeUvXYQOv0j6g@mail.gmail.com>
 <b443c697-c396-4bb4-8fb2-50304491dc58@oracle.com>
 <CANBJVOFNRcsSfAyT_AsS5Km=-uoA-rJLVJA1i4zrmJg4dEykPQ@mail.gmail.com>
 <SJ2PR10MB76699AD4DCB8423D0DCE9306A25DA@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOEhj97O-iNzEAq+pckhRD8FmzThetowJS9V_mFWpRGgOQ@mail.gmail.com>
Message-ID: <CANBJVOHC0533A7JMhckoDJ1X2SJQDbS=cccCpTECaSmAQzc3xQ@mail.gmail.com>

It does look like this is windows specific. If I run on WSL, I get results
similar to your linux-x64:

Benchmark                                         (data)  Mode  Cnt
 Score     Error  Units
CharSequenceCharAtBenchmark.testString             ascii  avgt    3
 679.294 ? 302.947  ns/op
CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3
 702.071 ? 926.959  ns/op
CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3
 682.815 ? 301.649  ns/op
CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3
 678.169 ? 810.276  ns/op

And I go back to the original version of the test, where String vs
StringBuilder is defined by parameter and both assigned to same local
variable as part of set up, that also shows no difference in wsl.
So it appears everything I observed is an artifact of Windows specific
intrinsics?

Benchmark                            (data)       (source)  Mode  Cnt
 Score     Error  Units
CharSequenceCharAtBenchmark.test      ascii         String  avgt    3
 660.597 ? 146.405  ns/op
CharSequenceCharAtBenchmark.test      ascii  StringBuilder  avgt    3
 659.395 ? 155.167  ns/op
CharSequenceCharAtBenchmark.test  non-ascii         String  avgt    3
 647.955 ? 189.747  ns/op
CharSequenceCharAtBenchmark.test  non-ascii  StringBuilder  avgt    3
 639.678 ? 146.923  ns/op

On Mon, Jul 21, 2025 at 5:13?PM Brett Okken <brett.okken.os at gmail.com>
wrote:

> I am running Windows x64. Windows 11 Pro 24H2
>
> Intel(R) Core(TM) i7-1370P
>
> On Mon, Jul 21, 2025 at 4:59?PM Chen Liang <chen.l.liang at oracle.com>
> wrote:
>
>> I finally came around and ran the benchmark on my linux-x64 device;
>> however, I could not produce your results where String is significantly
>> slower than StringBuilder.
>>
>> This is the results I've got:
>>
>> Benchmark                                         (data)  Mode  Cnt
>>  Score    Error  Units
>> CharSequenceCharAtBenchmark.testString             ascii  avgt    5
>>  668.649 ? 13.895  ns/op
>> CharSequenceCharAtBenchmark.testString         non-ascii  avgt    5
>>  651.903 ?  7.240  ns/op
>> CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    5
>>  673.802 ? 26.260  ns/op
>> CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    5
>>  657.374 ? 35.785  ns/op
>>
>> I think we might have more clue - are you testing on a macosx-aarch64
>> machine or some other platform? It might be that on some platforms, there
>> are some problems in the hand-written assemblies for the intrinsics which
>> contribute to this slowdown, instead of a problem with the C2 IR.
>>
>> Chen
>> ------------------------------
>> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
>> Brett Okken <brett.okken.os at gmail.com>
>> *Sent:* Monday, July 21, 2025 4:01 PM
>> *To:* Roger Riggs <roger.riggs at oracle.com>
>> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>> *Subject:* Re: String.charAt vs StringBuilder.charAt performance
>>
>> Updating to have different test methods for each representation did
>> remove the difference for the non-ascii String case for the jdk 21+
>> releases.
>> However, the ascii (latin) strings are still slower with String than
>> StringBuilder.
>>
>> How does C2 then handle something like StringCharBuffer wrapping a
>> CharSequence for all of it's get operations:
>>
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/StringCharBuffer.java#L88-L97
>>
>> Which is then used by CharBufferSpliterator
>>
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/CharBufferSpliterator.java
>>
>> And by many CharsetEncoder impls when either source or destination is not
>> backed by array (which would be the case if StringCharBuffer used):
>>
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/cs/UTF_8.java#L517
>>
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/cs/UnicodeEncoder.java#L81
>>
>>
>>
>> jdk 17
>> Benchmark                                         (data)  Mode  Cnt
>> Score     Error  Units
>> CharSequenceCharAtBenchmark.testString             ascii  avgt    3
>>  1429.358 ? 623.424  ns/op
>> CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3
>> 705.282 ? 233.453  ns/op
>> CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3
>> 724.138 ? 267.346  ns/op
>> CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3
>> 718.357 ? 864.066  ns/op
>>
>> jdk 21
>> Benchmark                                         (data)  Mode  Cnt
>> Score     Error  Units
>> CharSequenceCharAtBenchmark.testString             ascii  avgt    3
>>  1087.024 ?? 235.082  ns/op
>> CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3
>> 687.520 ?? 747.532  ns/op
>> CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3
>> 672.802 ??  29.740  ns/op
>> CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3
>> 689.964 ?? 791.175  ns/op
>>
>> jdk 25
>> Benchmark                                         (data)  Mode  Cnt
>> Score      Error  Units
>> CharSequenceCharAtBenchmark.testString             ascii  avgt    3
>>  1176.057 ?? 1157.979  ns/op
>> CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3
>> 697.382 ??  231.144  ns/op
>> CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3
>> 692.970 ??  105.112  ns/op
>> CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3
>> 703.178 ??  446.019  ns/op
>>
>> jdk 26
>> Benchmark                                         (data)  Mode  Cnt
>> Score     Error  Units
>> CharSequenceCharAtBenchmark.testString             ascii  avgt    3
>>  1132.971 ?? 350.786  ns/op
>> CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3
>> 688.201 ?? 175.797  ns/op
>> CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3
>> 704.380 ?? 101.763  ns/op
>> CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3
>> 673.622 ??  51.462  ns/op
>>
>>
>> @Warmup(iterations = 2, time = 7, timeUnit = TimeUnit.SECONDS)
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @State(Scope.Benchmark)
>> @Fork(value = 1, jvmArgsPrepend = {"-Xms512M", "-Xmx512M"})
>> public class CharSequenceCharAtBenchmark {
>>
>>     @Param(value = {"ascii", "non-ascii"})
>>     public String data;
>>
>>     private String string;
>>
>>     private StringBuilder stringBuilder;
>>
>>     @Setup(Level.Trial)
>>     public void setup() throws Exception {
>>         StringBuilder sb = new StringBuilder(3152);
>>         for (int i=0; i<3152; ++i) {
>>             char c = (char) i;
>>             if ("ascii".equals(data)) {
>>                 c = (char) (i & 0x7f);
>>             }
>>             sb.append(c);
>>         }
>>
>>         string = sb.toString();
>>         stringBuilder = sb;
>>     }
>>
>>     @Benchmark
>>     public int testString() {
>>         String sequence = this.string;
>>         int sum = 0;
>>         for (int i=0, j=sequence.length(); i<j; ++i) {
>>             sum += sequence.charAt(i);
>>         }
>>         return sum;
>>     }
>>
>>     @Benchmark
>>     public int testStringBuilder() {
>>         StringBuilder sequence = this.stringBuilder;
>>         int sum = 0;
>>         for (int i=0, j=sequence.length(); i<j; ++i) {
>>             sum += sequence.charAt(i);
>>         }
>>         return sum;
>>     }
>> }
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250722/c43d4815/attachment-0001.htm>

From myankelevich at openjdk.org  Tue Jul 22 11:46:29 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 22 Jul 2025 11:46:29 GMT
Subject: RFR: 8077587: BigInteger Roots [v33]
In-Reply-To: <6uhQJh06jrg54tH-SVHLj1lZ-K2jfNFupJls9-oUe5I=.b5990534-7dbc-4e07-9c1e-26e294125ae4@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <6uhQJh06jrg54tH-SVHLj1lZ-K2jfNFupJls9-oUe5I=.b5990534-7dbc-4e07-9c1e-26e294125ae4@github.com>
Message-ID: <TaQfIBcYKli9BYsKPjtzumYOmraamoEfntjN_CUwnh0=.79135ad6-d9ee-40d8-ab39-f6eaaa689ad3@github.com>

On Tue, 22 Jul 2025 11:21:46 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No need to check for root's shift overflow

minor: could you please update the `@bug` with bug id

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

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3102361567

From duke at openjdk.org  Tue Jul 22 12:24:30 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 22 Jul 2025 12:24:30 GMT
Subject: RFR: 8077587: BigInteger Roots [v34]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <d7Y6vPBthCKmeta5O7RHdcnf2pSOPswQa1xQP1D-Wz0=.7ac47f45-f260-44cf-bb36-7ccd0ad5e128@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

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

  Added bug id

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/eab46d0c..3d1705d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=32-33

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

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

From rriggs at openjdk.org  Tue Jul 22 13:37:26 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Jul 2025 13:37:26 GMT
Subject: RFR: 8362889: [GCC static analyzer] leak in
 libstringPlatformChars.c [v3]
In-Reply-To: <FqPWyHqzvqOaxLjKKn9IrsLxBuJ5dBeKjJqO9OMmENg=.26d89d3f-123e-410f-ac7d-31da69f94f48@github.com>
References: <ordEhGmC8cdl8LQKu-tmqNlvKSAK3ek3FUH6TMnpc-M=.b8c73a08-d65d-42ee-82a7-f3a0fd95d4db@github.com>
 <FqPWyHqzvqOaxLjKKn9IrsLxBuJ5dBeKjJqO9OMmENg=.26d89d3f-123e-410f-ac7d-31da69f94f48@github.com>
Message-ID: <2kI6P7gJTdg_mcZ3vtIJCQ1v6hDbmpAxKAVwv5Fkkh4=.8d5d887e-e7ae-437e-b2c9-8740093faf21@github.com>

On Tue, 22 Jul 2025 08:32:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> This is reported by the gcc static analyzer (-fanalyzer); it is just test coding so not very critical but probably should still be adjusted .
>> 
>> 
>> /jdk/test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c:74:12: warning: leak of 'str' [CWE-401] [-Wanalyzer-malloc-leak]
>>    74 | return JNU_NewStringPlatform(env, str);
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust Java_StringPlatformChars_newString

test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c line 67:

> 65:     str = (char*)malloc(len + 1);
> 66:     if (str == NULL) {
> 67:         return NULL;

Six of one, half-dozen of the other.  
You'll need to ReleasePrimitiveArrayCritical here or revert to the previous version.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26415#discussion_r2222560525

From mbaesken at openjdk.org  Tue Jul 22 14:01:56 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 22 Jul 2025 14:01:56 GMT
Subject: RFR: 8362889: [GCC static analyzer] leak in
 libstringPlatformChars.c [v4]
In-Reply-To: <ordEhGmC8cdl8LQKu-tmqNlvKSAK3ek3FUH6TMnpc-M=.b8c73a08-d65d-42ee-82a7-f3a0fd95d4db@github.com>
References: <ordEhGmC8cdl8LQKu-tmqNlvKSAK3ek3FUH6TMnpc-M=.b8c73a08-d65d-42ee-82a7-f3a0fd95d4db@github.com>
Message-ID: <VI2_0y_t67Q04GDM-cZlUuulIrgJvT_a9_i4i2cnDZk=.47dba761-5225-4faa-8224-a26f38cf4cae@github.com>

> This is reported by the gcc static analyzer (-fanalyzer); it is just test coding so not very critical but probably should still be adjusted .
> 
> 
> /jdk/test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c:74:12: warning: leak of 'str' [CWE-401] [-Wanalyzer-malloc-leak]
>    74 | return JNU_NewStringPlatform(env, str);

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

  Add ReleasePrimitiveArrayCritical

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26415/files
  - new: https://git.openjdk.org/jdk/pull/26415/files/de4f7881..82db2480

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

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

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

From raffaello.giulietti at oracle.com  Tue Jul 22 14:10:59 2025
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Tue, 22 Jul 2025 16:10:59 +0200
Subject: String.charAt vs StringBuilder.charAt performance
In-Reply-To: <CANBJVOHC0533A7JMhckoDJ1X2SJQDbS=cccCpTECaSmAQzc3xQ@mail.gmail.com>
References: <CANBJVOHxaDv5q3GJPX8dn2GepcU9de39phavquaxKNXGZrMRrA@mail.gmail.com>
 <CABe8uE0UJ_=Vb842cTTnE4tuGPWDMKDb0bkD9CCvqNKQfXF20Q@mail.gmail.com>
 <CANBJVOFUEEt1GdM59D27cXbEzG9ZZZaafPsJqt6uQ+gwjruVKw@mail.gmail.com>
 <fd0e5706-7c69-42e1-8b58-da5281569cda@oracle.com>
 <CANBJVOHbJxR9TCLW4OWuN2uMP4TN-ZKhJTvOwZeUvXYQOv0j6g@mail.gmail.com>
 <b443c697-c396-4bb4-8fb2-50304491dc58@oracle.com>
 <CANBJVOFNRcsSfAyT_AsS5Km=-uoA-rJLVJA1i4zrmJg4dEykPQ@mail.gmail.com>
 <SJ2PR10MB76699AD4DCB8423D0DCE9306A25DA@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOEhj97O-iNzEAq+pckhRD8FmzThetowJS9V_mFWpRGgOQ@mail.gmail.com>
 <CANBJVOHC0533A7JMhckoDJ1X2SJQDbS=cccCpTECaSmAQzc3xQ@mail.gmail.com>
Message-ID: <5436965e-211f-4f4f-84a5-2dcde7f3e8c0@oracle.com>

Hi,

the errors are so large that I'd dare to say that the measurements are 
unreliable.


On 2025-07-22 13:44, Brett Okken wrote:
> It does look like this is windows specific. If I run on WSL, I get 
> results similar to your linux-x64:
>
> Benchmark ? ? ? ? ? ? ? ? ? ? ? (data) ?Mode ?Cnt ? ?Score ? ? Error 
> ?Units
> CharSequenceCharAtBenchmark.testString ? ? ? ? ? ? ascii ?avgt ? ?3 
> ?679.294 ? 302.947 ?ns/op
> CharSequenceCharAtBenchmark.testString ? ? ? ? non-ascii ?avgt ? ?3 
> ?702.071 ? 926.959 ?ns/op
> CharSequenceCharAtBenchmark.testStringBuilder ? ? ?ascii ?avgt ? ?3 
> ?682.815 ? 301.649 ?ns/op
> CharSequenceCharAtBenchmark.testStringBuilder ?non-ascii ?avgt ? ?3 
> ?678.169 ? 810.276 ?ns/op
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250722/01857d0d/attachment.htm>

From rriggs at openjdk.org  Tue Jul 22 14:11:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Jul 2025 14:11:29 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
Message-ID: <9Hxf6U6rzK6SZMDlZkwuyjszdFQLSv0Vb6TAWF24nGw=.499d5efe-83cc-43df-a36a-4499857adaea@github.com>

On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini <duke at openjdk.org> wrote:

>> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
>> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.
>> 
>> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.
>
> Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print
>  - Update test/lib/jdk/test/lib/process/OutputBuffer.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Initial working solution

Catching up a bit. The use case is for running a test from the commandline where the timing of the output seems to be significant to the debugging sessions?  It is assumed that the test launches a subprocess and is monitoring its state.

Is there an example of the test where this would be used?

The test utilities of OutputAnalyzer may not be what you need. 
They encapsulate a number of behaviors that are readily available using ProcessBuilder and Process.

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

PR Comment: https://git.openjdk.org/jdk/pull/25587#issuecomment-3102914137

From rriggs at openjdk.org  Tue Jul 22 14:13:30 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Jul 2025 14:13:30 GMT
Subject: RFR: 8362889: [GCC static analyzer] leak in
 libstringPlatformChars.c [v4]
In-Reply-To: <VI2_0y_t67Q04GDM-cZlUuulIrgJvT_a9_i4i2cnDZk=.47dba761-5225-4faa-8224-a26f38cf4cae@github.com>
References: <ordEhGmC8cdl8LQKu-tmqNlvKSAK3ek3FUH6TMnpc-M=.b8c73a08-d65d-42ee-82a7-f3a0fd95d4db@github.com>
 <VI2_0y_t67Q04GDM-cZlUuulIrgJvT_a9_i4i2cnDZk=.47dba761-5225-4faa-8224-a26f38cf4cae@github.com>
Message-ID: <tS7F6gTRMvML6ZCgX-eTnXbfljIejdPKDEmo-DHnbuE=.89b99c2f-fb08-44fe-a7f7-3b1dfd273b94@github.com>

On Tue, 22 Jul 2025 14:01:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> This is reported by the gcc static analyzer (-fanalyzer); it is just test coding so not very critical but probably should still be adjusted .
>> 
>> 
>> /jdk/test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c:74:12: warning: leak of 'str' [CWE-401] [-Wanalyzer-malloc-leak]
>>    74 | return JNU_NewStringPlatform(env, str);
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add ReleasePrimitiveArrayCritical

looks good

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26415#pullrequestreview-3043200976

From mbaesken at openjdk.org  Tue Jul 22 14:16:27 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 22 Jul 2025 14:16:27 GMT
Subject: RFR: 8362889: [GCC static analyzer] leak in
 libstringPlatformChars.c [v4]
In-Reply-To: <VI2_0y_t67Q04GDM-cZlUuulIrgJvT_a9_i4i2cnDZk=.47dba761-5225-4faa-8224-a26f38cf4cae@github.com>
References: <ordEhGmC8cdl8LQKu-tmqNlvKSAK3ek3FUH6TMnpc-M=.b8c73a08-d65d-42ee-82a7-f3a0fd95d4db@github.com>
 <VI2_0y_t67Q04GDM-cZlUuulIrgJvT_a9_i4i2cnDZk=.47dba761-5225-4faa-8224-a26f38cf4cae@github.com>
Message-ID: <WDTArSfLjOAUe8j5lnnUuwrY1NNOGAIOxiZF7_jcn7c=.d619441f-234b-4cc4-8f0b-5d2d93c3ef36@github.com>

On Tue, 22 Jul 2025 14:01:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> This is reported by the gcc static analyzer (-fanalyzer); it is just test coding so not very critical but probably should still be adjusted .
>> 
>> 
>> /jdk/test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c:74:12: warning: leak of 'str' [CWE-401] [-Wanalyzer-malloc-leak]
>>    74 | return JNU_NewStringPlatform(env, str);
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add ReleasePrimitiveArrayCritical

Hi Roger, thanks for the review !

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

PR Comment: https://git.openjdk.org/jdk/pull/26415#issuecomment-3102936190

From kcr at openjdk.org  Tue Jul 22 15:00:36 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 15:00:36 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
Message-ID: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>

This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.

The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.


src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
src/jdk.compiler/share/data/symbols/symbols
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list


I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into 8359760-rm-jsobject
 - Bump copyright year
 - Merge remote-tracking branch 'upstream/master' into 8359760-rm-jsobject
 - 8359760: Remove the jdk.jsobject module

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

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

From kcr at openjdk.org  Tue Jul 22 15:00:36 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 15:00:36 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
Message-ID: <Jy76wevmXN0kbyz2G-gSH2SrK9dfwZadFX2je3roZA0=.79941b87-398d-4812-910e-163520606089@github.com>

On Fri, 18 Jul 2025 16:58:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
> 
> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
> 
> 
> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
> src/jdk.compiler/share/data/symbols/symbols
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
> test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list
> 
> 
> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.

@RogerRiggs @AlanBateman Can you review this PR to remove the `jdk.jsobject` module, which was deprecated for removal by PR #20555 ?

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

PR Comment: https://git.openjdk.org/jdk/pull/26393#issuecomment-3103204720

From alanb at openjdk.org  Tue Jul 22 15:09:25 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Jul 2025 15:09:25 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
Message-ID: <3jmBibdv4ZqVjUF9FI7KNvJ2H3siKn2H-WivoPRaWXw=.f399ac98-c29d-46a2-9c39-7ec5cd691623@github.com>

On Fri, 18 Jul 2025 16:58:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
> 
> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
> 
> 
> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
> src/jdk.compiler/share/data/symbols/symbols
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
> test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list
> 
> 
> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.

I did a quick scan and the updates to the conf, the removal, and the test changes look okay. Happy to review the CSR when you have it ready.

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

PR Comment: https://git.openjdk.org/jdk/pull/26393#issuecomment-3103254196

From rriggs at openjdk.org  Tue Jul 22 15:18:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Jul 2025 15:18:52 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
Message-ID: <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>

On Fri, 18 Jul 2025 16:58:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
> 
> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
> 
> 
> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
> src/jdk.compiler/share/data/symbols/symbols
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
> test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list
> 
> 
> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.

test/langtools/jdk/javadoc/doclet/testModules/jdk/element-list line 305:

> 303: jdk.jshell.spi
> 304: jdk.jshell.tool
> 305: module:jdk.jsobject

There is a similar pair in test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list.
Can it be removed? Unless it causes a test failure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2222878346

From liach at openjdk.org  Tue Jul 22 15:37:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Jul 2025 15:37:27 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
 [v3]
In-Reply-To: <ZgjRJGyu9IFgCsZyFF3D1cswr9nJD3vq7hWeX6Qumdk=.a8a46b00-108f-4d0f-9d47-cb4932e07d29@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
 <ZgjRJGyu9IFgCsZyFF3D1cswr9nJD3vq7hWeX6Qumdk=.a8a46b00-108f-4d0f-9d47-cb4932e07d29@github.com>
Message-ID: <TOGyIxr5eouB2i6fUgYSeOL3VyCgNynD1iTJxnoXUIQ=.57f7d059-87a6-48e2-8eec-4540823a9499@github.com>

On Thu, 17 Jul 2025 21:40:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review feedback.

Re @turbanoff and @ExE-Boss's style fixes: this code is ported from the c code of fdlibm so it has a lot of irregular styles. I think we might look into updating the implementation to be more Java-ish in the future in another patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/26341#issuecomment-3103334062

From rgiulietti at openjdk.org  Tue Jul 22 15:37:37 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 22 Jul 2025 15:37:37 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <i8xz8qX-FNCtYM1uGqNb63t0MBTYEwlX20dfbq8HLL0=.0734d880-6cc9-41ea-a18d-0b287388e73b@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <B8rouVL6Ecjm0lIqzwSjvhICoV_QonD06LqMZ853tFw=.575fe02c-f7b5-4f46-857a-c591a62a1bcd@github.com>
 <pU242ecdIxZSk-uXlfSiXjMX-xNZFq_R6H4kklT1Klw=.27929cce-dcb4-4dab-93d7-cbfb36284c36@github.com>
 <i8xz8qX-FNCtYM1uGqNb63t0MBTYEwlX20dfbq8HLL0=.0734d880-6cc9-41ea-a18d-0b287388e73b@github.com>
Message-ID: <nwpKH34OCPKJ5biFe6UhZ5obtqYqseRuaJFRTw4W8Dk=.6f9ab1ba-9686-4d8c-89ea-b1a98fdcfdc3@github.com>

On Wed, 16 Jul 2025 14:40:53 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> I don't know other ways to define it that don't involve the clause `!(x < 0 && n % 2 == 0)`. If the first definition is confusing, the only solution I see is to remove it, and leave only the formula `(x.signum() * floor(abs(nthRoot(x, n))))`.
>
> I think this is probably what you are searching for.
> 
> If x ? 0 there's at most one integer y ? 0 meeting y^n ? x < (y+1)^n.
> If x < 0 there's at most one integer y ? 0 meeting y^n ? x > (y-1)^n.
> The method returns y if it exists, and throws otherwise.
> As a consequence, it throws when n ? 0, or when x < 0 and n is even, and returns a result otherwise.
> 
> Can you please check?

The new definition leaves some questions open.

When the largest or smallest integer does not exist, nothing is stated.

What is meant here with "the real n-th root of x"? If it is a solution of y^n = x, then for n = x = -1 it is y = -1, so this method would need to return -1, but it throws.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2222934458

From rriggs at openjdk.org  Tue Jul 22 15:37:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Jul 2025 15:37:40 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v12]
In-Reply-To: <_xr23bKDmLusU-_TXQICLnk4Y11GBrIA5jvK-r4GL74=.97a4be69-1de6-4d18-bd2d-21ace429b985@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <eRJU5NDSnIIlE9ssz_zq_CrbyGAvaaWf7W6bzI0uDiU=.f4b4907c-ae6b-431d-81fd-bd97c1f81231@github.com>
 <yQoWs6r3QYoNoA9vfCM-DwasBs_pRFAecZulKJpKoCg=.133fb988-9647-4fb6-8102-8f82c209066e@github.com>
 <_xr23bKDmLusU-_TXQICLnk4Y11GBrIA5jvK-r4GL74=.97a4be69-1de6-4d18-bd2d-21ace429b985@github.com>
Message-ID: <xX177zY5r3FDdea_NHchW29iKE_1e3kUgBS6cl7qI3E=.869de4ff-c291-483b-9db1-710965cc54b5@github.com>

On Mon, 21 Jul 2025 11:57:38 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 279:
>> 
>>> 277:         }
>>> 278: 
>>> 279:         /// Returns a node in the JRT filesystem namespace, or null if no resource or
>> 
>> Using the standard javadoc tags for @param, @return can give some consistency and readability even for internal methods.
>
> Absolutely. This sort of thing is always a balance between clarity and conciseness. But here I think you're right so I pulled the `name` into a `@param`. I dislike doing it for the return types in most cases though, since that encourages duplication with the method's first sentence.

The {@return 1st sentence text} can be used on the first line and javadoc will put the text in both places without needing duplication in the source.  [(javadoc  tag specification](https://docs.oracle.com/en/java/javase/22/docs/specs/javadoc/doc-comment-spec.html))

>> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 611:
>> 
>>> 609:          *
>>> 610:          * <p>If this node is not a directory ({@code isDirectory() == false})
>>> 611:          * then this method will throw {@link IllegalStateException}.
>> 
>> A mismatch in overriding could give inconsistent results (since the impl does not call `isDirectory()`.
>
> True, though would you prefer to change the comment ("by default this method throws... and is overridden by directory subclasses...") or the implementation of things like `getChildNames()` so they call `isDirectory()` ?
> 
> Personally I dislike this "test and call" approach and would rather have restructured the API to be more object-oriented, and have callers use a more structured dispatch mechanism (but this would incur cost of lambdas etc.), but that's a really disruptive change.
> 
> Alternatively a type token/enum of some sort could be used to define node type. This is all internal/trusted API though, so I'm happy with trusting that things "do what they say" (it's going to be really obvious if something claims to be a directory and then throws when asks for its child names, and that's almost exclusively why anyone calls isDirectory() to start with).
> 
> So in summary, apart from maybe tweaking the comment slightly, I think this is fine as is.

I would change the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2222946949
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2222934325

From duke at openjdk.org  Tue Jul 22 15:53:00 2025
From: duke at openjdk.org (Darragh Conway)
Date: Tue, 22 Jul 2025 15:53:00 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: <Kr0ZRfZ4Om1urKEABaK8pboegDStMAcn12sbj60RPTo=.9f2d694e-8f70-4fbc-bad5-a1f5cdaa832a@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

@AlanBateman thanks for the comments I'll address those in the following issue: https://bugs.openjdk.org/browse/JDK-8363720  if that's ok with you. As I've already hit the integrate button.

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

PR Comment: https://git.openjdk.org/jdk/pull/26193#issuecomment-3103539963

From iklam at openjdk.org  Tue Jul 22 16:27:18 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Jul 2025 16:27:18 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
 [v2]
In-Reply-To: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
Message-ID: <_vFFlWeNVOvdMJINFxpATL3_gC2xFhk5MH_2KXD3ahg=.8c826ef9-d6c9-4a5c-b0f8-48a50e647db4@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.

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

 - Merge branch 'master' into 8360555-archive-all-unnamed-modules
 - 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=01
  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 darcy at openjdk.org  Tue Jul 22 16:37:59 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 22 Jul 2025 16:37:59 GMT
Subject: RFR: 8362376: Use @Stable annotation in Java FDLIBM implementation
 [v3]
In-Reply-To: <TOGyIxr5eouB2i6fUgYSeOL3VyCgNynD1iTJxnoXUIQ=.57f7d059-87a6-48e2-8eec-4540823a9499@github.com>
References: <HlWTR6VQcT5UrHGSmJmfwade3H7UDyINX8ciVMkvIjg=.99f879f6-9040-4db6-9586-c60877b9767b@github.com>
 <ZgjRJGyu9IFgCsZyFF3D1cswr9nJD3vq7hWeX6Qumdk=.a8a46b00-108f-4d0f-9d47-cb4932e07d29@github.com>
 <TOGyIxr5eouB2i6fUgYSeOL3VyCgNynD1iTJxnoXUIQ=.57f7d059-87a6-48e2-8eec-4540823a9499@github.com>
Message-ID: <okI5CkHJDjlntsCn-qICB4Uk1QzQq150zNVbp4v1F9c=.84a6b59f-d73b-4d9f-b5f2-bace3a8095af@github.com>

On Tue, 22 Jul 2025 15:20:24 GMT, Chen Liang <liach at openjdk.org> wrote:

> Re @turbanoff and @ExE-Boss's style fixes: this code is ported from the c code of fdlibm so it has a lot of irregular styles. I think we might look into updating the implementation to be more Java-ish in the future in another patch.

I'll address the array declaration syntax in the next commit on the PR. While the current state of Fdlibm.java does show its original C lineage, it has already gone through a few passes of getting it closer to idiomatic Java.

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

PR Comment: https://git.openjdk.org/jdk/pull/26341#issuecomment-3103741785

From coleenp at openjdk.org  Tue Jul 22 17:02:12 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 22 Jul 2025 17:02:12 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
 [v2]
In-Reply-To: <_vFFlWeNVOvdMJINFxpATL3_gC2xFhk5MH_2KXD3ahg=.8c826ef9-d6c9-4a5c-b0f8-48a50e647db4@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
 <_vFFlWeNVOvdMJINFxpATL3_gC2xFhk5MH_2KXD3ahg=.8c826ef9-d6c9-4a5c-b0f8-48a50e647db4@github.com>
Message-ID: <Qjok1MhxHy61Q-eIt-bY3uCbCRQjQ2cR2pLRv5grX3I=.67cdae39-7ede-46f9-b840-b7f4dbf7b2e6@github.com>

On Tue, 22 Jul 2025 16:27:18 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> 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.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into 8360555-archive-all-unnamed-modules
>  - 8360555: Archive all unnamed modules in CDS full module graph

Marked as reviewed by coleenp (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26082#pullrequestreview-3044001789

From liach at openjdk.org  Tue Jul 22 17:28:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Jul 2025 17:28:10 GMT
Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms
 [v5]
In-Reply-To: <lirArNH2rA5pWS5OGkhT15w6_dGdbt-Ds0jwrxPoC5k=.18aff583-5acf-49e7-9cbd-1a1e05fc3612@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
 <lirArNH2rA5pWS5OGkhT15w6_dGdbt-Ds0jwrxPoC5k=.18aff583-5acf-49e7-9cbd-1a1e05fc3612@github.com>
Message-ID: <8e8gKlLZ-2QXrx0C6XL2xBW0ocMYNokoI-EqVf3Ye_E=.5f22a552-1afd-448d-9378-c7f3e402bae2@github.com>

On Thu, 17 Jul 2025 18:28:04 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
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify wording

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26258#issuecomment-3103963593

From liach at openjdk.org  Tue Jul 22 17:28:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Jul 2025 17:28:10 GMT
Subject: Integrated: 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: <2n4bCzIXKBhwkWcdFqi-Lh_HlZmy9dOGXUUmMPTGtoo=.bfad1aa6-9981-4dfb-8f29-096a13680ee2@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

This pull request has now been integrated.

Changeset: ea6674fe
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea6674fec8702eea481afa7ca7e522cbacd53841
Stats:     8 lines in 2 files changed: 1 ins; 0 del; 7 mod

8315131: Clarify VarHandle set/get access on 32-bit platforms

Reviewed-by: rgiulietti, mcimadamore, jrose, shade, psandoz

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

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

From naoto at openjdk.org  Tue Jul 22 18:17:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 22 Jul 2025 18:17:55 GMT
Subject: RFR: 8361972: Clarify the condition of System.console() about
 standard input/output [v2]
In-Reply-To: <nIpdmbTaSvUxRjRO9TTrvjYg9kVVPMgYJ_WA18JOOTc=.1bc8dbca-de3e-42d9-8e2d-5d03e87b5359@github.com>
References: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
 <TKnCmtTeM0-f1yunDtO8zRno4ZbVWxhiWN0kagttFns=.3f8e4e55-84f4-4eee-924a-e04e46485c12@github.com>
 <HD9ktp88gpejD3h9DLO6HMAHiRNoTnHV-U5fW0xJPhk=.6a3b8a69-4c1b-43f5-ad6a-18f10196c70e@github.com>
 <YXJTMmkw39pSM87RT9BqXM9rwE0KHTcZF7pG3rUfvL8=.ac8e50b0-524f-4f64-8e2f-1e8999909860@github.com>
 <PMI4a2USZ3ox-Oijc6Cu2xF8tCn6b2PdjRvGcWbBYl4=.17364eb2-cd38-47ea-b7d1-9d58c62767d4@github.com>
 <nIpdmbTaSvUxRjRO9TTrvjYg9kVVPMgYJ_WA18JOOTc=.1bc8dbca-de3e-42d9-8e2d-5d03e87b5359@github.com>
Message-ID: <QujaobAwBn1CEl8PRUGGXx0k5g78TygIHDN3Hn7v9pI=.a674acd7-5418-4b25-97a0-3cc0509511f6@github.com>

On Sun, 20 Jul 2025 06:46:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Since the decision of whether a console exists is dependent on the implementation as specified,
>> 
>>> Whether a virtual machine has a console is dependent upon the underlying platform
>> 
>> And the existing wording in this paragraph uses open-ended words such as "may" and "typically", it makes sense to me that this change would follow the same style of wording. If you wanted to concretely define what this implementation does, using one of the `@impl` tags to describe the behavior could be an option?
>
> Okay, so the intent is to specify that it is implementation or configuration specific as to whether there is a Console when standard input or output, but not both, are redirected, is that right? What should users expect isTerminal to return in this case?

For the jshell case, I think it can return `true` from its `isTerminal()` as it is infact interactive environment. That means all the Console implementations return `true` so that we can replace that "may not have a Console" with "will not have a Console", which is clearer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26299#discussion_r2223438918

From pminborg at openjdk.org  Tue Jul 22 18:21:00 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Jul 2025 18:21:00 GMT
Subject: RFR: 8345292: Improve javadocs for MemorySegment::getStrings
 defining word boundary cases [v5]
In-Reply-To: <phBZll-SVauXppPx18CrOUu9JmwRsLDhOKdAeEVTUxA=.fa5a5068-a96e-4d61-89d8-fcd49bd5b6ba@github.com>
References: <is-opTo3YMk60P4Qo3vpOu1tgFuzeIwzGTDrXl3NxCs=.d84d3229-982c-4b95-a755-ad4462c80282@github.com>
 <phBZll-SVauXppPx18CrOUu9JmwRsLDhOKdAeEVTUxA=.fa5a5068-a96e-4d61-89d8-fcd49bd5b6ba@github.com>
Message-ID: <94KgBytKHEbo4kOBxd3Uwkc51Ygdww5V0SUi09UMuzo=.d82b98d8-5463-4d8d-9686-0100560b6846@github.com>

On Mon, 16 Jun 2025 16:58:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve the 'MemorySegment.getString(long offset, Charset charset)` method documentation with respect to multi-octet concerns.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove imp note
>  - Add text on N octets

keep alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/25715#issuecomment-3104216165

From pminborg at openjdk.org  Tue Jul 22 18:22:04 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Jul 2025 18:22:04 GMT
Subject: RFR: 8357531: The `SegmentBulkOperations::fill` method can be
 improved using overlaps [v9]
In-Reply-To: <eSigRXfWIK7P5KZaDDT9-6euHDK3gUwf7draTv_PnAA=.9f1f2518-6ac4-4991-9b39-6bb03806c0dd@github.com>
References: <JkAQUQngSmK8lqK5Tg7Lc8azydc77zNXJpRCT6T_CrM=.b3dccac6-04b2-4512-9d5f-a75c05489ca0@github.com>
 <eSigRXfWIK7P5KZaDDT9-6euHDK3gUwf7draTv_PnAA=.9f1f2518-6ac4-4991-9b39-6bb03806c0dd@github.com>
Message-ID: <A-DTGKbz_qmxrRsmmAUHhW6-KsEc2PN_fUMCbjtgBGI=.03eee652-46ce-44cb-94f5-678cbf039f21@github.com>

On Tue, 10 Jun 2025 17:31:20 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR builds on a concept John Rose told me about some time ago. Instead of combining memory operations of various sizes, a single large and skewed memory operation can be made to clean up the tail of remaining bytes.
>> 
>> This has the effect of simplifying and shortening the code. The number of branches to evaluate is reduced.
>> 
>> It should be noted that the performance of the fill operation affects the allocation of new segments (as they are zeroed out before being returned to the client code).
>> 
>> This PR passes tier1, tier2, and tier3 on multiple platforms.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Use Unsafe directly in benchmarks
>  - Merge branch 'master' into fill-overlap
>  - Use a fixed threashold for fill
>  - Fix benchmark
>  - Merge branch 'master' into fill-overlap
>  - Merge branch 'master' into fill-overlap
>  - Update test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkFill.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update benchmark to reflect new fill method
>  - Simplify
>  - Add case for long operations and break out methods
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/621294d7...c2583a50

keep alive

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

PR Comment: https://git.openjdk.org/jdk/pull/25383#issuecomment-3104220960

From kcr at openjdk.org  Tue Jul 22 18:39:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 18:39:53 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <3jmBibdv4ZqVjUF9FI7KNvJ2H3siKn2H-WivoPRaWXw=.f399ac98-c29d-46a2-9c39-7ec5cd691623@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <3jmBibdv4ZqVjUF9FI7KNvJ2H3siKn2H-WivoPRaWXw=.f399ac98-c29d-46a2-9c39-7ec5cd691623@github.com>
Message-ID: <4YzUhJJKnuwc6-nZe7m-PHszEBfhGhb4s2YRW-DmTc0=.27cf04dd-69f6-492e-ae6f-5a001740c877@github.com>

On Tue, 22 Jul 2025 15:06:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I did a quick scan and the updates to the conf, the removal, and the test changes look okay. Happy to review the CSR when you have it ready.

Thanks. The CSR is now ready to review: https://bugs.openjdk.org/browse/JDK-8362628

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

PR Comment: https://git.openjdk.org/jdk/pull/26393#issuecomment-3104282605

From duke at openjdk.org  Tue Jul 22 18:41:03 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 22 Jul 2025 18:41:03 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <nwpKH34OCPKJ5biFe6UhZ5obtqYqseRuaJFRTw4W8Dk=.6f9ab1ba-9686-4d8c-89ea-b1a98fdcfdc3@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <B8rouVL6Ecjm0lIqzwSjvhICoV_QonD06LqMZ853tFw=.575fe02c-f7b5-4f46-857a-c591a62a1bcd@github.com>
 <pU242ecdIxZSk-uXlfSiXjMX-xNZFq_R6H4kklT1Klw=.27929cce-dcb4-4dab-93d7-cbfb36284c36@github.com>
 <i8xz8qX-FNCtYM1uGqNb63t0MBTYEwlX20dfbq8HLL0=.0734d880-6cc9-41ea-a18d-0b287388e73b@github.com>
 <nwpKH34OCPKJ5biFe6UhZ5obtqYqseRuaJFRTw4W8Dk=.6f9ab1ba-9686-4d8c-89ea-b1a98fdcfdc3@github.com>
Message-ID: <6-t3qbPv3VTIBYUG-S0pSdgnDoqSEwqsjDeUUFaXfW0=.356b89f5-087e-45c5-927d-cb7c93a8cc3e@github.com>

On Tue, 22 Jul 2025 15:26:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> I think this is probably what you are searching for.
>> 
>> If x ? 0 there's at most one integer y ? 0 meeting y^n ? x < (y+1)^n.
>> If x < 0 there's at most one integer y ? 0 meeting y^n ? x > (y-1)^n.
>> The method returns y if it exists, and throws otherwise.
>> As a consequence, it throws when n ? 0, or when x < 0 and n is even, and returns a result otherwise.
>> 
>> Can you please check?
>
> The new definition leaves some questions open.
> 
> When the largest or smallest integer does not exist, nothing is stated.
> 
> What is meant here with "the real n-th root of x"? If it is a solution of y^n = x, then for n = x = -1 it is y = -1, so this method would need to return -1, but it throws.

@rgiulietti 
> When the largest or smallest integer does not exist, nothing is stated.

The cases in which the method throws correspond to the cases in which the integer root is not defined.

> What is meant here with "the real n-th root of x"? If it is a solution of y^n = x, then for n = x = -1 it is y = -1, so this method would need to return -1, but it throws.

By "the real n-th root of x" is meant the usual definition of "principal nth root", namely the only solution of $y^n = x$ for $y \in (-\infty; + \infty)$ that is concordant with the signum of $x$, if it exists. For the specification, the equivalence of the definition with the formula $\mathrm{signum}(x) \cdot \lfloor|\sqrt[n]{x}| \rfloor$ makes sense only when the definition itself makes sense, i.e. only when the method does not throw.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2223489445

From kcr at openjdk.org  Tue Jul 22 18:47:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 18:47:00 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
Message-ID: <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>

On Tue, 22 Jul 2025 15:13:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
>> 
>> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
>> 
>> 
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
>> src/jdk.compiler/share/data/symbols/symbols
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
>> test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list
>> 
>> 
>> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.
>
> test/langtools/jdk/javadoc/doclet/testModules/jdk/element-list line 305:
> 
>> 303: jdk.jshell.spi
>> 304: jdk.jshell.tool
>> 305: module:jdk.jsobject
> 
> There is a similar pair in test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list.
> Can it be removed? Unless it causes a test failure.

I wondered about that, and originally was going to remove it, but then noticed that the test in question parses the JDK 17 API docs (which does have the `jdk.jsobject` module).

https://github.com/openjdk/jdk/blob/e70c702d6f864b494dc7df3eea4f1a317a3bc981/test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java#L55-56


    private static final String externalDocs =
        "https://docs.oracle.com/en/java/javase/17/docs/api";


I suspect that the test will run just fine if I remove it. I don't mind either way. What would you recommend?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2223507650

From rriggs at openjdk.org  Tue Jul 22 18:51:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Jul 2025 18:51:55 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
 <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
Message-ID: <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>

On Tue, 22 Jul 2025 18:44:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> test/langtools/jdk/javadoc/doclet/testModules/jdk/element-list line 305:
>> 
>>> 303: jdk.jshell.spi
>>> 304: jdk.jshell.tool
>>> 305: module:jdk.jsobject
>> 
>> There is a similar pair in test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list.
>> Can it be removed? Unless it causes a test failure.
>
> I wondered about that, and originally was going to remove it, but then noticed that the test in question parses the JDK 17 API docs (which does have the `jdk.jsobject` module).
> 
> https://github.com/openjdk/jdk/blob/e70c702d6f864b494dc7df3eea4f1a317a3bc981/test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java#L55-56
> 
> 
>     private static final String externalDocs =
>         "https://docs.oracle.com/en/java/javase/17/docs/api";
> 
> 
> I suspect that the test will run just fine if I remove it. I don't mind either way. What would you recommend?

I ran the test and then removed those lines and the test still passed.
I'd remove them to avoiding leaving a (little) mess behind.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2223524163

From kcr at openjdk.org  Tue Jul 22 19:43:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 19:43:55 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
 <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
 <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>
Message-ID: <kS1L5BXHrQhg2Ear1fgxGJoRFAF5_cm_mybVY2iuksQ=.e20c4f19-328a-4448-9fa0-3d53067f14d2@github.com>

On Tue, 22 Jul 2025 18:48:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I wondered about that, and originally was going to remove it, but then noticed that the test in question parses the JDK 17 API docs (which does have the `jdk.jsobject` module).
>> 
>> https://github.com/openjdk/jdk/blob/e70c702d6f864b494dc7df3eea4f1a317a3bc981/test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java#L55-56
>> 
>> 
>>     private static final String externalDocs =
>>         "https://docs.oracle.com/en/java/javase/17/docs/api";
>> 
>> 
>> I suspect that the test will run just fine if I remove it. I don't mind either way. What would you recommend?
>
> I ran the test and then removed those lines and the test still passed.
> I'd remove them to avoiding leaving a (little) mess behind.

As expected, the above test passes fine if I remove the jsobject entries from `test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list`. I'll go ahead and remove them, since it seems like good cleanup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2223678605

From naoto at openjdk.org  Tue Jul 22 19:45:08 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 22 Jul 2025 19:45:08 GMT
Subject: RFR: 8361972: Clarify the condition of System.console() about
 standard input/output [v3]
In-Reply-To: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
References: <S-GpeSUzcrTebLBs0xGtQIG2l-EK-dYsGeqMqGPg0OA=.9f0da3b9-a7af-4a40-9057-2ce1cc20d97a@github.com>
Message-ID: <QFcHWkQagwX0N-Et76i2Sz5ofKR0_0yH4f6cHNVoUok=.f2badc58-b17f-4011-8f37-29c0a7c867b1@github.com>

> This accompanies the fix for [JDK-8361613](https://bugs.openjdk.org/browse/JDK-8361613), which restricts `System.console()` to return a `Console` instance only when both standard input and output are connected to a terminal. The change here is solely a specification clarification and tightening of the `java.io.Console` javadoc to reflect this behavior. We are separating the spec clarification because the fix itself may be backported to prior LTS releases without requiring a Maintenance Review process.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Wording change, isTerminal() always returns true
 - Merge branch 'master' into JDK-8361972-System-console-condition
 - Wording modification
 - initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26299/files
  - new: https://git.openjdk.org/jdk/pull/26299/files/e2a64c95..a3b39049

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26299&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26299&range=01-02

  Stats: 20447 lines in 622 files changed: 13483 ins; 4316 del; 2648 mod
  Patch: https://git.openjdk.org/jdk/pull/26299.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26299/head:pull/26299

PR: https://git.openjdk.org/jdk/pull/26299

From kcr at openjdk.org  Tue Jul 22 19:53:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 19:53:39 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
Message-ID: <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>

> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
> 
> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
> 
> 
> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
> src/jdk.compiler/share/data/symbols/symbols
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
> 
> 
> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Remove jdk.jsobject from one more test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26393/files
  - new: https://git.openjdk.org/jdk/pull/26393/files/e70c702d..2858cd3e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26393&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26393&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26393.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26393/head:pull/26393

PR: https://git.openjdk.org/jdk/pull/26393

From rriggs at openjdk.org  Tue Jul 22 19:55:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Jul 2025 19:55:55 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
Message-ID: <-GRJ-l0avR6jYVCgrpu6s1wDdNzxpfrpxDFb__T-X8M=.c8d7e16c-cc62-4fd2-a6b0-7d8f2add3871@github.com>

On Tue, 22 Jul 2025 19:53:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
>> 
>> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
>> 
>> 
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
>> src/jdk.compiler/share/data/symbols/symbols
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
>> 
>> 
>> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove jdk.jsobject from one more test

look good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26393#pullrequestreview-3044678258

From iris at openjdk.org  Tue Jul 22 20:15:56 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 22 Jul 2025 20:15:56 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
Message-ID: <riykbCOmZWw8xZyznbpjn_f9Zk1tppnltpXdS3jwfvo=.bdb4180d-d2c1-4bee-85fb-e6df77bfd5d6@github.com>

On Tue, 22 Jul 2025 19:53:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
>> 
>> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
>> 
>> 
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
>> src/jdk.compiler/share/data/symbols/symbols
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
>> 
>> 
>> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove jdk.jsobject from one more test

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26393#pullrequestreview-3044742971

From iklam at openjdk.org  Tue Jul 22 20:20:05 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Jul 2025 20:20:05 GMT
Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph
 [v2]
In-Reply-To: <Qjok1MhxHy61Q-eIt-bY3uCbCRQjQ2cR2pLRv5grX3I=.67cdae39-7ede-46f9-b840-b7f4dbf7b2e6@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
 <_vFFlWeNVOvdMJINFxpATL3_gC2xFhk5MH_2KXD3ahg=.8c826ef9-d6c9-4a5c-b0f8-48a50e647db4@github.com>
 <Qjok1MhxHy61Q-eIt-bY3uCbCRQjQ2cR2pLRv5grX3I=.67cdae39-7ede-46f9-b840-b7f4dbf7b2e6@github.com>
Message-ID: <gDKXK7PuCQYRK-ZbSHVDOgdHVmtOsZhqtXFOuuhJZXw=.48d21c3e-1534-4968-b45f-5caf8adaef07@github.com>

On Tue, 22 Jul 2025 16:59:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into 8360555-archive-all-unnamed-modules
>>  - 8360555: Archive all unnamed modules in CDS full module graph
>
> Marked as reviewed by coleenp (Reviewer).

Thanks @coleenp and @iwanowww for the review
Passed tiers 1-4 and builds-tier-5

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26082#issuecomment-3104700644

From iklam at openjdk.org  Tue Jul 22 20:20:06 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Jul 2025 20:20:06 GMT
Subject: Integrated: 8360555: Archive all unnamed modules in CDS full module
 graph
In-Reply-To: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
References: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>
Message-ID: <qKrT8MaARdUaoXNN2HMBfN5O80tB6Af22_FdUCJpz5w=.6d2d7d31-e3bd-48a4-bd73-7bce4014628a@github.com>

On Wed, 2 Jul 2025 00:18:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> 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.

This pull request has now been integrated.

Changeset: aae99022
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aae9902234d36049ec99a2f50934c526dd6235eb
Stats:     187 lines in 13 files changed: 140 ins; 17 del; 30 mod

8360555: Archive all unnamed modules in CDS full module graph

Reviewed-by: coleenp, vlivanov

-------------

PR: https://git.openjdk.org/jdk/pull/26082

From rgiulietti at openjdk.org  Tue Jul 22 20:21:58 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 22 Jul 2025 20:21:58 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <6-t3qbPv3VTIBYUG-S0pSdgnDoqSEwqsjDeUUFaXfW0=.356b89f5-087e-45c5-927d-cb7c93a8cc3e@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <B8rouVL6Ecjm0lIqzwSjvhICoV_QonD06LqMZ853tFw=.575fe02c-f7b5-4f46-857a-c591a62a1bcd@github.com>
 <pU242ecdIxZSk-uXlfSiXjMX-xNZFq_R6H4kklT1Klw=.27929cce-dcb4-4dab-93d7-cbfb36284c36@github.com>
 <i8xz8qX-FNCtYM1uGqNb63t0MBTYEwlX20dfbq8HLL0=.0734d880-6cc9-41ea-a18d-0b287388e73b@github.com>
 <nwpKH34OCPKJ5biFe6UhZ5obtqYqseRuaJFRTw4W8Dk=.6f9ab1ba-9686-4d8c-89ea-b1a98fdcfdc3@github.com>
 <6-t3qbPv3VTIBYUG-S0pSdgnDoqSEwqsjDeUUFaXfW0=.356b89f5-087e-45c5-927d-cb7c93a8cc3e@github.com>
Message-ID: <5dbp5Nw7Gd008HqNR32In9aFwnh1qhhVMCUGfHpckLI=.a354dbd8-b0c0-47b4-a9d4-21cc9d8c35ef@github.com>

On Tue, 22 Jul 2025 18:38:28 GMT, fabioromano1 <duke at openjdk.org> wrote:

> The cases in which the method throws correspond to the cases in which the integer root is not defined.

Yes, that's why it should be part of the definition: like in "the largest integer ..., if it exists; otherwise the result is undefined, and the method throws".

Specified this way, one `@throws` clause for undefined r would be sufficient. The implementation can still generate different messages, but this is not part of the spec.

> For the specification, the equivalence of the definition with the formula ... makes sense only when the definition itself makes sense, i.e. only when the method does not throw.

IMO, this could be expressed more clearly as "when r is defined, it is equal to ..." or something similar.

(As an aside, if R is taken as a subfield of C, the principal value of the nth root needs not be real, even in the case of odd n > 0. That's why I asked about the meaning of nth root here. And even "principal value" doesn't have a universally accepted definition, as it depends on the choice of the range for the "principal" phase angle of a complex number.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2223746548

From jlu at openjdk.org  Tue Jul 22 21:31:54 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 22 Jul 2025 21:31:54 GMT
Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system
 property
In-Reply-To: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
Message-ID: <iXd3i9lryb6yfkEKMbtKNInv3sEt7DhtfMWCHIOD_r0=.f0bdd239-04f5-403a-9995-23f679647dc9@github.com>

On Mon, 21 Jul 2025 22:56:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well

Should we also remove the test method, `ModuleTestUtil.runModuleWithLegacyCode` which passes the now defunct property to the process.

test/jdk/java/util/Locale/UseOldISOCodesTest.java line 56:

> 54:         public static void main(String[] args) {
> 55:             // Ensure java.locale.useOldISOCodes should have no effect
> 56:             System.setProperty("java.locale.useOldISOCodes", "false");

IMO, it seems weird to keep this line in the test, even if it has no effect. The original goal was to ensure the property only had impact when set during startup. The current test is no longer concerned with that (since the property no longer performs any mapping).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26419#pullrequestreview-3044862073
PR Review Comment: https://git.openjdk.org/jdk/pull/26419#discussion_r2223817468

From naoto at openjdk.org  Tue Jul 22 22:01:10 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 22 Jul 2025 22:01:10 GMT
Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system
 property [v2]
In-Reply-To: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
Message-ID: <JmVCWsuR4iMeps-Tn1dktb2vROto9Ya3tKyZvU8Mza4=.0eb01a02-0dc8-4096-a549-626de2cecfae@github.com>

> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26419/files
  - new: https://git.openjdk.org/jdk/pull/26419/files/85d8adfb..bcfd8a7e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26419&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26419&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26419.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26419/head:pull/26419

PR: https://git.openjdk.org/jdk/pull/26419

From duke at openjdk.org  Tue Jul 22 22:04:05 2025
From: duke at openjdk.org (Darragh Conway)
Date: Tue, 22 Jul 2025 22:04:05 GMT
Subject: Integrated: 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: <oTvV9zp6E8ZlcCG1nmNCV4PxFqMPhQqBAuCAeHIJcFw=.2662e2f7-d740-4253-a0b3-64c8dd0549ac@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

This pull request has now been integrated.

Changeset: 016694bf
Author:    DarraghConway <darragh.conway at oracle.com>
Committer: Mark Sheppard <msheppar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/016694bf74f6920f850330e353df9fd03458cca1
Stats:     20 lines in 1 file changed: 11 ins; 7 del; 2 mod

8360411: [TEST] open/test/jdk/java/io/File/MaxPathLength.java Refactor extract method to encapsulate Windows specific test logic

Reviewed-by: msheppar

-------------

PR: https://git.openjdk.org/jdk/pull/26193

From naoto at openjdk.org  Tue Jul 22 22:06:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 22 Jul 2025 22:06:55 GMT
Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system
 property [v2]
In-Reply-To: <iXd3i9lryb6yfkEKMbtKNInv3sEt7DhtfMWCHIOD_r0=.f0bdd239-04f5-403a-9995-23f679647dc9@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
 <iXd3i9lryb6yfkEKMbtKNInv3sEt7DhtfMWCHIOD_r0=.f0bdd239-04f5-403a-9995-23f679647dc9@github.com>
Message-ID: <x8kej_gf5CYTd3ODoNqU_Xze6myBzeqCj-HOMp576hY=.8dc0f007-52cd-4ceb-9ee8-b3c3df22c6ba@github.com>

On Tue, 22 Jul 2025 21:29:06 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Should we also remove the test method, `ModuleTestUtil.runModuleWithLegacyCode` which passes the now defunct property to the process.

I thought about that, but decided to leave it as it is, just to make sure everything works as before. For the same reason, I did not remove the `-Djava.locale.useOldISOCodes=true` run in LocaleTest.java

> test/jdk/java/util/Locale/UseOldISOCodesTest.java line 56:
> 
>> 54:         public static void main(String[] args) {
>> 55:             // Ensure java.locale.useOldISOCodes should have no effect
>> 56:             System.setProperty("java.locale.useOldISOCodes", "false");
> 
> IMO, it seems weird to keep this line in the test, even if it has no effect. The original goal was to ensure the property only had impact when set during startup. The current test is no longer concerned with that (since the property no longer performs any mapping).

Right. I re-purposed the test but as you mentioned, the line is confusing. Removed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26419#issuecomment-3104958671
PR Review Comment: https://git.openjdk.org/jdk/pull/26419#discussion_r2223912809

From jlu at openjdk.org  Tue Jul 22 22:11:55 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 22 Jul 2025 22:11:55 GMT
Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system
 property [v2]
In-Reply-To: <JmVCWsuR4iMeps-Tn1dktb2vROto9Ya3tKyZvU8Mza4=.0eb01a02-0dc8-4096-a549-626de2cecfae@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
 <JmVCWsuR4iMeps-Tn1dktb2vROto9Ya3tKyZvU8Mza4=.0eb01a02-0dc8-4096-a549-626de2cecfae@github.com>
Message-ID: <atKdR9Fp82Uwsv6Por_NJP8tNoFHw1yet6-2atW7Kjk=.c73b2a9a-6e32-4ccf-ba22-ef2a5fd64b74@github.com>

On Tue, 22 Jul 2025 22:01:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

src/java.base/share/classes/sun/util/locale/BaseLocale.java line 181:

> 179:     }
> 180: 
> 181:     public static String convertOldISOCodes(String language) {

It was there before this change, but above on line 166 I think we should update the outdated comment,

> // JDK uses deprecated ISO639.1 language codes for he, yi and id

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26419#discussion_r2223920817

From duke at openjdk.org  Tue Jul 22 22:21:51 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 22 Jul 2025 22:21:51 GMT
Subject: RFR: 8077587: BigInteger Roots [v35]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <rDuvSZsqA4NUv59kbnZSAJ6jXGjeCtBv8MRf0qDCy-0=.80b07a28-465f-410f-bc97-3581a4a0f4d1@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'nth-root-branch' of https://github.com/fabioromano1/jdk into nth-root-branch
 - Refinement of javadoc for nth root

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/3d1705d0..a98f91c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=33-34

  Stats: 8 lines in 1 file changed: 2 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From naoto at openjdk.org  Tue Jul 22 22:25:33 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 22 Jul 2025 22:25:33 GMT
Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system
 property [v3]
In-Reply-To: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
Message-ID: <Z3ELpLYL59qXREH7jThXieIAXFwYSUEyrAztdHdFAdo=.4489f709-641a-4771-9e9f-b0d814e5cb79@github.com>

> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Obsolete comment correction

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26419/files
  - new: https://git.openjdk.org/jdk/pull/26419/files/bcfd8a7e..93f3a8b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26419&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26419&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26419.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26419/head:pull/26419

PR: https://git.openjdk.org/jdk/pull/26419

From jlu at openjdk.org  Tue Jul 22 22:25:33 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 22 Jul 2025 22:25:33 GMT
Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system
 property [v3]
In-Reply-To: <Z3ELpLYL59qXREH7jThXieIAXFwYSUEyrAztdHdFAdo=.4489f709-641a-4771-9e9f-b0d814e5cb79@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
 <Z3ELpLYL59qXREH7jThXieIAXFwYSUEyrAztdHdFAdo=.4489f709-641a-4771-9e9f-b0d814e5cb79@github.com>
Message-ID: <Dxyj9FWnmW13ckUS5wgACLyNOWvuHHciZOFvsdYrD5A=.21891475-6a9b-4db5-9a69-455a12054dc6@github.com>

On Tue, 22 Jul 2025 22:22:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Obsolete comment correction

LGTM

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26419#pullrequestreview-3045036200

From chris.w.dennis at gmail.com  Tue Jul 22 23:00:40 2025
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Tue, 22 Jul 2025 19:00:40 -0400
Subject: ClassLoader Leak via Executors.newSingleThreadExecutor(...)
In-Reply-To: <CAM1ck5hxkfw4ONPJwopKiuwLtUYD=j9zd7vkFpMrKb5Zv2OvGg@mail.gmail.com>
References: <CAM1ck5hB3ym3dt8wAp3uQer5W=9=uboU6azgkCtMJji9ovnBBg@mail.gmail.com>
 <f02c0d49-9199-4061-90cd-f9dce54e13c3@oracle.com>
 <CAM1ck5hxkfw4ONPJwopKiuwLtUYD=j9zd7vkFpMrKb5Zv2OvGg@mail.gmail.com>
Message-ID: <CAM1ck5guQ8MtK2UwKjLq0URyfFZNj2bUy+CrBdNxmda67951sQ@mail.gmail.com>

Is there a process I can (or should?) be following to get my PR for fixing
this through OCA verification, or do I just need to be a little more
patient?

Thanks,

Chris

On Tue, 15 Jul 2025 at 07:59, Chris Dennis <chris.w.dennis at gmail.com> wrote:

> Apologies, that description is pretty lousy. A more explicit description
> of the leak (the one in my test in
> https://github.com/openjdk/jdk/pull/26296) would be: A class loaded by
> classloader 'C' statically references an Executor created via
> newSingleThreadExecutor(threadFactory). The ThreadFactory is an instance of
> a class also loaded by 'C'. This executor is then shutdown via
> shutdownNow(). The resulting structure will pin the classloader 'C' in
> memory.
>
> Chris
>
> On Tue, 15 Jul 2025 at 06:50, Alan Bateman <alan.bateman at oracle.com>
> wrote:
>
>> On 11/07/2025 15:42, Chris Dennis wrote:
>> > Hi All,
>> >
>> > I believe I've identified a bug in
>> > Executors.AutoShutdownDelegatedExecutorService that can trigger a
>> > classloader leak even in the presence of "correct" Executor
>> > lifecycling. AutoShutdownDelegatedExecutorService only unlinks the
>> > PhantomReference used for cleanup handling when it is shutdown via the
>> > shutdown() method. If an Executor wrapped in this way is instead
>> > shutdown using the shutdownNow() method and it references a
>> > classloader via an injected attribute: ThreadFactory, AbortPolicy,
>> > etc. then the cleanup action will reference the classloader, and the
>> > classloader will remain strongly referenced. Adding an additional
>> > override as shown in the attached patch is sufficient to fix the leak
>> > in my testing.
>> >
>> It would be useful if you could say more about the scenario. The cleaner
>> should execute once the executor service is eligible to be GC'ed and the
>> reference is queued. Invoking shutdown just means it is early
>> unregistered. So I'm wondering if your issue is more about timing in
>> that it's not being GC'ed in a timely manner.
>>
>> -Alan
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250722/33ab5077/attachment.htm>

From liach at openjdk.org  Wed Jul 23 04:04:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Jul 2025 04:04:53 GMT
Subject: RFR: 8361638: java.lang.classfile.CodeBuilder.catchingAll doesn't
 throw IllegalArgumentException if an existing catch block catches all
 exceptions
In-Reply-To: <EsgujIABpxOwwcDzA9fsWpfB9YMY0XIzlmJIFwipVXY=.8f40bdea-49b4-468b-83df-b22951a23d41@github.com>
References: <EsgujIABpxOwwcDzA9fsWpfB9YMY0XIzlmJIFwipVXY=.8f40bdea-49b4-468b-83df-b22951a23d41@github.com>
Message-ID: <V9cvaajFZpwZRfCVmukkIwrA5nYG8S5N83kmaGIins8=.ac7cef5b-502b-4aa1-922b-b610b2e83a73@github.com>

On Thu, 17 Jul 2025 16:50:33 GMT, Chen Liang <liach at openjdk.org> wrote:

> The detection of catch builder arguments is not working for catch-all blocks. Update this to track CP indices including 0 so we can more easily validate the incoming ClassDesc are all non-primitive and there is no duplicate.

This will update to remove the IAE clauses and behavior, which requires a CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26372#issuecomment-3105598351

From liach at openjdk.org  Wed Jul 23 04:11:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Jul 2025 04:11:07 GMT
Subject: [jdk25] RFR: 8315131: Clarify VarHandle set/get access on 32-bit
 platforms
Message-ID: <0uABTBFyAvVk-sD0us6ovyZS142Yu9ZBLvYSEduv5P4=.852da2c3-abe6-4d96-852f-d68c7349ea0d@github.com>

JDK-8315131 addresses a doc-only mistake present on release 25. Since this is doc-only, this is eligible for backport, and its CSR is approved for release 25 too. See #26258 for the original PR review.

-------------

Commit messages:
 - Backport ea6674fec8702eea481afa7ca7e522cbacd53841

Changes: https://git.openjdk.org/jdk/pull/26438/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26438&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315131
  Stats: 8 lines in 2 files changed: 1 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26438/head:pull/26438

PR: https://git.openjdk.org/jdk/pull/26438

From dholmes at openjdk.org  Wed Jul 23 04:39:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Jul 2025 04:39:54 GMT
Subject: RFR: 8362889: [GCC static analyzer] leak in
 libstringPlatformChars.c [v4]
In-Reply-To: <VI2_0y_t67Q04GDM-cZlUuulIrgJvT_a9_i4i2cnDZk=.47dba761-5225-4faa-8224-a26f38cf4cae@github.com>
References: <ordEhGmC8cdl8LQKu-tmqNlvKSAK3ek3FUH6TMnpc-M=.b8c73a08-d65d-42ee-82a7-f3a0fd95d4db@github.com>
 <VI2_0y_t67Q04GDM-cZlUuulIrgJvT_a9_i4i2cnDZk=.47dba761-5225-4faa-8224-a26f38cf4cae@github.com>
Message-ID: <CcfIDQORCmnhzYomDWuHRavVbTX4i9d_nFz70rCdWfA=.823f229f-41a6-45c1-ad93-19cd9424ef32@github.com>

On Tue, 22 Jul 2025 14:01:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> This is reported by the gcc static analyzer (-fanalyzer); it is just test coding so not very critical but probably should still be adjusted .
>> 
>> 
>> /jdk/test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c:74:12: warning: leak of 'str' [CWE-401] [-Wanalyzer-malloc-leak]
>>    74 | return JNU_NewStringPlatform(env, str);
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add ReleasePrimitiveArrayCritical

LGMT. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26415#pullrequestreview-3045568228

From alanb at openjdk.org  Wed Jul 23 05:57:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Jul 2025 05:57:56 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
Message-ID: <fbETTwthRh0Si0UEVuXz19SyNsot077gwkVtOJKTnm4=.2c286921-0f84-487b-8133-4d4b3e667963@github.com>

On Tue, 22 Jul 2025 19:53:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
>> 
>> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
>> 
>> 
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
>> src/jdk.compiler/share/data/symbols/symbols
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
>> 
>> 
>> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove jdk.jsobject from one more test

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26393#pullrequestreview-3045747196

From alanb at openjdk.org  Wed Jul 23 05:57:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Jul 2025 05:57:57 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <kS1L5BXHrQhg2Ear1fgxGJoRFAF5_cm_mybVY2iuksQ=.e20c4f19-328a-4448-9fa0-3d53067f14d2@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
 <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
 <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>
 <kS1L5BXHrQhg2Ear1fgxGJoRFAF5_cm_mybVY2iuksQ=.e20c4f19-328a-4448-9fa0-3d53067f14d2@github.com>
Message-ID: <3u6pXBfNO_0Jv6ncXqPzfEwAlMYACUs8n4hBCzVJySA=.c767eace-8e78-4449-af6a-056751167982@github.com>

On Tue, 22 Jul 2025 19:41:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I ran the test and then removed those lines and the test still passed.
>> I'd remove them to avoiding leaving a (little) mess behind.
>
> As expected, the above test passes fine if I remove the jsobject entries from `test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list`. I'll go ahead and remove them, since it seems like good cleanup.

@hns Would it be possible to confirm that it's okay to remove this from the doclet tests?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2224453194

From jai.forums2013 at gmail.com  Wed Jul 23 06:38:36 2025
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 23 Jul 2025 12:08:36 +0530
Subject: ClassLoader Leak via Executors.newSingleThreadExecutor(...)
In-Reply-To: <CAM1ck5guQ8MtK2UwKjLq0URyfFZNj2bUy+CrBdNxmda67951sQ@mail.gmail.com>
References: <CAM1ck5hB3ym3dt8wAp3uQer5W=9=uboU6azgkCtMJji9ovnBBg@mail.gmail.com>
 <f02c0d49-9199-4061-90cd-f9dce54e13c3@oracle.com>
 <CAM1ck5hxkfw4ONPJwopKiuwLtUYD=j9zd7vkFpMrKb5Zv2OvGg@mail.gmail.com>
 <CAM1ck5guQ8MtK2UwKjLq0URyfFZNj2bUy+CrBdNxmda67951sQ@mail.gmail.com>
Message-ID: <d173b368-5241-4bbc-913c-b4db8ea8829d@gmail.com>

Hello Chris,

In the past the OCA verification has sometimes taken more than a week or 
two, so please wait a few more days for the verification to be completed.

-Jaikiran

On 23/07/25 4:30 am, Chris Dennis wrote:
> Is there a process I can (or should?) be following to get my PR for 
> fixing this?through OCA verification, or do I just need to be a little 
> more patient?
>
> Thanks,
>
> Chris
>
> On Tue, 15 Jul 2025 at 07:59, Chris Dennis <chris.w.dennis at gmail.com> 
> wrote:
>
>     Apologies, that description is pretty lousy. A more explicit
>     description of the leak (the one in my test in
>     https://github.com/openjdk/jdk/pull/26296) would be: A class
>     loaded by classloader 'C' statically references an Executor
>     created via newSingleThreadExecutor(threadFactory). The
>     ThreadFactory is an instance of a class also loaded by 'C'. This
>     executor is then shutdown via shutdownNow(). The resulting
>     structure will pin the classloader 'C' in memory.
>
>     Chris
>
>     On Tue, 15 Jul 2025 at 06:50, Alan Bateman
>     <alan.bateman at oracle.com> wrote:
>
>         On 11/07/2025 15:42, Chris Dennis wrote:
>         > Hi All,
>         >
>         > I believe I've identified a bug in
>         > Executors.AutoShutdownDelegatedExecutorService that can
>         trigger a
>         > classloader leak even in the presence of "correct" Executor
>         > lifecycling. AutoShutdownDelegatedExecutorService only
>         unlinks the
>         > PhantomReference used for?cleanup handling when it is
>         shutdown via the
>         > shutdown() method. If an Executor wrapped in this way is
>         instead
>         > shutdown using the shutdownNow() method and it references a
>         > classloader via an injected attribute: ThreadFactory,
>         AbortPolicy,
>         > etc. then the cleanup action will reference the classloader,
>         and the
>         > classloader will remain strongly referenced. Adding an
>         additional
>         > override as shown in the attached patch is sufficient to fix
>         the leak
>         > in my testing.
>         >
>         It would be useful if you could say more about the scenario.
>         The cleaner
>         should execute once the executor service is eligible to be
>         GC'ed and the
>         reference is queued. Invoking shutdown just means it is early
>         unregistered. So I'm wondering if your issue is more about
>         timing in
>         that it's not being GC'ed in a timely manner.
>
>         -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250723/a44e64d5/attachment.htm>

From alanb at openjdk.org  Wed Jul 23 06:48:02 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Jul 2025 06:48:02 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v13]
In-Reply-To: <J-JqNtmP25GS9ovkcbl-IWtEZ2Oa8iGSROlZTuVAHJQ=.7c38d62a-020c-4edc-baac-c42833e5ca97@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <J-JqNtmP25GS9ovkcbl-IWtEZ2Oa8iGSROlZTuVAHJQ=.7c38d62a-020c-4edc-baac-c42833e5ca97@github.com>
Message-ID: <ER3v_je0TyvgB2Jlnz2pQu0Spwuvva2dcog79VHAuKc=.d407cf55-4d16-4207-a7bf-ca1485c47dc1@github.com>

On Mon, 21 Jul 2025 12:03: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...
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback changes.

The updates to SystemModuleFinder look okay, just need some cleanup.

src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 259:

> 257:         ImageReader reader = SystemImage.reader();
> 258:         try {
> 259:             return reader.findNode("/modules").getChildNames().map(mn -> readModuleAttributes(reader, mn));

Can you put the line over 3 lines so that it's easier to see the pipeline.

src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 265:

> 263:     }
> 264: 
> 265:     // Every module is required to have a valid module-info.class.

The methods in this class use use /** ..*/ in the method descriptions so would prefer if the changes change that. Here the method should really say that it returns the module's module-info, returning a holder for its class file attributes.

src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 276:

> 274:             err = e;
> 275:         }
> 276:         throw new Error("Missing or invalid module-info.class for module: " + moduleName, err);

I assume this can move into the catch block.

src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 457:

> 455:          * a non-resource node, then {@code null} is returned.
> 456:          */
> 457:         private ImageReader.Node findResourceNode(ImageReader reader, String name) throws IOException {

I think the usage would be clear if this were renamed to findResource.

src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 464:

> 462:             String nodeName = "/modules/" + module + "/" + name;
> 463:             ImageReader.Node node = reader.findNode(nodeName);
> 464:             return node != null && node.isResource() ? node : null;

Style wise, can you put ( ) around the expression to avoid having to pause and check precedence.

src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 470:

> 468:         public Optional<ByteBuffer> read(String name) throws IOException {
> 469:             ImageReader reader = SystemImage.reader();
> 470:             return Optional.ofNullable(findResourceNode(reader, name)).map(reader::getResourceBuffer);

Style wise, can you put the .map(...) on the next line so this is easier to read.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26054#pullrequestreview-3045867656
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2224555704
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2224563056
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2224557574
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2224553155
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2224549636
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2224546104

From alanb at openjdk.org  Wed Jul 23 07:04:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Jul 2025 07:04:00 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v13]
In-Reply-To: <J-JqNtmP25GS9ovkcbl-IWtEZ2Oa8iGSROlZTuVAHJQ=.7c38d62a-020c-4edc-baac-c42833e5ca97@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <J-JqNtmP25GS9ovkcbl-IWtEZ2Oa8iGSROlZTuVAHJQ=.7c38d62a-020c-4edc-baac-c42833e5ca97@github.com>
Message-ID: <58dZrvPejcKmpsrPdcmzCJWoXR_Tu_inMfk8PuB1zmE=.096138ee-f88d-4a88-8e3b-657ca77d985d@github.com>

On Mon, 21 Jul 2025 12:03: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...
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback changes.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 51:

> 49:  * file system friendly way. The jimage entries (resources, module and package
> 50:  * information) are mapped into a unified hierarchy of named nodes, which serve
> 51:  * as the underlying structure for the {@code JrtFileSystem} and other utilities.

I think it's a bit confusing to document this class as an adapter for a BasicImageReader because you obtain one with static open methods that specify the file path to the jimage file. So I think better to start out in the class description by saying that it provide an API that can be used to create file system and other views over the contents of the jimage file.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 106:

> 104:      *
> 105:      * <p>This is the expected was to open an {@code ImageReader}, and it should
> 106:      * be rare for anything other than the native byte order to be needed.

I think the "Almost all callers" and "This is the expected was (typo)" comments are confusing. Can we remove these?

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 138:

> 136:      * @param name a JRT file system name (path) of the form
> 137:      * {@code "/modules/<module>/...} or {@code "/packages/<package>/...}.
> 138:      * @return a node representing a resource, directory or symbolic link.

This is the jimage reader rather than the jrt file system so it's very confusing to see comments about "JRT file system" in this file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2224593051
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2224578163
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2224596684

From mbaesken at openjdk.org  Wed Jul 23 07:15:04 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 23 Jul 2025 07:15:04 GMT
Subject: RFR: 8362889: [GCC static analyzer] leak in
 libstringPlatformChars.c [v4]
In-Reply-To: <VI2_0y_t67Q04GDM-cZlUuulIrgJvT_a9_i4i2cnDZk=.47dba761-5225-4faa-8224-a26f38cf4cae@github.com>
References: <ordEhGmC8cdl8LQKu-tmqNlvKSAK3ek3FUH6TMnpc-M=.b8c73a08-d65d-42ee-82a7-f3a0fd95d4db@github.com>
 <VI2_0y_t67Q04GDM-cZlUuulIrgJvT_a9_i4i2cnDZk=.47dba761-5225-4faa-8224-a26f38cf4cae@github.com>
Message-ID: <ng3WiMKdd62kQRAjZj142UpEzY73Ix8j4_HCgF1abOM=.20e49ca4-e00e-42e3-8dec-1b8f346d6171@github.com>

On Tue, 22 Jul 2025 14:01:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> This is reported by the gcc static analyzer (-fanalyzer); it is just test coding so not very critical but probably should still be adjusted .
>> 
>> 
>> /jdk/test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c:74:12: warning: leak of 'str' [CWE-401] [-Wanalyzer-malloc-leak]
>>    74 | return JNU_NewStringPlatform(env, str);
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add ReleasePrimitiveArrayCritical

Thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26415#issuecomment-3106150824

From mbaesken at openjdk.org  Wed Jul 23 07:15:04 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 23 Jul 2025 07:15:04 GMT
Subject: Integrated: 8362889: [GCC static analyzer] leak in
 libstringPlatformChars.c
In-Reply-To: <ordEhGmC8cdl8LQKu-tmqNlvKSAK3ek3FUH6TMnpc-M=.b8c73a08-d65d-42ee-82a7-f3a0fd95d4db@github.com>
References: <ordEhGmC8cdl8LQKu-tmqNlvKSAK3ek3FUH6TMnpc-M=.b8c73a08-d65d-42ee-82a7-f3a0fd95d4db@github.com>
Message-ID: <RZBNMm3RPW5tPhYpmTeiHX3VxqqVw9hzbna-q4i-OtY=.e6d29d12-8169-42e2-bd02-2d3a43bf8347@github.com>

On Mon, 21 Jul 2025 14:12:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> This is reported by the gcc static analyzer (-fanalyzer); it is just test coding so not very critical but probably should still be adjusted .
> 
> 
> /jdk/test/jdk/java/lang/String/nativeEncoding/libstringPlatformChars.c:74:12: warning: leak of 'str' [CWE-401] [-Wanalyzer-malloc-leak]
>    74 | return JNU_NewStringPlatform(env, str);

This pull request has now been integrated.

Changeset: 5160cfb4
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5160cfb49634cc4a1568c200bc5c17ddbe83c2f7
Stats:     13 lines in 1 file changed: 7 ins; 3 del; 3 mod

8362889: [GCC static analyzer] leak in libstringPlatformChars.c

Reviewed-by: rriggs, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/26415

From alanb at openjdk.org  Wed Jul 23 10:14:42 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Jul 2025 10:14:42 GMT
Subject: RFR: 8362882: Update SubmissionPublisher() specification to reflect
 use of ForkJoinPool.asyncCommonPool()
Message-ID: <jqlYivNsVPTONrGSgVmeH0CeXH2JCs2nUWPJ99C13xs=.205b8340-72a8-4e8b-9248-b2470f3d81c5@github.com>

The changes in JDK-8319447 to improve the performance of delayed task handling updated CompletableFuture and SubmissionPublisher to use the ForkJoinPool commonPool in all cases. These APIs previously created a Thread for each task when parallelism was less than 2. We missed the update to SubmissionPublisher's no-arg constructor in that update.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/26426/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26426&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362882
  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26426.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26426/head:pull/26426

PR: https://git.openjdk.org/jdk/pull/26426

From djelinski at openjdk.org  Wed Jul 23 11:04:17 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 23 Jul 2025 11:04:17 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
Message-ID: <vr9dbhdfhe_CZkHcwTIY8AaPWVzOmKsthRIuvnvdUFU=.b8c6b4bd-1c52-4371-838a-d9d0d271c8f2@github.com>

On Tue, 8 Jul 2025 14:04:56 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 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

test/jdk/java/net/httpclient/AsFileDownloadTest.java line 453:

> 451: 
> 452:         @Override
> 453:         public void handle(HttpTestExchange t) throws IOException {

this is almost an exact copy of the method above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2225171864

From duke at openjdk.org  Wed Jul 23 11:41:52 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 23 Jul 2025 11:41:52 GMT
Subject: RFR: 8077587: BigInteger Roots [v36]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <GpVKqhwqoPjzd_aj758RlCNO46Q8qrcsWJwSyG5gdQI=.205e01d9-5617-4535-aae9-221070f62af5@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Ensure an initial overestimate of the root
  
  Ensure an initial overestimate of the root, using Math.exp() and Math.log(), whose error is guaranteed to be less than 1 ulp.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/a98f91c3..b0542837

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=34-35

  Stats: 9 lines in 1 file changed: 6 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From vyazici at openjdk.org  Wed Jul 23 12:54:00 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 23 Jul 2025 12:54:00 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v12]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <Z0qfXQIIg9tHXGWA6ZSDuEiFXjY535lENUx7k59xIUc=.a3adfad6-79b1-4af7-9151-6acf0b44edd6@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` 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");
>         }
>     }
> }
> ...

Volkan Yazici has updated the pull request incrementally with four additional commits since the last revision:

 - Add `@bug` tags
 - Improve wording of `@param len`
 - Make source array bound checks lenient too
 - Cap destination array bounds

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/025c7ef7..1d02189f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=10-11

  Stats: 29 lines in 6 files changed: 8 ins; 12 del; 9 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 vyazici at openjdk.org  Wed Jul 23 12:54:01 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 23 Jul 2025 12:54:01 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v11]
In-Reply-To: <EgGnsBKXnK2hdKfTx0M2HtRpTMKOcRlEDpmFSwUOF_0=.28fce127-a8da-4cdd-b655-bc96c76a6513@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <_YafZXn8pIbA-zuOFNN5sVGBM-uKKy47RPhgRod9Tf4=.1927921f-59af-44a2-be6d-18ce70779f51@github.com>
 <EgGnsBKXnK2hdKfTx0M2HtRpTMKOcRlEDpmFSwUOF_0=.28fce127-a8da-4cdd-b655-bc96c76a6513@github.com>
Message-ID: <PMiTq_RP0cSqHvcbd6j5qJwS7kbH-PTrRqkTzTjvX2U=.ab0fb2c4-66e8-41f3-a4e9-5ac7e799926c@github.com>

On Mon, 21 Jul 2025 15:39:34 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Minor: could you please add a bug id to the `@bug` annotations in tests?

@myankelev, thanks for the heads up. Implemented in 1d02189fba1.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3107998200

From duke at openjdk.org  Wed Jul 23 14:14:25 2025
From: duke at openjdk.org (Darragh Conway)
Date: Wed, 23 Jul 2025 14:14:25 GMT
Subject: RFR: 8363720: Follow up to JDK-8360411 with post review comments
Message-ID: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>

There were a couple of post review comments after the /integrate command was submitted. This issue will address those comments. Also created constants for hardcoded values and tests. Fixed some typos.

-------------

Commit messages:
 - 8363720: Follow up to JDK-8360411 with post review comments

Changes: https://git.openjdk.org/jdk/pull/26445/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26445&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8363720
  Stats: 36 lines in 1 file changed: 14 ins; 5 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/26445.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26445/head:pull/26445

PR: https://git.openjdk.org/jdk/pull/26445

From rriggs at openjdk.org  Wed Jul 23 14:33:57 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Jul 2025 14:33:57 GMT
Subject: [jdk25] RFR: 8315131: Clarify VarHandle set/get access on 32-bit
 platforms
In-Reply-To: <0uABTBFyAvVk-sD0us6ovyZS142Yu9ZBLvYSEduv5P4=.852da2c3-abe6-4d96-852f-d68c7349ea0d@github.com>
References: <0uABTBFyAvVk-sD0us6ovyZS142Yu9ZBLvYSEduv5P4=.852da2c3-abe6-4d96-852f-d68c7349ea0d@github.com>
Message-ID: <e6wpryU_vf7G_stO5CtK8Jc8ULm6WFzoKme7JA950Lg=.05e8a253-f7fa-4252-8b0b-a4f09482040a@github.com>

On Wed, 23 Jul 2025 04:04:46 GMT, Chen Liang <liach at openjdk.org> wrote:

> JDK-8315131 addresses a doc-only mistake present on release 25. Since this is doc-only, this is eligible for backport, and its CSR is approved for release 25 too. See #26258 for the original PR review.

looks fine.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26438#pullrequestreview-3047727612

From tschatzl at openjdk.org  Wed Jul 23 14:34:47 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 23 Jul 2025 14:34:47 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v44]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <0KXHzGhrVDYfe_gWdT7DFsZYNyKDDVv9Os8K91HLfUQ=.b120a07e-95d0-4140-be81-a95e1b02f5d5@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 61 commits:

 - * remove unused G1DetachedRefinementStats_lock
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into pull/23739
 - 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
 - ... and 51 more: https://git.openjdk.org/jdk/compare/743c8212...dd836387

-------------

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=43
  Stats: 7122 lines in 112 files changed: 2588 ins; 3592 del; 942 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 hannesw at openjdk.org  Wed Jul 23 14:35:59 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 23 Jul 2025 14:35:59 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <3u6pXBfNO_0Jv6ncXqPzfEwAlMYACUs8n4hBCzVJySA=.c767eace-8e78-4449-af6a-056751167982@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
 <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
 <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>
 <kS1L5BXHrQhg2Ear1fgxGJoRFAF5_cm_mybVY2iuksQ=.e20c4f19-328a-4448-9fa0-3d53067f14d2@github.com>
 <3u6pXBfNO_0Jv6ncXqPzfEwAlMYACUs8n4hBCzVJySA=.c767eace-8e78-4449-af6a-056751167982@github.com>
Message-ID: <Xqh-MwvNHBO0bwlzZHe46WiJqTzGbsiid9pZort3sG4=.fa2dc115-11b4-4036-99f6-4be73fd5adf4@github.com>

On Wed, 23 Jul 2025 05:55:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> As expected, the above test passes fine if I remove the jsobject entries from `test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list`. I'll go ahead and remove them, since it seems like good cleanup.
>
> @hns Would it be possible to confirm that it's okay to remove this from the doclet tests?

The list is used as list of external linkable modules/packages for the `-linkoffline` option. Since the list for JDK 17 the entry could be left in the list, but as the test doesn't try to link to the module removing it doesn't make any difference.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2225804491

From duke at openjdk.org  Wed Jul 23 15:10:56 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 23 Jul 2025 15:10:56 GMT
Subject: RFR: 8077587: BigInteger Roots [v37]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <Z0te_inzT7cLyEmm_yoKmLHjH_ybJ1wsEHMOJWevLEA=.28d2e9aa-aca8-4aa5-8899-812766056dab@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  No need to ceiling the initial estimate if not shifted

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/b0542837..ed1949d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=35-36

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From hannesw at openjdk.org  Wed Jul 23 15:25:01 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 23 Jul 2025 15:25:01 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <Xqh-MwvNHBO0bwlzZHe46WiJqTzGbsiid9pZort3sG4=.fa2dc115-11b4-4036-99f6-4be73fd5adf4@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
 <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
 <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>
 <kS1L5BXHrQhg2Ear1fgxGJoRFAF5_cm_mybVY2iuksQ=.e20c4f19-328a-4448-9fa0-3d53067f14d2@github.com>
 <3u6pXBfNO_0Jv6ncXqPzfEwAlMYACUs8n4hBCzVJySA=.c767eace-8e78-4449-af6a-056751167982@github.com>
 <Xqh-MwvNHBO0bwlzZHe46WiJqTzGbsiid9pZort3sG4=.fa2dc115-11b4-4036-99f6-4be73fd5adf4@github.com>
Message-ID: <-6pe3kOD8As2nIe-g3ca7UPXoKKpaVBYmpDCW4VdE_o=.d530e02e-6516-4655-ac5b-a4eafa006cd8@github.com>

On Wed, 23 Jul 2025 14:33:34 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> @hns Would it be possible to confirm that it's okay to remove this from the doclet tests?
>
> The list is used as list of external linkable modules/packages for the `-linkoffline` option. Since the list for JDK 17 the entry could be left in the list, but as the test doesn't try to link to the module removing it doesn't make any difference.

Maybe my previous comment was a bit unclear. Both options are okay, leaving the entries and removing them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2225940174

From duke at openjdk.org  Wed Jul 23 15:34:02 2025
From: duke at openjdk.org (duke)
Date: Wed, 23 Jul 2025 15:34:02 GMT
Subject: RFR: 8358530: Properties#list should warn against non-String
 values [v3]
In-Reply-To: <7GTzRxnXL2WlZDaFC5G6uirYlUs-jhsfNoEREBwQe3U=.8468402d-e5c8-41bb-9887-b73880bb0d71@github.com>
References: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
 <7GTzRxnXL2WlZDaFC5G6uirYlUs-jhsfNoEREBwQe3U=.8468402d-e5c8-41bb-9887-b73880bb0d71@github.com>
Message-ID: <PMBxFQscEEohzRxLStBDH02aCL6jCWH_qB3HhwDueD4=.be6fd2f5-1c93-4bea-afda-beb3b42ef16b@github.com>

On Thu, 17 Jul 2025 15:32:32 GMT, cagliostro92 <duke at openjdk.org> wrote:

>> Trivial PR to enhance Javadoc for the `Properties#list` method, which has cost me some debugging time.
>
> cagliostro92 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8358530: adds oxford comma

@cagliostro92 
Your change (at version a0c7572fbe2b6266dba0d466adba2b1f66ee1cea) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25334#issuecomment-3109131299

From liach at openjdk.org  Wed Jul 23 15:34:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Jul 2025 15:34:02 GMT
Subject: RFR: 8358530: Properties#list should warn against non-String
 values [v3]
In-Reply-To: <9Wr-amACg6uZeYoPf5Qfo-UwVDVvITaxpcNksaf6xY4=.54c2ac06-5e6d-41af-a4dd-b52b31824143@github.com>
References: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
 <9Wr-amACg6uZeYoPf5Qfo-UwVDVvITaxpcNksaf6xY4=.54c2ac06-5e6d-41af-a4dd-b52b31824143@github.com>
Message-ID: <rGlCgK4mit0ngVI2qqYoyx_-D5Tg8lXQceFVoeDsrRw=.56a4468f-0bc2-4f3f-b062-c9a087e1d5e7@github.com>

On Tue, 15 Jul 2025 16:37:18 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> cagliostro92 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8358530: adds oxford comma
>
> The copyright year for this file should also be updated: `1995, 2025,`
> 
> Also, the PR title will need to be changed to,
> 
> _8358530: Properties#list should warn against non-String values_

@justin-curtis-lu Do you want a final round of review?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25334#issuecomment-3109138695

From jpai at openjdk.org  Wed Jul 23 15:35:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 23 Jul 2025 15:35:54 GMT
Subject: RFR: 8362882: Update SubmissionPublisher() specification to
 reflect use of ForkJoinPool.asyncCommonPool()
In-Reply-To: <jqlYivNsVPTONrGSgVmeH0CeXH2JCs2nUWPJ99C13xs=.205b8340-72a8-4e8b-9248-b2470f3d81c5@github.com>
References: <jqlYivNsVPTONrGSgVmeH0CeXH2JCs2nUWPJ99C13xs=.205b8340-72a8-4e8b-9248-b2470f3d81c5@github.com>
Message-ID: <diV9-GCdi3EweuiGK0zv4XMPtHBpQGm24eF90-bxvAU=.12590dbe-0278-4366-8db6-0342e1182072@github.com>

On Tue, 22 Jul 2025 13:13:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The changes in JDK-8319447 to improve the performance of delayed task handling updated CompletableFuture and SubmissionPublisher to use the ForkJoinPool commonPool in all cases. These APIs previously created a Thread for each task when parallelism was less than 2. We missed the update to SubmissionPublisher's no-arg constructor in that update.

This looks OK to me and matches the current implementation of this constructor.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26426#pullrequestreview-3048000895

From iris at openjdk.org  Wed Jul 23 15:38:00 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 23 Jul 2025 15:38:00 GMT
Subject: [jdk25] RFR: 8315131: Clarify VarHandle set/get access on 32-bit
 platforms
In-Reply-To: <0uABTBFyAvVk-sD0us6ovyZS142Yu9ZBLvYSEduv5P4=.852da2c3-abe6-4d96-852f-d68c7349ea0d@github.com>
References: <0uABTBFyAvVk-sD0us6ovyZS142Yu9ZBLvYSEduv5P4=.852da2c3-abe6-4d96-852f-d68c7349ea0d@github.com>
Message-ID: <sYZJ90WAnRkhoGAW3Mqv3cpIMC6lr1mOcyA-_5aF3l0=.6f646527-1a38-43d4-b6a2-b29238da9db1@github.com>

On Wed, 23 Jul 2025 04:04:46 GMT, Chen Liang <liach at openjdk.org> wrote:

> JDK-8315131 addresses a doc-only mistake present on release 25. Since this is doc-only, this is eligible for backport, and its CSR is approved for release 25 too. See #26258 for the original PR review.

Confirmed changes identical to those already in `master`.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26438#pullrequestreview-3048006291

From kcr at openjdk.org  Wed Jul 23 15:39:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Jul 2025 15:39:58 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <-6pe3kOD8As2nIe-g3ca7UPXoKKpaVBYmpDCW4VdE_o=.d530e02e-6516-4655-ac5b-a4eafa006cd8@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
 <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
 <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>
 <kS1L5BXHrQhg2Ear1fgxGJoRFAF5_cm_mybVY2iuksQ=.e20c4f19-328a-4448-9fa0-3d53067f14d2@github.com>
 <3u6pXBfNO_0Jv6ncXqPzfEwAlMYACUs8n4hBCzVJySA=.c767eace-8e78-4449-af6a-056751167982@github.com>
 <Xqh-MwvNHBO0bwlzZHe46WiJqTzGbsiid9pZort3sG4=.fa2dc115-11b4-4036-99f6-4be73fd5adf4@github.com>
 <-6pe3kOD8As2nIe-g3ca7UPXoKKpaVBYmpDCW4VdE_o=.d530e02e-6516-4655-ac5b-a4eafa006cd8@github.com>
Message-ID: <49XysSSYVTzmKjja4l23jCkIz_gab8_qXX7eSxb2IsE=.1f07ea64-3a1b-49c6-9ef6-5b06e9616ad3@github.com>

On Wed, 23 Jul 2025 15:22:04 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> The list is used as list of external linkable modules/packages for the `-linkoffline` option. Since the list is for JDK 17 the entry could be left in the list, but as the test doesn't try to link to the module removing it doesn't make any difference.
>
> Maybe my previous comment was a bit unclear. Both options are okay, leaving the entries and removing them.

Thanks. In that case, I'll stick with the current state of the PR which removes them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2225986752

From duke at openjdk.org  Wed Jul 23 15:42:59 2025
From: duke at openjdk.org (duke)
Date: Wed, 23 Jul 2025 15:42:59 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
Message-ID: <lZThqhW_oV4kZT0z239m-ztL7l-fENyyolVs3dcnqn0=.80495d5f-2e75-48ea-bc2c-d7030a16d685@github.com>

On Tue, 22 Jul 2025 19:53:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
>> 
>> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
>> 
>> 
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
>> src/jdk.compiler/share/data/symbols/symbols
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
>> 
>> 
>> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove jdk.jsobject from one more test

@kevinrushforth 
Your change (at version 2858cd3e61b51f213db3265beec30d1afedf1906) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26393#issuecomment-3109170206

From kcr at openjdk.org  Wed Jul 23 15:50:05 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Jul 2025 15:50:05 GMT
Subject: Integrated: 8359760: Remove the jdk.jsobject module
In-Reply-To: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
Message-ID: <hx0zS7djImUSZHj8604N2mlfoMh0ecey7l8pmtfy7jQ=.c470ccd7-6b43-48fe-9478-4469b75c62a0@github.com>

On Fri, 18 Jul 2025 16:58:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
> 
> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
> 
> 
> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
> src/jdk.compiler/share/data/symbols/symbols
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
> 
> 
> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.

This pull request has now been integrated.

Changeset: 594c080b
Author:    Kevin Rushforth <kcr at openjdk.org>
Committer: Iris Clark <iris at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/594c080b2bde81a48ecccda85ac765218fc93856
Stats:     362 lines in 12 files changed: 0 ins; 358 del; 4 mod

8359760: Remove the jdk.jsobject module

Reviewed-by: rriggs, iris, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/26393

From duke at openjdk.org  Wed Jul 23 16:11:20 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 23 Jul 2025 16:11:20 GMT
Subject: RFR: 8077587: BigInteger Roots [v38]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <POqvv6k8duqSKi_6zY01HwqmPD6WQAvjAd75_ofezzY=.8742db1b-5d75-4d8f-ba19-d46be0c787b8@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  More accurate lower bound for doubles values tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/ed1949d4..5a6a4a07

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=37
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=36-37

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From joehw at openjdk.org  Wed Jul 23 16:23:00 2025
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 23 Jul 2025 16:23:00 GMT
Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system
 property [v3]
In-Reply-To: <Z3ELpLYL59qXREH7jThXieIAXFwYSUEyrAztdHdFAdo=.4489f709-641a-4771-9e9f-b0d814e5cb79@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
 <Z3ELpLYL59qXREH7jThXieIAXFwYSUEyrAztdHdFAdo=.4489f709-641a-4771-9e9f-b0d814e5cb79@github.com>
Message-ID: <aK3R9ZdTYi4ZiddRKTvpq8KUlH_BuOeYM2Z5SRkMXt4=.6fe67c39-49ec-4695-b1fa-3730c6080942@github.com>

On Tue, 22 Jul 2025 22:25:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Obsolete comment correction

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26419#pullrequestreview-3048180520

From duke at openjdk.org  Wed Jul 23 16:34:01 2025
From: duke at openjdk.org (cagliostro92)
Date: Wed, 23 Jul 2025 16:34:01 GMT
Subject: Integrated: 8358530: Properties#list should warn against non-String
 values
In-Reply-To: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
References: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
Message-ID: <tECwbZNCN-1vcq6Qme0bvrJjl1RtJpjTXg3RHWqalbk=.c4dc6a85-a19c-4b59-aae5-240b73b33fc3@github.com>

On Tue, 20 May 2025 16:03:14 GMT, cagliostro92 <duke at openjdk.org> wrote:

> Trivial PR to enhance Javadoc for the `Properties#list` method, which has cost me some debugging time.

This pull request has now been integrated.

Changeset: 03e9ea16
Author:    Edoardo Patti <edoardopatti25 at gmail.com>
Committer: Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/03e9ea169b7e45ae3c2ac23b5fe73d39ae57506f
Stats:     7 lines in 1 file changed: 0 ins; 0 del; 7 mod

8358530: Properties#list should warn against non-String values

Reviewed-by: jlu, liach

-------------

PR: https://git.openjdk.org/jdk/pull/25334

From jlu at openjdk.org  Wed Jul 23 16:34:00 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 23 Jul 2025 16:34:00 GMT
Subject: RFR: 8358530: Properties#list should warn against non-String
 values [v3]
In-Reply-To: <7GTzRxnXL2WlZDaFC5G6uirYlUs-jhsfNoEREBwQe3U=.8468402d-e5c8-41bb-9887-b73880bb0d71@github.com>
References: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
 <7GTzRxnXL2WlZDaFC5G6uirYlUs-jhsfNoEREBwQe3U=.8468402d-e5c8-41bb-9887-b73880bb0d71@github.com>
Message-ID: <AXUEPMKS0zslZY1fnJZVX16kVxSMJ2RT4wEIn4HZfKA=.289b5d5c-c5e4-4527-812a-8a0d5011ac12@github.com>

On Thu, 17 Jul 2025 15:32:32 GMT, cagliostro92 <duke at openjdk.org> wrote:

>> Trivial PR to enhance Javadoc for the `Properties#list` method, which has cost me some debugging time.
>
> cagliostro92 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8358530: adds oxford comma

Thanks @cagliostro92 for the changes and @liach for reviewing.

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25334#pullrequestreview-3048206253

From duke at openjdk.org  Wed Jul 23 16:38:00 2025
From: duke at openjdk.org (cagliostro92)
Date: Wed, 23 Jul 2025 16:38:00 GMT
Subject: RFR: 8358530: Properties#list should warn against non-String
 values [v3]
In-Reply-To: <AXUEPMKS0zslZY1fnJZVX16kVxSMJ2RT4wEIn4HZfKA=.289b5d5c-c5e4-4527-812a-8a0d5011ac12@github.com>
References: <-izZBnT8HKqUQdMjdydfE_tdvcTRKqSxF20teX8nSa0=.a2f8f037-64b0-4919-90b0-bbf43c7524b1@github.com>
 <7GTzRxnXL2WlZDaFC5G6uirYlUs-jhsfNoEREBwQe3U=.8468402d-e5c8-41bb-9887-b73880bb0d71@github.com>
 <AXUEPMKS0zslZY1fnJZVX16kVxSMJ2RT4wEIn4HZfKA=.289b5d5c-c5e4-4527-812a-8a0d5011ac12@github.com>
Message-ID: <o-EzGsxHZC2Cx09cRMFsxQMJbS0YJC0Cp_DbPu_kIA4=.64627185-7133-4384-9583-4fb2436e5531@github.com>

On Wed, 23 Jul 2025 16:29:38 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> cagliostro92 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8358530: adds oxford comma
>
> Thanks @cagliostro92 for the changes and @liach for reviewing.

@justin-curtis-lu @liach thank you! ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25334#issuecomment-3109356812

From jlu at openjdk.org  Wed Jul 23 16:50:56 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 23 Jul 2025 16:50:56 GMT
Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system
 property [v3]
In-Reply-To: <Z3ELpLYL59qXREH7jThXieIAXFwYSUEyrAztdHdFAdo=.4489f709-641a-4771-9e9f-b0d814e5cb79@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
 <Z3ELpLYL59qXREH7jThXieIAXFwYSUEyrAztdHdFAdo=.4489f709-641a-4771-9e9f-b0d814e5cb79@github.com>
Message-ID: <NtoCikJGvH8XnsCVf3eCNRY5L9wqD3ME2LA1z01k_2s=.b5f6c9e4-dab1-4537-bb0c-7688ff35a805@github.com>

On Tue, 22 Jul 2025 22:25:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Obsolete comment correction

src/java.base/share/classes/java/util/Locale.java line 534:

> 532:  * their earlier, obsoleted forms: {@code he} maps to {@code iw},
> 533:  * {@code yi} maps to {@code ji}, and {@code id} maps to
> 534:  * {@code in}. Since Java SE 17, this is no longer the case. Each

* <p>Locale's constructors have always converted three language codes to
 * their earlier, obsoleted forms: {@code he} maps to {@code iw},
 * {@code yi} maps to {@code ji}, and {@code id} maps to
 * {@code in}. Since Java SE 17, this is no longer the case.


This history was relevant when the property existed. Since this is no longer the case, and we're quite a few releases away from 17, can we also remove this wording as well. Users on 26 should only be concerned with the "old" to "modern" mapping.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26419#discussion_r2226150632

From rgiulietti at openjdk.org  Wed Jul 23 17:08:06 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 23 Jul 2025 17:08:06 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <xgskj4LLvFR3upWuqjKEDVCLQ4uEXrorlfxlimZ17ts=.6ae32e3b-56c8-453b-a369-f806fa2ec3fa@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <hlJRzBO6IWnQ1naGAPRydFUxc7dqbhIGY-ak7va0jCY=.e1965f33-4206-49ec-8403-4bf9ff7aee65@github.com>
 <UYLJINZ26NuZAcCc6jq0KCpI11uVwVOWSGNrkXcLUIk=.70bdaf9b-b066-454f-806a-e3b104588f2d@github.com>
 <jAyW8BztvN-9vdU9r1pTdFFMuTK4VPrz3lrGNJPUSsQ=.22b8c9ac-5001-47f9-9b23-ae32454fb47d@github.com>
 <xgskj4LLvFR3upWuqjKEDVCLQ4uEXrorlfxlimZ17ts=.6ae32e3b-56c8-453b-a369-f806fa2ec3fa@github.com>
Message-ID: <pxDJ-FDB5HTPVFtzBvvOSbf_xyVl3X2l-bLO_dSlYPo=.4bf70293-3d20-47c6-8fb2-5495b8d9c0f6@github.com>

On Mon, 14 Jul 2025 16:41:15 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This is my hunch as well.
>> So while the use of `nextUp()` and `ceil()` certainly help to achieve an overestimate, I'm less sure that this is sufficient when using `pow()`. If the latter has some error bigger than a few ulps, then we are in trouble.
>
> @rgiulietti Now that I checked the recurrence better, it seems to me that it should give an overestimate if `rLong` is an underestimate, without modify it.

Can you please provide a succinct "proof" in form of a comment? Needs to be convincing, although not necessarily rigorous.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2226184420

From rgiulietti at openjdk.org  Wed Jul 23 17:18:05 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 23 Jul 2025 17:18:05 GMT
Subject: RFR: 8077587: BigInteger Roots [v38]
In-Reply-To: <POqvv6k8duqSKi_6zY01HwqmPD6WQAvjAd75_ofezzY=.8742db1b-5d75-4d8f-ba19-d46be0c787b8@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <POqvv6k8duqSKi_6zY01HwqmPD6WQAvjAd75_ofezzY=.8742db1b-5d75-4d8f-ba19-d46be0c787b8@github.com>
Message-ID: <WRjZQwIfL3_g8Z5Smz-5qMCDS7dmfh1JMdDCQzw7d5A=.38f2f25b-5971-4490-b7dd-fdc60f6a4433@github.com>

On Wed, 23 Jul 2025 16:11:20 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More accurate lower bound for doubles values tests

Please merge branch `master` into yours every now and then.

src/java.base/share/classes/java/math/MutableBigInteger.java line 1956:

> 1954:                     rToN1 = BigInteger.unsignedLongPow(rLong, n - 1);
> 1955:                     r1 = ((n - 1) * rLong + Long.divideUnsigned(x, rToN1)) / n;
> 1956:                 } while (r1 < rLong); // Terminate when non-decreasing.

Here (and below as well) it would be useful to have the same variable names as in the paper, where possible.
No need to rename `x` to m and `n` to k, though, they can remain.

src/java.base/share/classes/java/math/MutableBigInteger.java line 2000:

> 1998:                     int shiftLack = n - shiftExcess;
> 1999:                     shift += shiftLack; // shift is long, no overflow
> 2000:                     rad /= Double.parseDouble("0x1p" + shiftLack);

Suggestion:

                    rad /= Math.scalb(1.0, shiftLack);

src/java.base/share/classes/java/math/MutableBigInteger.java line 2026:

> 2024:                     int correctBits = ((Double.PRECISION - 1) - radExp - 1) / n + 1;
> 2025:                     rootShift -= correctBits;
> 2026:                     approx *= Double.parseDouble("0x1p" + correctBits);

Suggestion:

                    approx *= Math.scalb(1.0, correctBits);

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3109471808
PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2226198312
PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2226198452
PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2226198568

From naoto at openjdk.org  Wed Jul 23 17:39:12 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 23 Jul 2025 17:39:12 GMT
Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system
 property [v4]
In-Reply-To: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
Message-ID: <hi8DT6X0BNMx5wNJSeBE036ZqFstwEvRhG_-JyilOkA=.e7ac62fc-40fe-4c1d-a0a0-dfa63e50de37@github.com>

> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Further wording refinement

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26419/files
  - new: https://git.openjdk.org/jdk/pull/26419/files/93f3a8b3..c68a63be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26419&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26419&range=02-03

  Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26419.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26419/head:pull/26419

PR: https://git.openjdk.org/jdk/pull/26419

From naoto at openjdk.org  Wed Jul 23 17:39:13 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 23 Jul 2025 17:39:13 GMT
Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system
 property [v3]
In-Reply-To: <NtoCikJGvH8XnsCVf3eCNRY5L9wqD3ME2LA1z01k_2s=.b5f6c9e4-dab1-4537-bb0c-7688ff35a805@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
 <Z3ELpLYL59qXREH7jThXieIAXFwYSUEyrAztdHdFAdo=.4489f709-641a-4771-9e9f-b0d814e5cb79@github.com>
 <NtoCikJGvH8XnsCVf3eCNRY5L9wqD3ME2LA1z01k_2s=.b5f6c9e4-dab1-4537-bb0c-7688ff35a805@github.com>
Message-ID: <mEM4ZF5Cr1Aey4oaWcJeRokoE9jN-Ypi_RapvyB0XCg=.429854b4-b266-48b1-a174-ef222d1aa88e@github.com>

On Wed, 23 Jul 2025 16:48:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Obsolete comment correction
>
> src/java.base/share/classes/java/util/Locale.java line 534:
> 
>> 532:  * their earlier, obsoleted forms: {@code he} maps to {@code iw},
>> 533:  * {@code yi} maps to {@code ji}, and {@code id} maps to
>> 534:  * {@code in}. Since Java SE 17, this is no longer the case. Each
> 
> * <p>Locale's constructors have always converted three language codes to
>  * their earlier, obsoleted forms: {@code he} maps to {@code iw},
>  * {@code yi} maps to {@code ji}, and {@code id} maps to
>  * {@code in}. Since Java SE 17, this is no longer the case.
> 
> 
> This history was relevant when the property existed. Since this is no longer the case, and we're quite a few releases away from 17, can we also remove this wording as well. Users on 26 should only be concerned with the "old" to "modern" mapping.

Good point. Modified the unnecesarry history.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26419#discussion_r2226240004

From duke at openjdk.org  Wed Jul 23 17:43:10 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 23 Jul 2025 17:43:10 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <pxDJ-FDB5HTPVFtzBvvOSbf_xyVl3X2l-bLO_dSlYPo=.4bf70293-3d20-47c6-8fb2-5495b8d9c0f6@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <hlJRzBO6IWnQ1naGAPRydFUxc7dqbhIGY-ak7va0jCY=.e1965f33-4206-49ec-8403-4bf9ff7aee65@github.com>
 <UYLJINZ26NuZAcCc6jq0KCpI11uVwVOWSGNrkXcLUIk=.70bdaf9b-b066-454f-806a-e3b104588f2d@github.com>
 <jAyW8BztvN-9vdU9r1pTdFFMuTK4VPrz3lrGNJPUSsQ=.22b8c9ac-5001-47f9-9b23-ae32454fb47d@github.com>
 <xgskj4LLvFR3upWuqjKEDVCLQ4uEXrorlfxlimZ17ts=.6ae32e3b-56c8-453b-a369-f806fa2ec3fa@github.com>
 <pxDJ-FDB5HTPVFtzBvvOSbf_xyVl3X2l-bLO_dSlYPo=.4bf70293-3d20-47c6-8fb2-5495b8d9c0f6@github.com>
Message-ID: <ha_WXueBRc1kLuQebAFJVsVBf_1Cc38a4uZk-0q_7uQ=.96670b81-b3c5-42fb-87cb-df5386c86581@github.com>

On Wed, 23 Jul 2025 17:05:07 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti Now that I checked the recurrence better, it seems to me that it should give an overestimate if `rLong` is an underestimate, without modify it.
>
> Can you please provide a succinct "proof" in form of a comment? Needs to be convincing, although not necessarily rigorous.

@rgiulietti I've changed the formula that computes the initial estimate, now it does not use `Math.pow()` anymore, but `Math.exp()` and `Math.log()` instead, which are guaranteed to have always an error less than 1 ulp  by the fdlibm.

Anyway, the proof that the Newton's recurrence should output an overestimate if the input is an underestimate should follow by two facts:
- $f(x) = x^n - C$ with domain $x \in [0, +\infty)$ is an increasing function and its derivative is increasing;
- Newton's recurrence computes the next approximation $x_{i+1}$ by finding the zero of the line with gradient $f'(x_i)$ that passes through the point $(x_i, f(x_i))$.

So, Newton's method approximates the curve of $f(x)$ with the tangent in the point $(x_i, f(x_i))$. Since the curve is increasing and its derivative is increasing, if $x_i$ is less than the zero of $f(x)$, then the zero of the line must be greater than the zero of $f(x)$ (because the line increases more slowly than the curve of $f(x)$ ).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2226248974

From rgiulietti at openjdk.org  Wed Jul 23 19:52:59 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 23 Jul 2025 19:52:59 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <ha_WXueBRc1kLuQebAFJVsVBf_1Cc38a4uZk-0q_7uQ=.96670b81-b3c5-42fb-87cb-df5386c86581@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <hlJRzBO6IWnQ1naGAPRydFUxc7dqbhIGY-ak7va0jCY=.e1965f33-4206-49ec-8403-4bf9ff7aee65@github.com>
 <UYLJINZ26NuZAcCc6jq0KCpI11uVwVOWSGNrkXcLUIk=.70bdaf9b-b066-454f-806a-e3b104588f2d@github.com>
 <jAyW8BztvN-9vdU9r1pTdFFMuTK4VPrz3lrGNJPUSsQ=.22b8c9ac-5001-47f9-9b23-ae32454fb47d@github.com>
 <xgskj4LLvFR3upWuqjKEDVCLQ4uEXrorlfxlimZ17ts=.6ae32e3b-56c8-453b-a369-f806fa2ec3fa@github.com>
 <pxDJ-FDB5HTPVFtzBvvOSbf_xyVl3X2l-bLO_dSlYPo=.4bf70293-3d20-47c6-8fb2-5495b8d9c0f6@github.com>
 <ha_WXueBRc1kLuQebAFJVsVBf_1Cc38a4uZk-0q_7uQ=.96670b81-b3c5-42fb-87cb-df5386c86581@github.com>
Message-ID: <acXJtjtRG_TOEC6A9eQWC-0jfiCMCnF5EoDBxEVFysU=.c74ae4f3-4840-4041-b3a3-32c9259de8fd@github.com>

On Wed, 23 Jul 2025 17:40:22 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Can you please provide a succinct "proof" in form of a comment? Needs to be convincing, although not necessarily rigorous.
>
> @rgiulietti I've changed the formula that computes the initial estimate, now it does not use `Math.pow()` anymore, but `Math.exp()` and `Math.log()` instead, which are guaranteed to have always an error less than 1 ulp  by the fdlibm.
> 
> Anyway, the proof that the Newton's recurrence should output an overestimate if the input is an underestimate should follow by two facts:
> - $f(x) = x^n - C$ with domain $x \in [0, +\infty)$ is an increasing function and its derivative is increasing;
> - Newton's recurrence computes the next approximation $x_{i+1}$ by finding the zero of the line with gradient $f'(x_i)$ that passes through the point $(x_i, f(x_i))$.
> 
> So, Newton's method approximates the curve of $f(x)$ with the tangent in the point $(x_i, f(x_i))$. Since the curve is increasing and its derivative is increasing, if $x_i$ is less than the zero of $f(x)$, then the zero of the line must be greater than the zero of $f(x)$ (because the line increases more slowly than the curve of $f(x)$ ).

I noticed the usage of exp() and log(), thanks for the change.

My concerns about using transcendental are rooted in [this paper](https://members.loria.fr/PZimmermann/papers/accuracy.pdf).
The Javadoc claims an error of 1 ulp for pow(), but it turns out to be plainly wrong: the worst _known_ error is 636 ulps! (In that paper, see the column for OpenLibm, a derivative work of fdlibm.)

On a more positive side, that paper also shows the worst _known_ error for exp() and log() to be around 0.95 ulps. But again, it could be much worse, who knows?

The Brent & Zimmermann paper assumes an initial estimate $u \ge \lfloor x^{1/n}\rfloor$, probably for a (unstated) reason.
The proof of the algorithm makes use of Newton's formula $x_{i+1} = f(x_i)$, where $f$ is the real-valued counterpart of the integer recurrence formula in the algorithm.
It is straightforward to see that $x_{i+1} > x^{1/n}$ when $0 < x_i < x^{1/n}$.
But it's less clear to me that the same applies to the _integer_ recurrence formula of the algorithm.

Given all of the above, we must ensure that the initial estimate meets the requirements of the BZ paper, or we need a proof that an underestimate in the 1st iteration is harmless because it will become an overestimate in the 2nd, i.e., that the reasoning which holds for the real-valued $f$ also holds with the integer-valued analogous formula.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2226499267

From duke at openjdk.org  Wed Jul 23 21:13:58 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 23 Jul 2025 21:13:58 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <acXJtjtRG_TOEC6A9eQWC-0jfiCMCnF5EoDBxEVFysU=.c74ae4f3-4840-4041-b3a3-32c9259de8fd@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <hlJRzBO6IWnQ1naGAPRydFUxc7dqbhIGY-ak7va0jCY=.e1965f33-4206-49ec-8403-4bf9ff7aee65@github.com>
 <UYLJINZ26NuZAcCc6jq0KCpI11uVwVOWSGNrkXcLUIk=.70bdaf9b-b066-454f-806a-e3b104588f2d@github.com>
 <jAyW8BztvN-9vdU9r1pTdFFMuTK4VPrz3lrGNJPUSsQ=.22b8c9ac-5001-47f9-9b23-ae32454fb47d@github.com>
 <xgskj4LLvFR3upWuqjKEDVCLQ4uEXrorlfxlimZ17ts=.6ae32e3b-56c8-453b-a369-f806fa2ec3fa@github.com>
 <pxDJ-FDB5HTPVFtzBvvOSbf_xyVl3X2l-bLO_dSlYPo=.4bf70293-3d20-47c6-8fb2-5495b8d9c0f6@github.com>
 <ha_WXueBRc1kLuQebAFJVsVBf_1Cc38a4uZk-0q_7uQ=.96670b81-b3c5-42fb-87cb-df5386c86581@github.com>
 <acXJtjtRG_TOEC6A9eQWC-0jfiCMCnF5EoDBxEVFysU=.c74ae4f3-4840-4041-b3a3-32c9259de8fd@github.com>
Message-ID: <YwUgf4i5k8ZL0M-VEpGzWI0fnqt_U82sLr63dpqiigk=.12667c79-9ae2-4df5-a699-5f7de6123b89@github.com>

On Wed, 23 Jul 2025 19:49:51 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti I've changed the formula that computes the initial estimate, now it does not use `Math.pow()` anymore, but `Math.exp()` and `Math.log()` instead, which are guaranteed to have always an error less than 1 ulp  by the fdlibm.
>> 
>> Anyway, the proof that the Newton's recurrence should output an overestimate if the input is an underestimate should follow by two facts:
>> - $f(x) = x^n - C$ with domain $x \in [0, +\infty)$ is an increasing function and its derivative is increasing;
>> - Newton's recurrence computes the next approximation $x_{i+1}$ by finding the zero of the line with gradient $f'(x_i)$ that passes through the point $(x_i, f(x_i))$.
>> 
>> So, Newton's method approximates the curve of $f(x)$ with the tangent in the point $(x_i, f(x_i))$. Since the curve is increasing and its derivative is increasing, if $x_i$ is less than the zero of $f(x)$, then the zero of the line must be greater than the zero of $f(x)$ (because the line increases more slowly than the curve of $f(x)$ ).
>
> I noticed the usage of exp() and log(), thanks for the change.
> 
> My concerns about using transcendental are rooted in [this paper](https://members.loria.fr/PZimmermann/papers/accuracy.pdf).
> The Javadoc claims an error of 1 ulp for pow(), but it turns out to be plainly wrong: the worst _known_ error is 636 ulps! (In that paper, see the column for OpenLibm, a derivative work of fdlibm.)
> 
> On a more positive side, that paper also shows the worst _known_ error for exp() and log() to be around 0.95 ulps. But again, it could be much worse, who knows?
> 
> The Brent & Zimmermann paper assumes an initial estimate $u \ge \lfloor x^{1/n}\rfloor$, probably for a (unstated) reason.
> The proof of the algorithm makes use of Newton's formula $x_{i+1} = f(x_i)$, where $f$ is the real-valued counterpart of the integer recurrence formula in the algorithm.
> It is straightforward to see that $x_{i+1} > x^{1/n}$ when $0 < x_i < x^{1/n}$.
> But it's less clear to me that the same applies to the _integer_ recurrence formula of the algorithm.
> 
> Given all of the above, we must ensure that the initial estimate meets the requirements of the BZ paper, or we need a proof that an underestimate in the 1st iteration is harmless because it will become an overestimate in the 2nd, i.e., that the reasoning which holds for the real-valued $f$ also holds with the integer-valued analogous formula.

@rgiulietti
> The Brent & Zimmermann paper assumes an initial estimate u ? ? x 1 / n ? , probably for a (unstated) reason.

The reason is the condition to stop the loop, since it terminates when the estimate does not decrease anymore.

> 
> Given all of the above, we must ensure that the initial estimate meets the requirements of the BZ paper, or we need a proof that an underestimate in the 1st iteration is harmless because it will become an overestimate in the 2nd, i.e., that the reasoning which holds for the real-valued f also holds with the integer-valued analogous formula.

In Brent & Zimmermann proof, we have the following definition: $f(t) := \lfloor (n-1) t + m/t^{n-1}  \rfloor / n$, with $t \in (0; +\infty)$. Since $f(t)' < 0$ if $t < \sqrt[n]{m}$ and $f(t)' > 0$ if $t > \sqrt[n]{m}$, then $\sqrt[n]{m}$ is a point of minimum, so $f(t) \ge f(\sqrt[n]{m}) = \sqrt[n]{m}$, hence $\lfloor f(t) \rfloor \ge \lfloor \sqrt[n]{m} \rfloor$ for any $t$ in the domain. This proves that, when $\lfloor f(t) \rfloor \le \lfloor \sqrt[n]{m} \rfloor$ becomes true (it does because the sequence of estimates is strictly decreasing), we get $\lfloor f(t) \rfloor = \lfloor \sqrt[n]{m} \rfloor$ and the loop stops at the next iteration.

> The proof of the algorithm makes use of Newton's formula x i + 1 = f ( x i ) , where f is the real-valued counterpart of the integer recurrence formula in the algorithm. It is straightforward to see that x i + 1 > x 1 / n when 0 < x i < x 1 / n . But it's less clear to me that the same applies to the _integer_ recurrence formula of the algorithm.

It should be clear if we note that the integer-valued analogous formula simply discard the fraction part of the real-valued counterpart:
$\lfloor f(t) \rfloor = \lfloor  \lfloor (n-1) t + m/t^{n-1}  \rfloor / n \rfloor$ = $\lfloor ((n-1) t + m/t^{n-1}) / n \rfloor$

So, if $x_i < \lfloor \sqrt[n]{m} \rfloor$, then $((n-1) x_i + m/x_i^{n-1}) / n > \sqrt[n]{m}$, hence $\lfloor f(x_i) \rfloor \ge \lfloor \sqrt[n]{m} \rfloor$.

>From what has just been shown, it follows that it is sufficient to perform an initial iteration before starting the loop to get an overestimate.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2226698680

From duke at openjdk.org  Wed Jul 23 21:19:54 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 23 Jul 2025 21:19:54 GMT
Subject: RFR: 8077587: BigInteger Roots [v39]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <BqtdcGS4Ql5k1jq-XCpGvScQIgC3epi1ckg2w0VLyhg=.2090b5c8-6781-4371-bed2-704832388668@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 84 commits:

 - Merge branch 'openjdk:master' into nth-root-branch
 - Revision changes
 - More accurate lower bound for doubles values tests
 - No need to ceiling the initial estimate if not shifted
 - Ensure an initial overestimate of the root
   
   Ensure an initial overestimate of the root, using Math.exp() and Math.log(), whose error is guaranteed to be less than 1 ulp.
 - Merge branch 'nth-root-branch' of https://github.com/fabioromano1/jdk into nth-root-branch
 - Added bug id
 - Refinement of javadoc for nth root
 - No need to check for root's shift overflow
 - Include one more possible correct bit in initial estimate
 - ... and 74 more: https://git.openjdk.org/jdk/compare/ad510fb2...ec5816dd

-------------

Changes: https://git.openjdk.org/jdk/pull/24898/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=38
  Stats: 408 lines in 3 files changed: 406 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From rgiulietti at openjdk.org  Wed Jul 23 23:22:57 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 23 Jul 2025 23:22:57 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <YwUgf4i5k8ZL0M-VEpGzWI0fnqt_U82sLr63dpqiigk=.12667c79-9ae2-4df5-a699-5f7de6123b89@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <hlJRzBO6IWnQ1naGAPRydFUxc7dqbhIGY-ak7va0jCY=.e1965f33-4206-49ec-8403-4bf9ff7aee65@github.com>
 <UYLJINZ26NuZAcCc6jq0KCpI11uVwVOWSGNrkXcLUIk=.70bdaf9b-b066-454f-806a-e3b104588f2d@github.com>
 <jAyW8BztvN-9vdU9r1pTdFFMuTK4VPrz3lrGNJPUSsQ=.22b8c9ac-5001-47f9-9b23-ae32454fb47d@github.com>
 <xgskj4LLvFR3upWuqjKEDVCLQ4uEXrorlfxlimZ17ts=.6ae32e3b-56c8-453b-a369-f806fa2ec3fa@github.com>
 <pxDJ-FDB5HTPVFtzBvvOSbf_xyVl3X2l-bLO_dSlYPo=.4bf70293-3d20-47c6-8fb2-5495b8d9c0f6@github.com>
 <ha_WXueBRc1kLuQebAFJVsVBf_1Cc38a4uZk-0q_7uQ=.96670b81-b3c5-42fb-87cb-df5386c86581@github.com>
 <acXJtjtRG_TOEC6A9eQWC-0jfiCMCnF5EoDBxEVFysU=.c74ae4f3-4840-4041-b3a3-32c9259de8fd@github.com>
 <YwUgf4i5k8ZL0M-VEpGzWI0fnqt_U82sLr63dpqiigk=.12667c79-9ae2-4df5-a699-5f7de6123b89@github.com>
Message-ID: <ySIVY3xOUfep9iqqL3njtI39ObsYRMBPSSITqUbGHHg=.0f079a4f-23bd-4993-87cb-6232742d3494@github.com>

On Wed, 23 Jul 2025 21:11:16 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> I noticed the usage of exp() and log(), thanks for the change.
>> 
>> My concerns about using transcendental are rooted in [this paper](https://members.loria.fr/PZimmermann/papers/accuracy.pdf).
>> The Javadoc claims an error of 1 ulp for pow(), but it turns out to be plainly wrong: the worst _known_ error is 636 ulps! (In that paper, see the column for OpenLibm, a derivative work of fdlibm.)
>> 
>> On a more positive side, that paper also shows the worst _known_ error for exp() and log() to be around 0.95 ulps. But again, it could be much worse, who knows?
>> 
>> The Brent & Zimmermann paper assumes an initial estimate $u \ge \lfloor x^{1/n}\rfloor$, probably for a (unstated) reason.
>> The proof of the algorithm makes use of Newton's formula $x_{i+1} = f(x_i)$, where $f$ is the real-valued counterpart of the integer recurrence formula in the algorithm.
>> It is straightforward to see that $x_{i+1} > x^{1/n}$ when $0 < x_i < x^{1/n}$.
>> But it's less clear to me that the same applies to the _integer_ recurrence formula of the algorithm.
>> 
>> Given all of the above, we must ensure that the initial estimate meets the requirements of the BZ paper, or we need a proof that an underestimate in the 1st iteration is harmless because it will become an overestimate in the 2nd, i.e., that the reasoning which holds for the real-valued $f$ also holds with the integer-valued analogous formula.
>
> @rgiulietti
>> The Brent & Zimmermann paper assumes an initial estimate u ? ? x 1 / n ? , probably for a (unstated) reason.
> 
> The reason is the condition to stop the loop, since it terminates when the estimate does not decrease anymore.
> 
>> 
>> Given all of the above, we must ensure that the initial estimate meets the requirements of the BZ paper, or we need a proof that an underestimate in the 1st iteration is harmless because it will become an overestimate in the 2nd, i.e., that the reasoning which holds for the real-valued f also holds with the integer-valued analogous formula.
> 
> In Brent & Zimmermann proof, we have the following definition: $f(t) := [ (n-1) t + m/t^{n-1}] / n$, with $t \in (0; +\infty)$. Since $f(t)' < 0$ if $t < \sqrt[n]{m}$ and $f(t)' > 0$ if $t > \sqrt[n]{m}$, then $\sqrt[n]{m}$ is a point of minimum, so $f(t) \ge f(\sqrt[n]{m}) = \sqrt[n]{m}$, hence $\lfloor f(t) \rfloor \ge \lfloor \sqrt[n]{m} \rfloor$ for any $t$ in the domain. This proves that, when $\lfloor f(t) \rfloor \le \lfloor \sqrt[n]{m} \rfloor$ becomes true (it does because the sequence of estimates is strictly decreasing), we get $\lfloor f(t) \rfloor = \lfloor \sqrt[n]{m} \rfloor$ and the loop stops at the next iteration.
> 
>> The proof of the algorithm makes use of Newton's formula x i + 1 = f ( x i ) , where f is the real-valued counterpart of the integer recurrence formula in the algorithm. It is straightforward to see that x i + 1 > x 1 / n when 0 < x i < x 1 / n . But it's less clear to me that the same applies to the _integer_ recurrence formula of the algorithm.
> 
> It should be clear if we note that the integer-valued analogous formula simply discard the fraction part of the real-valued counterpart:
> $\lfloor f(t) \rfloor  = \lfloor [(n-1) t + m/t^{n-1}] / n \rfloor = \lfloor  \lfloor (n-1) t + m/t^{n-1}  \rfloor / n \rfloor$
> 
> So, if $x_i < \lfloor \sqrt[n]{m} \rfloor$, then $[(n-1) x_i + m/x_i^{n-1}] / n > \sqrt[n]{m}$, hence $\lfloor f(x_i) \rfloor \ge \lfloor \sqrt[n]{m} \rfloor$.
> 
> From what has just been shown, it follows that it is sufficient to perform an initial iteration before starting the loop to get an overestimate.

Everything above is already present in BZ, except for your insight that $\lfloor f(s)\rfloor = \hat{f}(s)$, where $\hat{f}$ is the integer-valued recurrence function computed by the algorithm.
So yes, this is a proof that an initial positive integer underestimate leads to a (weak) integer overestimate after one iteration. From then on, BZ shows termination and correctness.

I think that a note in a comment like the following would be helpful:
"The integer-valued recurrence formula in the algorithm of Brent&Zimmermann simply discard the fraction part of the real-valued Newton recurrence on f discussed in the referenced work. As a consequence, an initial underestimate (not discussed in BZ) will immediately lead to a (weak) overestimate during the 1st iteration, thus meeting BZ requirements for termination and correctness."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2226936195

From duke at openjdk.org  Thu Jul 24 03:45:00 2025
From: duke at openjdk.org (erifan)
Date: Thu, 24 Jul 2025 03:45:00 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: <NJYm4IbrGv5JHoG9x991hDNotRDGNDi68VlVRrDV8oI=.ee9a5e26-ab63-4dee-8473-9c75dc8724d2@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 , could you please take a look at this patch? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-3111851722

From jrose at openjdk.org  Thu Jul 24 06:10:01 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 24 Jul 2025 06:10:01 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: <OQ2sjHpt-C0N9p8xrqcPj8p3QgfMsvDGL_VjXZEbG8M=.540d2bc1-c99b-40ce-877c-ad626c923250@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

Good fix.  I added some minor comments.  No logic changes requested!

I'm a little surprised to see the second annotation has survived; I'd prefer to see it totally nuked.  But I am not asking you to remove it; there is an argument that it is helpful.  I requested better documdentation and checking that the two annotations are properly interdependent.  The "runtime setup" annotation should not be allowed except in classes marked as AOT safe.

In a few places you removed an unrelated "non-public" comment.  That is not a good cleanup to incorporate in passing, since the comment is actually functional.

If somebody is arguing that such comments are somehow detrimental, let them make a separate argument and a separate PR to purge them.

src/hotspot/share/classfile/classFileParser.cpp line 5179:

> 5177:       log_info(aot, init)("Found @AOTSafeClassInitializer class %s", ik->external_name());
> 5178:     }
> 5179:   }

This would be a good place to validate that the runtime-setup annotation is only placed on `@AOTSCI` classes.

src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java line 47:

> 45:  * All bound arguments are encapsulated in dedicated species.
> 46:  */
> 47: /*non-public*/

please keep this comment intact; it reminds maintainers that the non-public access of this class is not accidental

src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 67:

> 65:  * @param <S> species data type.
> 66:  */
> 67: /*non-public*/

please keep this comment intact; it reminds maintainers that the non-public access of this class is not accidental

src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line 39:

> 37:  * @author jrose
> 38:  */
> 39: /*non-public*/

please keep this comment intact; it reminds maintainers that the non-public access of this class is not accidental

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 75:

> 73:  * @author jrose
> 74:  */
> 75: /*non-public*/

please keep this comment intact; it reminds maintainers that the non-public access of this class is not accidental

src/java.base/share/classes/jdk/internal/vm/annotation/AOTRuntimeSetup.java line 39:

> 37: ///
> 38: /// `classFileParser.cpp` performs checks on the annotated method - if the
> 39: /// annotated method's signature differs from that described above, a

add:

 /// `classFileParser.cpp` performs checks on the annotated method - if the
 /// annotated method's signature differs from that described above,
+/// or if the enclosing class is not annotated `@AOTSafeClassInitializer`,
 /// a [ClassFormatError] will be thrown.


Otherwise, there are just some late-firing asserts that catch the error.
But the dependency of one annotation on the other should be documented up front.

-------------

Changes requested by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-3050063235
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2227419561
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2227480716
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2227481353
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2227482049
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2227484671
PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2227401171

From rgiulietti at openjdk.org  Thu Jul 24 08:45:01 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 24 Jul 2025 08:45:01 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <ySIVY3xOUfep9iqqL3njtI39ObsYRMBPSSITqUbGHHg=.0f079a4f-23bd-4993-87cb-6232742d3494@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <hlJRzBO6IWnQ1naGAPRydFUxc7dqbhIGY-ak7va0jCY=.e1965f33-4206-49ec-8403-4bf9ff7aee65@github.com>
 <UYLJINZ26NuZAcCc6jq0KCpI11uVwVOWSGNrkXcLUIk=.70bdaf9b-b066-454f-806a-e3b104588f2d@github.com>
 <jAyW8BztvN-9vdU9r1pTdFFMuTK4VPrz3lrGNJPUSsQ=.22b8c9ac-5001-47f9-9b23-ae32454fb47d@github.com>
 <xgskj4LLvFR3upWuqjKEDVCLQ4uEXrorlfxlimZ17ts=.6ae32e3b-56c8-453b-a369-f806fa2ec3fa@github.com>
 <pxDJ-FDB5HTPVFtzBvvOSbf_xyVl3X2l-bLO_dSlYPo=.4bf70293-3d20-47c6-8fb2-5495b8d9c0f6@github.com>
 <ha_WXueBRc1kLuQebAFJVsVBf_1Cc38a4uZk-0q_7uQ=.96670b81-b3c5-42fb-87cb-df5386c86581@github.com>
 <acXJtjtRG_TOEC6A9eQWC-0jfiCMCnF5EoDBxEVFysU=.c74ae4f3-4840-4041-b3a3-32c9259de8fd@github.com>
 <YwUgf4i5k8ZL0M-VEpGzWI0fnqt_U82sLr63dpqiigk=.12667c79-9ae2-4df5-a699-5f7de6123b89@github.com>
 <ySIVY3xOUfep9iqqL3njtI39ObsYRMBPSSI
 TqUbGHHg=.0f079a4f-23bd-4993-87cb-6232742d3494@github.com>
Message-ID: <n3JHFx88H55huPBejCRegMUoSj-shxg9_WzTVX3LMV8=.e7ea66cf-7d7b-4dbf-84fb-bc9407d57262@github.com>

On Wed, 23 Jul 2025 23:19:49 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti
>>> The Brent & Zimmermann paper assumes an initial estimate u ? ? x 1 / n ? , probably for a (unstated) reason.
>> 
>> The reason is the condition to stop the loop, since it terminates when the estimate does not decrease anymore.
>> 
>>> 
>>> Given all of the above, we must ensure that the initial estimate meets the requirements of the BZ paper, or we need a proof that an underestimate in the 1st iteration is harmless because it will become an overestimate in the 2nd, i.e., that the reasoning which holds for the real-valued f also holds with the integer-valued analogous formula.
>> 
>> In Brent & Zimmermann proof, we have the following definition: $f(t) := [ (n-1) t + m/t^{n-1}] / n$, with $t \in (0; +\infty)$. Since $f(t)' < 0$ if $t < \sqrt[n]{m}$ and $f(t)' > 0$ if $t > \sqrt[n]{m}$, then $\sqrt[n]{m}$ is a point of minimum, so $f(t) \ge f(\sqrt[n]{m}) = \sqrt[n]{m}$, hence $\lfloor f(t) \rfloor \ge \lfloor \sqrt[n]{m} \rfloor$ for any $t$ in the domain. This proves that, when $\lfloor f(t) \rfloor \le \lfloor \sqrt[n]{m} \rfloor$ becomes true (it does because the sequence of estimates is strictly decreasing), we get $\lfloor f(t) \rfloor = \lfloor \sqrt[n]{m} \rfloor$ and the loop stops at the next iteration.
>> 
>>> The proof of the algorithm makes use of Newton's formula x i + 1 = f ( x i ) , where f is the real-valued counterpart of the integer recurrence formula in the algorithm. It is straightforward to see that x i + 1 > x 1 / n when 0 < x i < x 1 / n . But it's less clear to me that the same applies to the _integer_ recurrence formula of the algorithm.
>> 
>> It should be clear if we note that the integer-valued analogous formula simply discard the fraction part of the real-valued counterpart:
>> $\lfloor f(t) \rfloor  = \lfloor [(n-1) t + m/t^{n-1}] / n \rfloor = \lfloor  \lfloor (n-1) t + m/t^{n-1}  \rfloor / n \rfloor$
>> 
>> So, if $x_i < \lfloor \sqrt[n]{m} \rfloor$, then $[(n-1) x_i + m/x_i^{n-1}] / n > \sqrt[n]{m}$, hence $\lfloor f(x_i) \rfloor \ge \lfloor \sqrt[n]{m} \rfloor$.
>> 
>> From what has just been shown, it follows that it is sufficient to perform an initial iteration before starting the loop to get an overestimate.
>
> Everything above is already present in BZ, except for your insight that $\lfloor f(s)\rfloor = \hat{f}(s)$, where $\hat{f}$ is the integer-valued recurrence function computed by the algorithm.
> So yes, this is a proof that an initial positive integer underestimate leads to a (weak) integer overestimate after one iteration. From then on, BZ shows termination and correctness.
> 
> I think that a note in a comment like the following would be helpful:
> "The integer-valued recurrence formula in the algorithm of Brent&Zimmermann simply discard the fraction part of the real-valued Newton recurrence on f discussed in the referenced work. As a consequence, an initial underestimate (not discussed in BZ) will immediately lead to a (weak) overestimate during the 1st iteration, thus meeting BZ requirements for termination and correctness."

Correction:

"The integer-valued recurrence formula in the algorithm of Brent&Zimmermann simply discards the fraction part of the real-valued Newton recurrence on f discussed in the referenced work.
(Indeed, for real $x$ and integer $n > 0$, the equality $\lfloor x / n \rfloor = \lfloor \lfloor x \rfloor / n \rfloor$ holds, from which the claim follows.)
As a consequence, an initial underestimate (not discussed in BZ) will immediately lead to a (weak) overestimate during the 1st iteration, thus meeting BZ requirements for termination and correctness."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2227858171

From duke at openjdk.org  Thu Jul 24 09:55:49 2025
From: duke at openjdk.org (Darragh Conway)
Date: Thu, 24 Jul 2025 09:55:49 GMT
Subject: RFR: 8363720: Follow up to JDK-8360411 with post review comments
 [v2]
In-Reply-To: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
References: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
Message-ID: <_ok-Dps1xGrWAQ91iDfgD6AW0CAmpJnUEUFC-CmD6TM=.17660e49-b020-4e7b-aac6-14b47e6c056b@github.com>

> There were a couple of post review comments after the /integrate command was submitted. This issue will address those comments. Also created constants for hardcoded values and tests. Fixed some typos.

Darragh Conway has updated the pull request incrementally with one additional commit since the last revision:

  Fix indentation issues

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26445/files
  - new: https://git.openjdk.org/jdk/pull/26445/files/cc34a0a1..061dc647

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26445&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26445&range=00-01

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26445.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26445/head:pull/26445

PR: https://git.openjdk.org/jdk/pull/26445

From duke at openjdk.org  Thu Jul 24 10:06:39 2025
From: duke at openjdk.org (Darragh Conway)
Date: Thu, 24 Jul 2025 10:06:39 GMT
Subject: RFR: 8363720: Follow up to JDK-8360411 with post review comments
 [v3]
In-Reply-To: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
References: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
Message-ID: <bxhUtcshp1dDVJgMzQtJAGz5C6u4ckZ3KGiBdpWLh20=.431191d5-0682-4983-9598-280763356282@github.com>

> There were a couple of post review comments after the /integrate command was submitted. This issue will address those comments. Also created constants for hardcoded values and tests. Fixed some typos.

Darragh Conway has updated the pull request incrementally with one additional commit since the last revision:

  Fix remaining indentation errors (From my first commit on this branch)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26445/files
  - new: https://git.openjdk.org/jdk/pull/26445/files/061dc647..7468b4b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26445&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26445&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26445.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26445/head:pull/26445

PR: https://git.openjdk.org/jdk/pull/26445

From galder at openjdk.org  Thu Jul 24 10:34:38 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 24 Jul 2025 10:34:38 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F
Message-ID: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>

I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations.

Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows:


Benchmark                                (seed)  (size)   Mode  Cnt      Base      Patch   Units   Diff
VectorBitConversion.doubleToLongBits          0    2048  thrpt    8  1168.782   1157.717  ops/ms    -1%
VectorBitConversion.doubleToRawLongBits       0    2048  thrpt    8  3999.387   7353.936  ops/ms   +83%
VectorBitConversion.floatToIntBits            0    2048  thrpt    8  1200.338   1188.206  ops/ms    -1%
VectorBitConversion.floatToRawIntBits         0    2048  thrpt    8  4058.248  14792.474  ops/ms  +264%
VectorBitConversion.intBitsToFloat            0    2048  thrpt    8  3050.313  14984.246  ops/ms  +391%
VectorBitConversion.longBitsToDouble          0    2048  thrpt    8  3022.691   7379.360  ops/ms  +144%


The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control.

I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions.

-------------

Commit messages:
 - Removed unnecessary assert methods
 - Adjust IR test after adding Move* vector support
 - Delete IR test because it's already covered by other test
 - Merge branch 'master' into topic.fp-bits-vector
 - Add longBitsToDouble and intBitsToFloat
 - Fix test for vectorized and add floatToRawIntBits
 - Add basic IR test
 - Add JMH benchmark for doubleTo*LongBits
 - Support doubleToRawLongBits
 - add floatToIntBits benchmark
 - ... and 4 more: https://git.openjdk.org/jdk/compare/c68697e1...b6ec784e

Changes: https://git.openjdk.org/jdk/pull/26457/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26457&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329077
  Stats: 164 lines in 7 files changed: 153 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26457/head:pull/26457

PR: https://git.openjdk.org/jdk/pull/26457

From duke at openjdk.org  Thu Jul 24 10:39:38 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 24 Jul 2025 10:39:38 GMT
Subject: RFR: 8077587: BigInteger Roots [v40]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <CEVhf0SP3FlbBu_o-Bbncpwy92qpeqHoEgSQ2RnSf8M=.5344058a-dae1-46fb-b348-44c946b36094@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Ensure an initial overestimate of the root
  
  Ensure an initial overestimate of the root by doing 1st iteration outside the loop.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/ec5816dd..6e10645f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=39
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=38-39

  Stats: 22 lines in 1 file changed: 14 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From swen at openjdk.org  Thu Jul 24 10:45:57 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 24 Jul 2025 10:45:57 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v8]
In-Reply-To: <sE0TFDey2bGBWZgaYZYT-TL2MU7vzHolAliJFcBE9-w=.42ae0a78-eece-4529-a901-9de3917a16b1@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
 <sE0TFDey2bGBWZgaYZYT-TL2MU7vzHolAliJFcBE9-w=.42ae0a78-eece-4529-a901-9de3917a16b1@github.com>
Message-ID: <O-d-CiwSiqxGad-tZPmP736C3MA3kcNVOTj41n6_fHA=.67d3f8e0-904c-4722-b84b-c57dd770e31f@github.com>

On Tue, 22 Jul 2025 04:03:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> I just noticed there is `LibraryCallKit::inline_string_getCharsU` that is for byte -> char conversion. I wonder if we can slightly update it for char -> byte conversion.

If the performance is the same, the current proposal to use Unsafe should be more maintainable, and the maintainer only needs to know Java. If intrinsics are used, the maintainer needs to know C++, Java, and intrinsic mechanisms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-3112974656

From djelinski at openjdk.org  Thu Jul 24 12:25:14 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 24 Jul 2025 12:25:14 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
Message-ID: <4kAWa2wgbihXfl3lGOhZJ3sNAFh3RwlPMRT9ZeQpYiY=.68e72d2f-3477-4f01-a4da-4e88ecedd3ed@github.com>

On Tue, 8 Jul 2025 14:04:56 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 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

test/jdk/java/net/httpclient/http3/BadCipherSuiteErrorTest.java line 59:

> 57:  * causing hang problems
> 58:  */
> 59: public class BadCipherSuiteErrorTest implements HttpServerAdapters {

This test overlaps with H3QuicTLSConnection test. Any reason to keep them separate?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2228364279

From duke at openjdk.org  Thu Jul 24 13:04:43 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 24 Jul 2025 13:04:43 GMT
Subject: RFR: 8077587: BigInteger Roots [v41]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <yG_gw3ZXBywYe8gLCgB09jok9vknWQiMELV2Xs42jJQ=.58f6facc-33c4-4885-b203-5d51a08cdff9@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Added pow() -nthRoot() roundtrip tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/6e10645f..bccb8c34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=40
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=39-40

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From rgiulietti at openjdk.org  Thu Jul 24 13:32:58 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 24 Jul 2025 13:32:58 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v8]
In-Reply-To: <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
Message-ID: <I65deGg4JVnbt9YdlraqFb4g4RQ-9sztwNwopOvuFvc=.ce964a62-eef3-40a9-a11c-f7368991456b@github.com>

On Fri, 27 Jun 2025 01:04:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string.
>> 
>> For these scenarios, we can Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed.
>> 
>> @RogerRiggs completed the optimization when the encoder is LATIN1 in PR #24967. This PR continues to complete the optimization when the encoder is UTF16.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/StringUTF16.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

src/java.base/share/classes/java/lang/StringUTF16.java line 1490:

> 1488:                 val,
> 1489:                 Unsafe.ARRAY_BYTE_BASE_OFFSET + ((long) index << 1),
> 1490:                 (long) (end - off) << 1);

The documentation of `copyMemory()` is not super-clear about endianness.
But it seems to imply that in this case it behaves as if it were to copy `short`s, so endianness seems to be preserved.

The invocation of `copyMemory()` here implicitly assumes that `ARRAY_CHAR_INDEX_SCALE` and `ARRAY_BYTE_INDEX_SCALE` are 2 and 1, resp., which seems quite reasonable but not written in the stone.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2228500325

From dl at openjdk.org  Thu Jul 24 13:59:54 2025
From: dl at openjdk.org (Doug Lea)
Date: Thu, 24 Jul 2025 13:59:54 GMT
Subject: RFR: 8362882: Update SubmissionPublisher() specification to
 reflect use of ForkJoinPool.asyncCommonPool()
In-Reply-To: <jqlYivNsVPTONrGSgVmeH0CeXH2JCs2nUWPJ99C13xs=.205b8340-72a8-4e8b-9248-b2470f3d81c5@github.com>
References: <jqlYivNsVPTONrGSgVmeH0CeXH2JCs2nUWPJ99C13xs=.205b8340-72a8-4e8b-9248-b2470f3d81c5@github.com>
Message-ID: <0An6vfR0nVTdrH5JG72BZviUrz18J7BozOH0EoRlzSE=.bd47d813-9f9c-4af0-bbf3-ad44d663d05f@github.com>

On Tue, 22 Jul 2025 13:13:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The changes in JDK-8319447 to improve the performance of delayed task handling updated CompletableFuture and SubmissionPublisher to use the ForkJoinPool commonPool in all cases. These APIs previously created a Thread for each task when parallelism was less than 2. We missed the update to SubmissionPublisher's no-arg constructor in that update.

Yes, sorry to have missed this before.

-------------

Marked as reviewed by dl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26426#pullrequestreview-3051794583

From rriggs at openjdk.org  Thu Jul 24 14:08:57 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Jul 2025 14:08:57 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v12]
In-Reply-To: <Z0qfXQIIg9tHXGWA6ZSDuEiFXjY535lENUx7k59xIUc=.a3adfad6-79b1-4af7-9151-6acf0b44edd6@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <Z0qfXQIIg9tHXGWA6ZSDuEiFXjY535lENUx7k59xIUc=.a3adfad6-79b1-4af7-9151-6acf0b44edd6@github.com>
Message-ID: <KKkCYGaQEVck6JjJqAp3Ndh7hmV80dLdY51_Qhsw49A=.4fbfba9e-d5c3-4197-bba8-01a2695b72fa@github.com>

On Wed, 23 Jul 2025 12:54:00 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 IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` 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...
>
> Volkan Yazici has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Add `@bug` tags
>  - Improve wording of `@param len`
>  - Make source array bound checks lenient too
>  - Cap destination array bounds

Will re-review when the changes settle.

-------------

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25998#pullrequestreview-3051829566

From liach at openjdk.org  Thu Jul 24 14:23:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Jul 2025 14:23:58 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v8]
In-Reply-To: <I65deGg4JVnbt9YdlraqFb4g4RQ-9sztwNwopOvuFvc=.ce964a62-eef3-40a9-a11c-f7368991456b@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
 <I65deGg4JVnbt9YdlraqFb4g4RQ-9sztwNwopOvuFvc=.ce964a62-eef3-40a9-a11c-f7368991456b@github.com>
Message-ID: <NPd54DHdF-RbZTJSTtEtSkHm4KGup1sao_HjCjdUChU=.9ec9394d-72ef-403c-8236-4979a952804b@github.com>

On Thu, 24 Jul 2025 13:18:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/lang/StringUTF16.java
>>   
>>   Co-authored-by: Chen Liang <liach at openjdk.org>
>
> src/java.base/share/classes/java/lang/StringUTF16.java line 1490:
> 
>> 1488:                 val,
>> 1489:                 Unsafe.ARRAY_BYTE_BASE_OFFSET + ((long) index << 1),
>> 1490:                 (long) (end - off) << 1);
> 
> The documentation of `copyMemory()` is not super-clear about endianness.
> But it seems to imply that in this case it behaves as if it were to copy `short`s, so endianness seems to be preserved.
> 
> The invocation of `copyMemory()` here implicitly assumes that `ARRAY_CHAR_INDEX_SCALE` and `ARRAY_BYTE_INDEX_SCALE` are 2 and 1, resp., which seems quite reasonable but not written in the stone.

I recall runtime requires UTF16 byte array and char array have exactly the same layout - would be nice if we keep this in the design notes for the string implementation classes, such as on the class header.

(Useful notes could include that indices are char-based, UTF16 byte[] and char[] has identical layout, etc.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2228671899

From rriggs at openjdk.org  Thu Jul 24 14:40:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Jul 2025 14:40:56 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v8]
In-Reply-To: <NPd54DHdF-RbZTJSTtEtSkHm4KGup1sao_HjCjdUChU=.9ec9394d-72ef-403c-8236-4979a952804b@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
 <I65deGg4JVnbt9YdlraqFb4g4RQ-9sztwNwopOvuFvc=.ce964a62-eef3-40a9-a11c-f7368991456b@github.com>
 <NPd54DHdF-RbZTJSTtEtSkHm4KGup1sao_HjCjdUChU=.9ec9394d-72ef-403c-8236-4979a952804b@github.com>
Message-ID: <OB-Z7utWaBYE0CKQCyApMsITbbiX7VH8PLYbHaU45Ck=.e7f3859f-d458-41ae-ba72-014e409127ff@github.com>

On Thu, 24 Jul 2025 14:20:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringUTF16.java line 1490:
>> 
>>> 1488:                 val,
>>> 1489:                 Unsafe.ARRAY_BYTE_BASE_OFFSET + ((long) index << 1),
>>> 1490:                 (long) (end - off) << 1);
>> 
>> The documentation of `copyMemory()` is not super-clear about endianness.
>> But it seems to imply that in this case it behaves as if it were to copy `short`s, so endianness seems to be preserved.
>> 
>> The invocation of `copyMemory()` here implicitly assumes that `ARRAY_CHAR_INDEX_SCALE` and `ARRAY_BYTE_INDEX_SCALE` are 2 and 1, resp., which seems quite reasonable but not written in the stone.
>
> I recall runtime requires UTF16 byte array and char array have exactly the same layout - would be nice if we keep this in the design notes for the string implementation classes, such as on the class header.
> 
> (Useful notes could include that indices are char-based, UTF16 byte[] and char[] has identical layout, etc.)

The StringUTF16.getChar and putChar methods are carefully written to use the platform endianness to compose and decompose char values from and to byte[] in terms of shifts of the lower and upper bytes.
The mapping of that into other apis that try to optimize between char[] and the compact string byte[] are less well documented.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2228721098

From duke at openjdk.org  Thu Jul 24 14:59:31 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Thu, 24 Jul 2025 14:59:31 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc.
Message-ID: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>

Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.


if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
    throw new Exception("exceeding length");
}


Is a CSR required to this change?

-------------

Commit messages:
 - Remove trailing spaces
 - 8364007: Add overload without arguments to codePointCount in String etc.

Changes: https://git.openjdk.org/jdk/pull/26461/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364007
  Stats: 112 lines in 13 files changed: 95 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/26461.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461

PR: https://git.openjdk.org/jdk/pull/26461

From duke at openjdk.org  Thu Jul 24 14:59:51 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 24 Jul 2025 14:59:51 GMT
Subject: RFR: 8077587: BigInteger Roots [v42]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <Eofxf16bIamEdA9m2SCPpiB67QsMTe557-rWePP0TSk=.41394004-7fc8-4de7-b84e-ff0ae2fa14d0@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Use checkResult() in pow-nthRoot roundtrip tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/bccb8c34..1dfa232f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=40-41

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From rriggs at openjdk.org  Thu Jul 24 15:15:01 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Jul 2025 15:15:01 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc.
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <_ZiQNuzt_mXMGd0GGi1XZhAjYFu0lc0ULkdlRdWQ-qE=.19c4501b-aa62-4b2f-b996-aed285ecc781@github.com>

On Thu, 24 Jul 2025 14:50:07 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

The recommended process for proposing new APIs is to put the proposal to the OpenJDK core-libs-dev mail alias.
Putting the effort into a PR before there is some agreement on the value is premature.
And yes, every change to the spec needs a CSR.

To keep the proposal focused on the APIs, please drop the changes to modules other than java.base.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3113849427
PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3113856629

From duke at openjdk.org  Thu Jul 24 15:20:14 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 24 Jul 2025 15:20:14 GMT
Subject: RFR: 8077587: BigInteger Roots [v43]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <9g-MJ9FAcObSCYxosAVw-tXg65vtUnAUlUhy7WeFb_M=.297075c2-7094-4faf-a504-01bf33373156@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Update BigIntegerTest.java
  
  Adjust pow-nthRoot roundtrip tests to handle negative base with even exponent.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/1dfa232f..c9cb4ec1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=42
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=41-42

  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From djelinski at openjdk.org  Thu Jul 24 15:23:15 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 24 Jul 2025 15:23:15 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
Message-ID: <rjOdFLUipPEg5WANViULncjttCDE1vafjjR0wzhi4HE=.55628aae-59c2-4d50-848a-771154bcd45c@github.com>

On Tue, 8 Jul 2025 14:04:56 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 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

test/jdk/java/net/httpclient/http3/H3SimpleTest.java line 47:

> 45: /*
> 46:  * @test
> 47:  * @summary Basic test to verify HTTP3 requests from HttpClient with security manager enabled

nothing in this test references the security manager.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2228837216

From rgiulietti at openjdk.org  Thu Jul 24 15:24:04 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 24 Jul 2025 15:24:04 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v8]
In-Reply-To: <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
Message-ID: <Akc09cL762LAM8tZXqUuyIZiwKyYQpABKjAjjhqjeT0=.eadecf6b-1a3c-4061-8951-537e6e24742c@github.com>

On Fri, 27 Jun 2025 01:04:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string.
>> 
>> For these scenarios, we can Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed.
>> 
>> @RogerRiggs completed the optimization when the encoder is LATIN1 in PR #24967. This PR continues to complete the optimization when the encoder is UTF16.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/StringUTF16.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

src/java.base/share/classes/java/lang/StringUTF16.java line 1487:

> 1485:         Unsafe.getUnsafe().copyMemory(
> 1486:                 ca,
> 1487:                 Unsafe.ARRAY_CHAR_BASE_OFFSET + ((long) off << 1),

Suggestion:

                Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off * Unsafe.ARRAY_CHAR_INDEX_SCALE,

src/java.base/share/classes/java/lang/StringUTF16.java line 1489:

> 1487:                 Unsafe.ARRAY_CHAR_BASE_OFFSET + ((long) off << 1),
> 1488:                 val,
> 1489:                 Unsafe.ARRAY_BYTE_BASE_OFFSET + ((long) index << 1),

Suggestion:

                Unsafe.ARRAY_BYTE_BASE_OFFSET + ((long) index << 1) * Unsafe.ARRAY_BYTE_INDEX_SCALE,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2228828535
PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2228829451

From duke at openjdk.org  Thu Jul 24 15:35:14 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 24 Jul 2025 15:35:14 GMT
Subject: RFR: 8077587: BigInteger Roots [v44]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <g9_lXRaZhggluOKSJtqzFieHVVAf5o5_nA1eiFVNsOY=.fef3539d-ffa7-41f2-8f62-cc635e1358b7@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Code simplification

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/c9cb4ec1..c989330e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=43
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=42-43

  Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From liach at openjdk.org  Thu Jul 24 16:24:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Jul 2025 16:24:55 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc.
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <y_R_o6taygSCoX84MIf4aCogNn_yVlejH3hzRVRZSgU=.85b8004b-dab6-4c58-9105-6a86b6cb267a@github.com>

On Thu, 24 Jul 2025 14:50:07 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

Also, do we need `codePointCount` on `CharSequence`?

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 545:

> 543:         byte[] value = this.value;
> 544:         if (isLatin1(coder)) {
> 545:             return value.length;

Suggestion:

            return count;

-------------

PR Review: https://git.openjdk.org/jdk/pull/26461#pullrequestreview-3052346769
PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2228974436

From duke at openjdk.org  Thu Jul 24 17:05:33 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 24 Jul 2025 17:05:33 GMT
Subject: RFR: 8077587: BigInteger Roots [v45]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <I7aYp0FRNnbjVqayzg3HCOhx05ZMnJXih61G0tZHluI=.0cb682ba-bf40-4729-807e-100ce83b5753@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Round up to do less iterations
  
  With the 1st iteration outside the loop, it is more convenient rounding up to ceiling.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/c989330e..29ec5146

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=44
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=43-44

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From jd at civilian-framework.org  Thu Jul 24 17:33:40 2025
From: jd at civilian-framework.org (=?UTF-8?Q?Johannes_D=C3=B6bler?=)
Date: Thu, 24 Jul 2025 19:33:40 +0200
Subject: String.charAt vs StringBuilder.charAt performance
In-Reply-To: <CANBJVOHC0533A7JMhckoDJ1X2SJQDbS=cccCpTECaSmAQzc3xQ@mail.gmail.com>
References: <CANBJVOHxaDv5q3GJPX8dn2GepcU9de39phavquaxKNXGZrMRrA@mail.gmail.com>
 <CABe8uE0UJ_=Vb842cTTnE4tuGPWDMKDb0bkD9CCvqNKQfXF20Q@mail.gmail.com>
 <CANBJVOFUEEt1GdM59D27cXbEzG9ZZZaafPsJqt6uQ+gwjruVKw@mail.gmail.com>
 <fd0e5706-7c69-42e1-8b58-da5281569cda@oracle.com>
 <CANBJVOHbJxR9TCLW4OWuN2uMP4TN-ZKhJTvOwZeUvXYQOv0j6g@mail.gmail.com>
 <b443c697-c396-4bb4-8fb2-50304491dc58@oracle.com>
 <CANBJVOFNRcsSfAyT_AsS5Km=-uoA-rJLVJA1i4zrmJg4dEykPQ@mail.gmail.com>
 <SJ2PR10MB76699AD4DCB8423D0DCE9306A25DA@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOEhj97O-iNzEAq+pckhRD8FmzThetowJS9V_mFWpRGgOQ@mail.gmail.com>
 <CANBJVOHC0533A7JMhckoDJ1X2SJQDbS=cccCpTECaSmAQzc3xQ@mail.gmail.com>
Message-ID: <0f88213a-33aa-4ce0-a907-26e14b9d00b5@civilian-framework.org>

Hi Brett,

I ran your benchmark on a Windows11 Pro 24H2 / ARM64 / JDK 21 system? 
and can reproduce your findings that 
CharSequenceCharAtBenchmark.testString<ascii> has weaker performance.
I also added these benchmarks:
 ??? @Benchmark
 ??? public int testStringBuilderAsCS() {
 ??????? return test(this.stringBuilder);
 ??? }

 ??? @Benchmark
 ??? public int testStringAsCS() {
 ??????? return test(this.string);
 ??? }

 ??? private int test(CharSequence sequence) {
 ??????? int sum = 0;
 ??????? for (int i=0, j=sequence.length(); i<j; ++i) {
 ??????????? sum += sequence.charAt(i);
 ??????? }
 ??????? return sum;
 ??? }

and see a total breakdown of CharSequenceCharAtBenchmark.testStringAsCS

Benchmark (data)? Mode? Cnt???? Score???? Error? Units
CharSequenceCharAtBenchmark.testString???????????????? ascii avgt??? 5? 
1647,439 ?? 70,486? ns/op
CharSequenceCharAtBenchmark.testString???????????? non-ascii avgt??? 5?? 
939,780 ?? 63,896? ns/op
CharSequenceCharAtBenchmark.testStringAsCS???????????? ascii avgt??? 5? 
1657,796 ?? 18,488? ns/op
CharSequenceCharAtBenchmark.testStringAsCS???????? non-ascii avgt??? 5? 
9400,447 ? 290,066? ns/op
CharSequenceCharAtBenchmark.testStringBuilder????????? ascii avgt??? 5?? 
923,943 ??? 6,130? ns/op
CharSequenceCharAtBenchmark.testStringBuilder????? non-ascii avgt??? 5?? 
941,507 ?? 30,786? ns/op
CharSequenceCharAtBenchmark.testStringBuilderAsCS????? ascii avgt??? 5?? 
930,974 ?? 33,187? ns/op
CharSequenceCharAtBenchmark.testStringBuilderAsCS? non-ascii avgt??? 5?? 
945,983 ?? 87,636? ns/op

Best
Johannes

On 22/07/2025 13:44, Brett Okken wrote:
> It does look like this is windows specific. If I run on WSL, I get 
> results similar to your linux-x64:
>
> Benchmark ? ? ? ? ? ? ? ? ? ? ? (data) ?Mode ?Cnt ? ?Score ? ? Error 
> ?Units
> CharSequenceCharAtBenchmark.testString ? ? ? ? ? ? ascii ?avgt ? ?3 
> ?679.294 ? 302.947 ?ns/op
> CharSequenceCharAtBenchmark.testString ? ? ? ? non-ascii ?avgt ? ?3 
> ?702.071 ? 926.959 ?ns/op
> CharSequenceCharAtBenchmark.testStringBuilder ? ? ?ascii ?avgt ? ?3 
> ?682.815 ? 301.649 ?ns/op
> CharSequenceCharAtBenchmark.testStringBuilder ?non-ascii ?avgt ? ?3 
> ?678.169 ? 810.276 ?ns/op
>
> And I go back to the original version of the test, where String vs 
> StringBuilder is defined by parameter and both assigned to same local 
> variable as part of set up, that also shows no difference in wsl.
> So it appears?everything I observed is an artifact of Windows specific 
> intrinsics?
>
> Benchmark ? ? ? ? ? ? ?(data) ? ? ? (source) ?Mode ?Cnt ? ?Score Error 
> ?Units
> CharSequenceCharAtBenchmark.test ? ? ?ascii ? ? ? ? String ?avgt ? ?3 
> ?660.597 ? 146.405 ?ns/op
> CharSequenceCharAtBenchmark.test ? ? ?ascii ?StringBuilder ?avgt ? ?3 
> ?659.395 ? 155.167 ?ns/op
> CharSequenceCharAtBenchmark.test ?non-ascii ? ? ? ? String ?avgt ? ?3 
> ?647.955 ? 189.747 ?ns/op
> CharSequenceCharAtBenchmark.test ?non-ascii ?StringBuilder ?avgt ? ?3 
> ?639.678 ? 146.923 ?ns/op
>
> On Mon, Jul 21, 2025 at 5:13?PM Brett Okken <brett.okken.os at gmail.com> 
> wrote:
>
>     I am running Windows x64. Windows 11 Pro 24H2
>
>     Intel(R) Core(TM) i7-1370P
>
>     On Mon, Jul 21, 2025 at 4:59?PM Chen Liang
>     <chen.l.liang at oracle.com> wrote:
>
>         I finally came around and ran the benchmark on my linux-x64
>         device; however, I could not produce your results where String
>         is significantly slower than StringBuilder.
>
>         This is the results I've got:
>
>         Benchmark (data) ?Mode ?Cnt ? ?Score ? ?Error ?Units
>         CharSequenceCharAtBenchmark.testString ascii ?avgt ? ?5
>         ?668.649 ? 13.895 ?ns/op
>         CharSequenceCharAtBenchmark.testString non-ascii ?avgt ? ?5
>         ?651.903 ? ?7.240 ?ns/op
>         CharSequenceCharAtBenchmark.testStringBuilder ?ascii ?avgt ?
>         ?5 ?673.802 ? 26.260 ?ns/op
>         CharSequenceCharAtBenchmark.testStringBuilder ?non-ascii ?avgt
>         ? ?5 ?657.374 ? 35.785 ?ns/op
>
>         I think we might have more clue - are you testing on a
>         macosx-aarch64 machine or some other platform? It might be
>         that on some platforms, there are some problems in the
>         hand-written assemblies for the intrinsics which contribute to
>         this slowdown, instead of a problem with the C2 IR.
>
>         Chen
>         ------------------------------------------------------------------------
>         *From:*?core-libs-dev <core-libs-dev-retn at openjdk.org> on
>         behalf of Brett Okken <brett.okken.os at gmail.com>
>         *Sent:*?Monday, July 21, 2025 4:01 PM
>         *To:*?Roger Riggs <roger.riggs at oracle.com>
>         *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>         *Subject:*?Re: String.charAt vs StringBuilder.charAt performance
>         Updating to have different?test methods for each
>         representation did remove the difference for the non-ascii
>         String case for the jdk 21+ releases.
>         However, the ascii (latin) strings are still slower with
>         String than StringBuilder.
>
>         How does C2 then handle something like StringCharBuffer
>         wrapping a CharSequence for all of it's?get operations:
>         https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/StringCharBuffer.java#L88-L97
>
>         Which is then used by CharBufferSpliterator
>         https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/CharBufferSpliterator.java
>
>         And by many CharsetEncoder impls when either source or
>         destination is not backed by array (which would be the case if
>         StringCharBuffer used):
>         https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/cs/UTF_8.java#L517
>         https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/cs/UnicodeEncoder.java#L81
>
>
>
>         jdk 17
>         Benchmark (data) ?Mode ?Cnt ? ? Score ? ? Error ?Units
>         CharSequenceCharAtBenchmark.testString ascii ?avgt ? ?3
>         ?1429.358 ? 623.424 ?ns/op
>         CharSequenceCharAtBenchmark.testString non-ascii ?avgt ? ?3 ?
>         705.282 ? 233.453 ?ns/op
>         CharSequenceCharAtBenchmark.testStringBuilder ?ascii ?avgt ?
>         ?3 ? 724.138 ? 267.346 ?ns/op
>         CharSequenceCharAtBenchmark.testStringBuilder ?non-ascii ?avgt
>         ? ?3 ? 718.357 ? 864.066 ?ns/op
>
>         jdk 21
>         Benchmark (data) ?Mode ?Cnt ? ? Score ? ? Error ?Units
>         CharSequenceCharAtBenchmark.testString ascii ?avgt ? ?3
>         ?1087.024 ?? 235.082 ?ns/op
>         CharSequenceCharAtBenchmark.testString non-ascii ?avgt ? ?3 ?
>         687.520 ?? 747.532 ?ns/op
>         CharSequenceCharAtBenchmark.testStringBuilder ?ascii ?avgt ?
>         ?3 ? 672.802 ?? ?29.740 ?ns/op
>         CharSequenceCharAtBenchmark.testStringBuilder ?non-ascii ?avgt
>         ? ?3 ? 689.964 ?? 791.175 ?ns/op
>
>         jdk 25
>         Benchmark (data) ?Mode ?Cnt ? ? Score ? ? ?Error ?Units
>         CharSequenceCharAtBenchmark.testString ascii ?avgt ? ?3
>         ?1176.057 ?? 1157.979 ?ns/op
>         CharSequenceCharAtBenchmark.testString non-ascii ?avgt ? ?3 ?
>         697.382 ?? ?231.144 ?ns/op
>         CharSequenceCharAtBenchmark.testStringBuilder ?ascii ?avgt ?
>         ?3 ? 692.970 ?? ?105.112 ?ns/op
>         CharSequenceCharAtBenchmark.testStringBuilder ?non-ascii ?avgt
>         ? ?3 ? 703.178 ?? ?446.019 ?ns/op
>
>         jdk 26
>         Benchmark (data) ?Mode ?Cnt ? ? Score ? ? Error ?Units
>         CharSequenceCharAtBenchmark.testString ascii ?avgt ? ?3
>         ?1132.971 ?? 350.786 ?ns/op
>         CharSequenceCharAtBenchmark.testString non-ascii ?avgt ? ?3 ?
>         688.201 ?? 175.797 ?ns/op
>         CharSequenceCharAtBenchmark.testStringBuilder ?ascii ?avgt ?
>         ?3 ? 704.380 ?? 101.763 ?ns/op
>         CharSequenceCharAtBenchmark.testStringBuilder ?non-ascii ?avgt
>         ? ?3 ? 673.622 ?? ?51.462 ?ns/op
>
>
>         @Warmup(iterations = 2, time = 7, timeUnit = TimeUnit.SECONDS)
>         @BenchmarkMode(Mode.AverageTime)
>         @OutputTimeUnit(TimeUnit.NANOSECONDS)
>         @State(Scope.Benchmark)
>         @Fork(value = 1, jvmArgsPrepend = {"-Xms512M", "-Xmx512M"})
>         public class CharSequenceCharAtBenchmark {
>
>         ? ? @Param(value = {"ascii", "non-ascii"})
>         ? ? public String data;
>
>         ? ? private String string;
>
>         ? ? private StringBuilder stringBuilder;
>
>         ? ? @Setup(Level.Trial)
>         ? ? public void setup() throws Exception {
>         ? ? ? ? StringBuilder sb = new StringBuilder(3152);
>         ? ? ? ? for (int i=0; i<3152; ++i) {
>         ? ? ? ? ? ? char c = (char) i;
>         ? ? ? ? ? ? if ("ascii".equals(data)) {
>         ? ? ? ? ? ? ? ? c = (char) (i & 0x7f);
>         ? ? ? ? ? ? }
>         ? ? ? ? ? ? sb.append(c);
>         ? ? ? ? }
>
>         ? ? ? ? string = sb.toString();
>         ? ? ? ? stringBuilder = sb;
>         ? ? }
>
>         ? ? @Benchmark
>         ? ? public int testString() {
>         ? ? ? ? String sequence = this.string;
>         ? ? ? ? int sum = 0;
>         ? ? ? ? for (int i=0, j=sequence.length(); i<j; ++i) {
>         ? ? ? ? ? ? sum += sequence.charAt(i);
>         ? ? ? ? }
>         ? ? ? ? return sum;
>         ? ? }
>
>         ? ? @Benchmark
>         ? ? public int testStringBuilder() {
>         ? ? ? ? StringBuilder sequence = this.stringBuilder;
>         ? ? ? ? int sum = 0;
>         ? ? ? ? for (int i=0, j=sequence.length(); i<j; ++i) {
>         ? ? ? ? ? ? sum += sequence.charAt(i);
>         ? ? ? ? }
>         ? ? ? ? return sum;
>         ? ? }
>         }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250724/bface8fc/attachment-0001.htm>

From liach at openjdk.org  Thu Jul 24 17:51:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Jul 2025 17:51:58 GMT
Subject: [jdk25] RFR: 8315131: Clarify VarHandle set/get access on 32-bit
 platforms
In-Reply-To: <0uABTBFyAvVk-sD0us6ovyZS142Yu9ZBLvYSEduv5P4=.852da2c3-abe6-4d96-852f-d68c7349ea0d@github.com>
References: <0uABTBFyAvVk-sD0us6ovyZS142Yu9ZBLvYSEduv5P4=.852da2c3-abe6-4d96-852f-d68c7349ea0d@github.com>
Message-ID: <7BqedcC_NDzBijWSsFd-zsN2zXb7qMnjDRm-muhiqCU=.650b2be7-4329-43a5-a763-07756e8c5ed4@github.com>

On Wed, 23 Jul 2025 04:04:46 GMT, Chen Liang <liach at openjdk.org> wrote:

> JDK-8315131 addresses a doc-only mistake present on release 25. Since this is doc-only, this is eligible for backport, and its CSR is approved for release 25 too. See #26258 for the original PR review.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26438#issuecomment-3114330688

From liach at openjdk.org  Thu Jul 24 17:51:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Jul 2025 17:51:59 GMT
Subject: [jdk25] Integrated: 8315131: Clarify VarHandle set/get access on
 32-bit platforms
In-Reply-To: <0uABTBFyAvVk-sD0us6ovyZS142Yu9ZBLvYSEduv5P4=.852da2c3-abe6-4d96-852f-d68c7349ea0d@github.com>
References: <0uABTBFyAvVk-sD0us6ovyZS142Yu9ZBLvYSEduv5P4=.852da2c3-abe6-4d96-852f-d68c7349ea0d@github.com>
Message-ID: <BY6t7RwWIgFWibfq6MVcFW8sUoT0gzsZRU0HtIGV398=.f45f1927-9e2f-41e8-bb15-ebba704a7b7a@github.com>

On Wed, 23 Jul 2025 04:04:46 GMT, Chen Liang <liach at openjdk.org> wrote:

> JDK-8315131 addresses a doc-only mistake present on release 25. Since this is doc-only, this is eligible for backport, and its CSR is approved for release 25 too. See #26258 for the original PR review.

This pull request has now been integrated.

Changeset: 1867effc
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1867effcc0c4c0864168a7c1509a89a268a137dc
Stats:     8 lines in 2 files changed: 1 ins; 0 del; 7 mod

8315131: Clarify VarHandle set/get access on 32-bit platforms

Reviewed-by: rriggs, iris
Backport-of: ea6674fec8702eea481afa7ca7e522cbacd53841

-------------

PR: https://git.openjdk.org/jdk/pull/26438

From chen.l.liang at oracle.com  Thu Jul 24 18:01:31 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Thu, 24 Jul 2025 18:01:31 +0000
Subject: String.charAt vs StringBuilder.charAt performance
In-Reply-To: <0f88213a-33aa-4ce0-a907-26e14b9d00b5@civilian-framework.org>
References: <CANBJVOHxaDv5q3GJPX8dn2GepcU9de39phavquaxKNXGZrMRrA@mail.gmail.com>
 <CABe8uE0UJ_=Vb842cTTnE4tuGPWDMKDb0bkD9CCvqNKQfXF20Q@mail.gmail.com>
 <CANBJVOFUEEt1GdM59D27cXbEzG9ZZZaafPsJqt6uQ+gwjruVKw@mail.gmail.com>
 <fd0e5706-7c69-42e1-8b58-da5281569cda@oracle.com>
 <CANBJVOHbJxR9TCLW4OWuN2uMP4TN-ZKhJTvOwZeUvXYQOv0j6g@mail.gmail.com>
 <b443c697-c396-4bb4-8fb2-50304491dc58@oracle.com>
 <CANBJVOFNRcsSfAyT_AsS5Km=-uoA-rJLVJA1i4zrmJg4dEykPQ@mail.gmail.com>
 <SJ2PR10MB76699AD4DCB8423D0DCE9306A25DA@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOEhj97O-iNzEAq+pckhRD8FmzThetowJS9V_mFWpRGgOQ@mail.gmail.com>
 <CANBJVOHC0533A7JMhckoDJ1X2SJQDbS=cccCpTECaSmAQzc3xQ@mail.gmail.com>
 <0f88213a-33aa-4ce0-a907-26e14b9d00b5@civilian-framework.org>
Message-ID: <SJ2PR10MB76699A8929D99407E3D30024A25EA@SJ2PR10MB7669.namprd10.prod.outlook.com>

Thanks Johannes for another test case!

Hotspot compiler investigation concludes this is due to inlining limits; an issue https://bugs.openjdk.org/browse/JDK-8364043 has been created. The guess for now is that limits are reached on different platforms inconsistently.
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Johannes D?bler <jd at civilian-framework.org>
Sent: Thursday, July 24, 2025 12:33 PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: String.charAt vs StringBuilder.charAt performance

Hi Brett,

I ran your benchmark on a Windows11 Pro 24H2 / ARM64 / JDK 21 system  and can reproduce your findings that CharSequenceCharAtBenchmark.testString<ascii> has weaker performance.
I also added these benchmarks:
    @Benchmark
    public int testStringBuilderAsCS() {
        return test(this.stringBuilder);
    }

    @Benchmark
    public int testStringAsCS() {
        return test(this.string);
    }

    private int test(CharSequence sequence) {
        int sum = 0;
        for (int i=0, j=sequence.length(); i<j; ++i) {
            sum += sequence.charAt(i);
        }
        return sum;
    }

and see a total breakdown of  CharSequenceCharAtBenchmark.testStringAsCS

Benchmark                                             (data)  Mode  Cnt     Score     Error  Units
CharSequenceCharAtBenchmark.testString                 ascii  avgt    5  1647,439 ?  70,486  ns/op
CharSequenceCharAtBenchmark.testString             non-ascii  avgt    5   939,780 ?  63,896  ns/op
CharSequenceCharAtBenchmark.testStringAsCS             ascii  avgt    5  1657,796 ?  18,488  ns/op
CharSequenceCharAtBenchmark.testStringAsCS         non-ascii  avgt    5  9400,447 ? 290,066  ns/op
CharSequenceCharAtBenchmark.testStringBuilder          ascii  avgt    5   923,943 ?   6,130  ns/op
CharSequenceCharAtBenchmark.testStringBuilder      non-ascii  avgt    5   941,507 ?  30,786  ns/op
CharSequenceCharAtBenchmark.testStringBuilderAsCS      ascii  avgt    5   930,974 ?  33,187  ns/op
CharSequenceCharAtBenchmark.testStringBuilderAsCS  non-ascii  avgt    5   945,983 ?  87,636  ns/op

Best
Johannes

On 22/07/2025 13:44, Brett Okken wrote:
It does look like this is windows specific. If I run on WSL, I get results similar to your linux-x64:

Benchmark                                         (data)  Mode  Cnt    Score     Error  Units
CharSequenceCharAtBenchmark.testString             ascii  avgt    3  679.294 ? 302.947  ns/op
CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3  702.071 ? 926.959  ns/op
CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3  682.815 ? 301.649  ns/op
CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3  678.169 ? 810.276  ns/op

And I go back to the original version of the test, where String vs StringBuilder is defined by parameter and both assigned to same local variable as part of set up, that also shows no difference in wsl.
So it appears everything I observed is an artifact of Windows specific intrinsics?

Benchmark                            (data)       (source)  Mode  Cnt    Score     Error  Units
CharSequenceCharAtBenchmark.test      ascii         String  avgt    3  660.597 ? 146.405  ns/op
CharSequenceCharAtBenchmark.test      ascii  StringBuilder  avgt    3  659.395 ? 155.167  ns/op
CharSequenceCharAtBenchmark.test  non-ascii         String  avgt    3  647.955 ? 189.747  ns/op
CharSequenceCharAtBenchmark.test  non-ascii  StringBuilder  avgt    3  639.678 ? 146.923  ns/op

On Mon, Jul 21, 2025 at 5:13?PM Brett Okken <brett.okken.os at gmail.com<mailto:brett.okken.os at gmail.com>> wrote:
I am running Windows x64. Windows 11 Pro 24H2

Intel(R) Core(TM) i7-1370P

On Mon, Jul 21, 2025 at 4:59?PM Chen Liang <chen.l.liang at oracle.com<mailto:chen.l.liang at oracle.com>> wrote:
I finally came around and ran the benchmark on my linux-x64 device; however, I could not produce your results where String is significantly slower than StringBuilder.

This is the results I've got:

Benchmark                                         (data)  Mode  Cnt    Score    Error  Units
CharSequenceCharAtBenchmark.testString             ascii  avgt    5  668.649 ? 13.895  ns/op
CharSequenceCharAtBenchmark.testString         non-ascii  avgt    5  651.903 ?  7.240  ns/op
CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    5  673.802 ? 26.260  ns/op
CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    5  657.374 ? 35.785  ns/op

I think we might have more clue - are you testing on a macosx-aarch64 machine or some other platform? It might be that on some platforms, there are some problems in the hand-written assemblies for the intrinsics which contribute to this slowdown, instead of a problem with the C2 IR.

Chen
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Brett Okken <brett.okken.os at gmail.com<mailto:brett.okken.os at gmail.com>>
Sent: Monday, July 21, 2025 4:01 PM
To: Roger Riggs <roger.riggs at oracle.com<mailto:roger.riggs 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: String.charAt vs StringBuilder.charAt performance

Updating to have different test methods for each representation did remove the difference for the non-ascii String case for the jdk 21+ releases.
However, the ascii (latin) strings are still slower with String than StringBuilder.

How does C2 then handle something like StringCharBuffer wrapping a CharSequence for all of it's get operations:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/StringCharBuffer.java#L88-L97

Which is then used by CharBufferSpliterator
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/CharBufferSpliterator.java

And by many CharsetEncoder impls when either source or destination is not backed by array (which would be the case if StringCharBuffer used):
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/cs/UTF_8.java#L517
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/cs/UnicodeEncoder.java#L81



jdk 17
Benchmark                                         (data)  Mode  Cnt     Score     Error  Units
CharSequenceCharAtBenchmark.testString             ascii  avgt    3  1429.358 ? 623.424  ns/op
CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3   705.282 ? 233.453  ns/op
CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3   724.138 ? 267.346  ns/op
CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3   718.357 ? 864.066  ns/op

jdk 21
Benchmark                                         (data)  Mode  Cnt     Score     Error  Units
CharSequenceCharAtBenchmark.testString             ascii  avgt    3  1087.024 ?? 235.082  ns/op
CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3   687.520 ?? 747.532  ns/op
CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3   672.802 ??  29.740  ns/op
CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3   689.964 ?? 791.175  ns/op

jdk 25
Benchmark                                         (data)  Mode  Cnt     Score      Error  Units
CharSequenceCharAtBenchmark.testString             ascii  avgt    3  1176.057 ?? 1157.979  ns/op
CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3   697.382 ??  231.144  ns/op
CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3   692.970 ??  105.112  ns/op
CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3   703.178 ??  446.019  ns/op

jdk 26
Benchmark                                         (data)  Mode  Cnt     Score     Error  Units
CharSequenceCharAtBenchmark.testString             ascii  avgt    3  1132.971 ?? 350.786  ns/op
CharSequenceCharAtBenchmark.testString         non-ascii  avgt    3   688.201 ?? 175.797  ns/op
CharSequenceCharAtBenchmark.testStringBuilder      ascii  avgt    3   704.380 ?? 101.763  ns/op
CharSequenceCharAtBenchmark.testStringBuilder  non-ascii  avgt    3   673.622 ??  51.462  ns/op


@Warmup(iterations = 2, time = 7, timeUnit = TimeUnit.SECONDS)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
@Fork(value = 1, jvmArgsPrepend = {"-Xms512M", "-Xmx512M"})
public class CharSequenceCharAtBenchmark {

    @Param(value = {"ascii", "non-ascii"})
    public String data;

    private String string;

    private StringBuilder stringBuilder;

    @Setup(Level.Trial)
    public void setup() throws Exception {
        StringBuilder sb = new StringBuilder(3152);
        for (int i=0; i<3152; ++i) {
            char c = (char) i;
            if ("ascii".equals(data)) {
                c = (char) (i & 0x7f);
            }
            sb.append(c);
        }

        string = sb.toString();
        stringBuilder = sb;
    }

    @Benchmark
    public int testString() {
        String sequence = this.string;
        int sum = 0;
        for (int i=0, j=sequence.length(); i<j; ++i) {
            sum += sequence.charAt(i);
        }
        return sum;
    }

    @Benchmark
    public int testStringBuilder() {
        StringBuilder sequence = this.stringBuilder;
        int sum = 0;
        for (int i=0, j=sequence.length(); i<j; ++i) {
            sum += sequence.charAt(i);
        }
        return sum;
    }
}


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250724/42d9fc04/attachment-0001.htm>

From liach at openjdk.org  Thu Jul 24 18:44:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Jul 2025 18:44:18 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v12]
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: <KBhs1l5ktSApeck6WAzETQZXBwKEGOl6OfxOVgmadzg=.32c6bb61-6835-4be5-9360-cb77f75aea6c@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 26 commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno
 - Restore non-public comments
 - 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
 - ... and 16 more: https://git.openjdk.org/jdk/compare/84776309...7cb07340

-------------

Changes: https://git.openjdk.org/jdk/pull/25922/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=11
  Stats: 453 lines in 38 files changed: 286 ins; 150 del; 17 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 rriggs at openjdk.org  Thu Jul 24 18:49:57 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Jul 2025 18:49:57 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v8]
In-Reply-To: <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
Message-ID: <fIoFUw3fUQIszOe50MXkIeTvOsmAy5xUj3UbHcfPkhw=.9482ef6b-c918-41e1-976d-1a028ec2f074@github.com>

On Fri, 27 Jun 2025 01:04:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string.
>> 
>> For these scenarios, we can Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed.
>> 
>> @RogerRiggs completed the optimization when the encoder is LATIN1 in PR #24967. This PR continues to complete the optimization when the encoder is UTF16.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/StringUTF16.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24773#pullrequestreview-3052828743

From djelinski at openjdk.org  Thu Jul 24 19:37:16 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 24 Jul 2025 19:37:16 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
Message-ID: <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>

On Tue, 8 Jul 2025 14:04:56 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 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

test/jdk/java/net/httpclient/http3/H3StreamLimitReachedTest.java line 94:

> 92: import static org.testng.Assert.assertFalse;
> 93: 
> 94: public class H3StreamLimitReachedTest implements HttpServerAdapters {

This test seems to duplicate the checks in `StreamLimitTest`.

test/jdk/java/net/httpclient/http3/H3UnsupportedSSLParametersTest.java line 42:

> 40:  * @run junit H3UnsupportedSSLParametersTest
> 41:  */
> 42: public class H3UnsupportedSSLParametersTest {

This test overlaps with H3QuicTLSConnection. Any reason we shouldn't merge them?

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/ThrowingConsumer.java line 26:

> 24: 
> 25: @FunctionalInterface
> 26: public interface ThrowingConsumer<T, X extends Throwable> {

This interface is only implemented by Http2Handler. We should remove it.

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2RedirectHandler.java line 61:

> 59:     }
> 60: 
> 61:     protected byte[] getResponseBytes() {

this method doesn't appear to be overridden anywhere. Should we revert these changes?

test/jdk/jdk/internal/net/http/quic/packets/QuicPacketNumbersTest.java line 33:

> 31:  * @modules java.net.http/jdk.internal.net.http.quic.packets
> 32:  */
> 33: public class QuicPacketNumbersTest {

This test covers the same functions as `quic/PacketNumbersTest.java`; can we remove one?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2228940118
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2228863718
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2229069373
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2229083738
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2229397818

From myankelevich at openjdk.org  Thu Jul 24 21:53:54 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 24 Jul 2025 21:53:54 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc.
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <FkuVToJew8Yt-S4GV3S5hFEM2omQnXtS4a3LoACWRpk=.2f0c76b2-d634-40fc-b241-f97d274cf7d9@github.com>

On Thu, 24 Jul 2025 14:50:07 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

Could you please add a bug number under `@bug`?

test/jdk/java/lang/StringBuilder/Supplementary.java line 216:

> 214:         testAppendCodePoint(Character.MAX_CODE_POINT+1, IllegalArgumentException.class);
> 215:     }
> 216: 

nit, as the other copyrights are updated: 

* Copyright (c) 2003, 2025, Oracle and/or its affiliates. All rights reserved.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26461#pullrequestreview-3053452383
PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2229652045

From myankelevich at openjdk.org  Thu Jul 24 22:09:56 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 24 Jul 2025 22:09:56 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc.
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <196EiVbN3eRqsKa6dSY6qlQuGcncN9gSihR5hTNuMVw=.ca7a4101-28b2-418f-870a-1cb25d00c0a0@github.com>

On Thu, 24 Jul 2025 14:50:07 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

src/java.base/share/classes/java/lang/Character.java line 9969:

> 9967:         int n = length;
> 9968:         for (int i = 0; i < length; ) {
> 9969:             if (isHighSurrogate(seq.charAt(i++)) && i < length &&

Imo this is quite hard to read, especially with `i++` inside of the if statement. What do you think about changing it to this? 
```java 
for (int i = 0; i < length; i++) {
    if (isHighSurrogate(seq.charAt(i)) && 
         i+1 < length && 
         isLowSurrogate(seq.charAt(i+1))) {

         n--;
         i++;
    }
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2229676944

From achung at openjdk.org  Fri Jul 25 00:29:13 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 25 Jul 2025 00:29:13 GMT
Subject: RFR: 8364089: JDK 25 RDP2 L10n resource files update
Message-ID: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>

This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

-------------

Commit messages:
 - update l10n

Changes: https://git.openjdk.org/jdk/pull/26467/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26467&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364089
  Stats: 90 lines in 14 files changed: 71 ins; 9 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/26467.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26467/head:pull/26467

PR: https://git.openjdk.org/jdk/pull/26467

From vyazici at openjdk.org  Fri Jul 25 07:40:46 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 25 Jul 2025 07:40:46 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v13]
In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
Message-ID: <t16yfpAYjX9Wm_qw-kEX4IGPsvv9KRyMudtRbGK7UZY=.30a8ab28-15b0-45f6-a0aa-aba54e387106@github.com>

> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input.
> 
> ## Implementation notes
> 
> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
> 
> 1. Move `@IntrinsicCandidate`-annotated `public` 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");
>         }
>     }
> }
> ...

Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 31 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
 - Replace `requireNonNull` with implicit null checks to reduce bytecode size
 - Add `@bug` tags
 - Improve wording of `@param len`
 - Make source array bound checks lenient too
 - Cap destination array bounds
 - Fix bit shifting
 - Remove superseded `@throws` Javadoc
 - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
 - Make `StringCoding` encoding intrinsics lenient
 - ... and 21 more: https://git.openjdk.org/jdk/compare/9331736c...c322f0e0

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25998/files
  - new: https://git.openjdk.org/jdk/pull/25998/files/1d02189f..c322f0e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=11-12

  Stats: 11682 lines in 267 files changed: 4951 ins; 5263 del; 1468 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 alanb at openjdk.org  Fri Jul 25 08:14:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Jul 2025 08:14:59 GMT
Subject: Integrated: 8362882: Update SubmissionPublisher() specification to
 reflect use of ForkJoinPool.asyncCommonPool()
In-Reply-To: <jqlYivNsVPTONrGSgVmeH0CeXH2JCs2nUWPJ99C13xs=.205b8340-72a8-4e8b-9248-b2470f3d81c5@github.com>
References: <jqlYivNsVPTONrGSgVmeH0CeXH2JCs2nUWPJ99C13xs=.205b8340-72a8-4e8b-9248-b2470f3d81c5@github.com>
Message-ID: <teCQsWwutoKQQgZPRHRJ0eyRQRihcjIWtYZdaPjEmAM=.f644e388-c8b2-4780-b6ea-9bb526360284@github.com>

On Tue, 22 Jul 2025 13:13:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The changes in JDK-8319447 to improve the performance of delayed task handling updated CompletableFuture and SubmissionPublisher to use the ForkJoinPool commonPool in all cases. These APIs previously created a Thread for each task when parallelism was less than 2. We missed the update to SubmissionPublisher's no-arg constructor in that update.

This pull request has now been integrated.

Changeset: f79bd54b
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f79bd54bbb9f5748e437346d34702608f7b67019
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8362882: Update SubmissionPublisher() specification to reflect use of ForkJoinPool.asyncCommonPool()

Reviewed-by: jpai, dl

-------------

PR: https://git.openjdk.org/jdk/pull/26426

From alanb at openjdk.org  Fri Jul 25 09:56:06 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Jul 2025 09:56:06 GMT
Subject: [jdk25] RFR: 8362882: Update SubmissionPublisher() specification to
 reflect use of ForkJoinPool.asyncCommonPool()
Message-ID: <pQshE-_kRSCoEcfZ8CVg6g6XcDYORozB2VuVorAbdEc=.ee0723b5-717e-420c-8833-8734d677f284@github.com>

Backport of docs only change. The CSR is already approved for JDK 25.

-------------

Commit messages:
 - Backport f79bd54bbb9f5748e437346d34702608f7b67019

Changes: https://git.openjdk.org/jdk/pull/26474/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26474&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362882
  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26474.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26474/head:pull/26474

PR: https://git.openjdk.org/jdk/pull/26474

From jpai at openjdk.org  Fri Jul 25 10:00:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Jul 2025 10:00:55 GMT
Subject: [jdk25] RFR: 8362882: Update SubmissionPublisher() specification
 to reflect use of ForkJoinPool.asyncCommonPool()
In-Reply-To: <pQshE-_kRSCoEcfZ8CVg6g6XcDYORozB2VuVorAbdEc=.ee0723b5-717e-420c-8833-8734d677f284@github.com>
References: <pQshE-_kRSCoEcfZ8CVg6g6XcDYORozB2VuVorAbdEc=.ee0723b5-717e-420c-8833-8734d677f284@github.com>
Message-ID: <M1p5fZ55wmIiN4D-NiKMUub1b1vkQThmUtFQ0Wg3_4g=.d0e092d1-818b-41c3-881e-044e72e6b218@github.com>

On Fri, 25 Jul 2025 08:20:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Backport of docs only change. The CSR is already approved for JDK 25.

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26474#pullrequestreview-3054833211

From alanb at openjdk.org  Fri Jul 25 11:25:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Jul 2025 11:25:00 GMT
Subject: [jdk25] Integrated: 8362882: Update SubmissionPublisher()
 specification to reflect use of ForkJoinPool.asyncCommonPool()
In-Reply-To: <pQshE-_kRSCoEcfZ8CVg6g6XcDYORozB2VuVorAbdEc=.ee0723b5-717e-420c-8833-8734d677f284@github.com>
References: <pQshE-_kRSCoEcfZ8CVg6g6XcDYORozB2VuVorAbdEc=.ee0723b5-717e-420c-8833-8734d677f284@github.com>
Message-ID: <eRUrWunnqMwF7l-LT3Ce6G8-c8mhWIAFrSpV4zYZmco=.11c3b672-f951-403a-ab1b-0fdf6f829b47@github.com>

On Fri, 25 Jul 2025 08:20:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Backport of docs only change. The CSR is already approved for JDK 25.

This pull request has now been integrated.

Changeset: 3db82624
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3db8262445070440e0ac45f523813fd6ce983cc4
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8362882: Update SubmissionPublisher() specification to reflect use of ForkJoinPool.asyncCommonPool()

Reviewed-by: jpai
Backport-of: f79bd54bbb9f5748e437346d34702608f7b67019

-------------

PR: https://git.openjdk.org/jdk/pull/26474

From michaelm at openjdk.org  Fri Jul 25 12:15:05 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 25 Jul 2025 12:15:05 GMT
Subject: RFR: 8362581: Timeouts in
 java/nio/channels/SocketChannel/OpenLeak.java on UNIX
Message-ID: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>

Hi,

This is a fix for 8362581 caused by the implementation for https://bugs.openjdk.org/browse/JDK-8348986
An incorrect check was added to the method Exceptions.ioException() which wasn't noticed partly
because that file was renamed, and webrev doesn't show the diffs side by side.
The effect of this change is to restore the method to pretty much what it was before, but taking account
of the changed categorisation of exceptions.

A test is not included since this was caught by an existing regression test.

Thanks,
Michael

-------------

Commit messages:
 - add test bugid
 - impl update

Changes: https://git.openjdk.org/jdk/pull/26478/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26478&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362581
  Stats: 6 lines in 2 files changed: 0 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26478/head:pull/26478

PR: https://git.openjdk.org/jdk/pull/26478

From djelinski at openjdk.org  Fri Jul 25 12:46:53 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 25 Jul 2025 12:46:53 GMT
Subject: RFR: 8362581: Timeouts in
 java/nio/channels/SocketChannel/OpenLeak.java on UNIX
In-Reply-To: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
References: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
Message-ID: <iXowkpHLNw_IZg-GjAasRE7E0etYN_uMJDvJ1RqPyQI=.5f6a5541-2e48-4cab-bd89-3cd7cafa78ef@github.com>

On Fri, 25 Jul 2025 12:08:38 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This is a fix for 8362581 caused by the implementation for https://bugs.openjdk.org/browse/JDK-8348986
> An incorrect check was added to the method Exceptions.ioException() which wasn't noticed partly
> because that file was renamed, and webrev doesn't show the diffs side by side.
> The effect of this change is to restore the method to pretty much what it was before, but taking account
> of the changed categorisation of exceptions.
> 
> A test is not included since this was caught by an existing regression test.
> 
> Thanks,
> Michael

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26478#pullrequestreview-3055263287

From dl at openjdk.org  Fri Jul 25 13:12:25 2025
From: dl at openjdk.org (Doug Lea)
Date: Fri, 25 Jul 2025 13:12:25 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads with
 almost empty tasks
Message-ID: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>

This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.

-------------

Commit messages:
 - Whitespace
 - Merge branch 'openjdk:master' into JDK-8360046
 - Avoid unnecessary use of InterruptibleTask; misc cleanup
 - revert runWorker; tweak external probes
 - reduce contention
 - Merge branch 'openjdk:master' into JDK-8360046
 - For testing
 - Reduce branchiness of Exchanger

Changes: https://git.openjdk.org/jdk/pull/26479/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360046
  Stats: 142 lines in 3 files changed: 31 ins; 28 del; 83 mod
  Patch: https://git.openjdk.org/jdk/pull/26479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479

PR: https://git.openjdk.org/jdk/pull/26479

From jbhateja at openjdk.org  Fri Jul 25 13:50:55 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Jul 2025 13:50:55 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction
Message-ID: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>

Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction.
It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails.

 Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java).

Vector API jtreg tests pass at AVX level 2, remaining validation in progress.

Performance numbers:


System : 13th Gen Intel(R) Core(TM) i3-1315U

Baseline:
Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2   9444.444          ops/ms
VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  10009.319          ops/ms
VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9081.926          ops/ms
VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2   6085.825          ops/ms
VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2   6505.378          ops/ms
VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6204.489          ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2   1651.334          ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   1642.784          ops/ms
VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1474.808          ops/ms
VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  10399.394          ops/ms
VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  10502.894          ops/ms
VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024  thrpt    2   9756.573          ops/ms

With opt:
Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2  34122.435          ops/ms
VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  33281.868          ops/ms
VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9345.154          ops/ms
VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2   8283.247          ops/ms
VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2   8510.695          ops/ms
VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   5626.367          ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2    960.958          ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   4155.801          ops/ms
VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1465.953          ops/ms
VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  32748.061          ops/ms
VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  33674.408          ops/ms
VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024  thrpt    2   9346.148          ops/ms


Please share your feedback.

Best Regards,
Jatin

-------------

Commit messages:
 - Fixes for failing regressions
 -  Optimizing AVX2 backend and some re-factoring
 - new benchmark
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8303762
 - 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction

Changes: https://git.openjdk.org/jdk/pull/24104/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303762
  Stats: 747 lines in 32 files changed: 664 ins; 0 del; 83 mod
  Patch: https://git.openjdk.org/jdk/pull/24104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104

PR: https://git.openjdk.org/jdk/pull/24104

From jbhateja at openjdk.org  Fri Jul 25 13:50:56 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Jul 2025 13:50:56 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction
In-Reply-To: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
Message-ID: <rxrqifXZWTu2RgnGV-1QjP1eenihYP5YAMcu48k6NyQ=.22a486b9-a4de-43df-9b01-f6ef81301d64@github.com>

On Tue, 18 Mar 2025 20:51:46 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction.
> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails.
> 
>  Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java).
> 
> Vector API jtreg tests pass at AVX level 2, remaining validation in progress.
> 
> Performance numbers:
> 
> 
> System : 13th Gen Intel(R) Core(TM) i3-1315U
> 
> Baseline:
> Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2   9444.444          ops/ms
> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  10009.319          ops/ms
> VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9081.926          ops/ms
> VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2   6085.825          ops/ms
> VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2   6505.378          ops/ms
> VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6204.489          ops/ms
> VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2   1651.334          ops/ms
> VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   1642.784          ops/ms
> VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1474.808          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  10399.394          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  10502.894          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024 ...

Performance after AVX2 backend modifications


Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2  51644.530          ops/ms
VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  48171.079          ops/ms
VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9662.306          ops/ms
VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2  14358.347          ops/ms
VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2  14619.920          ops/ms
VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6675.824          ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2    818.911          ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   4778.321          ops/ms
VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1612.264          ops/ms
VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  35961.146          ops/ms
VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  39072.170          ops/ms
VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024  thrpt    2  11209.685          ops/ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3116214722

From duke at openjdk.org  Fri Jul 25 15:16:59 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 25 Jul 2025 15:16:59 GMT
Subject: RFR: 8077587: BigInteger Roots [v45]
In-Reply-To: <aTIf0PDMB0Lf_LLiWemJOGnmi8WFTP4U7QTj2a7ooc8=.b7bc7b3d-17f1-4c79-84ba-54956f25467f@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <I7aYp0FRNnbjVqayzg3HCOhx05ZMnJXih61G0tZHluI=.0cb682ba-bf40-4729-807e-100ce83b5753@github.com>
 <aTIf0PDMB0Lf_LLiWemJOGnmi8WFTP4U7QTj2a7ooc8=.b7bc7b3d-17f1-4c79-84ba-54956f25467f@github.com>
Message-ID: <6S90pN28akSc0KyrcgmwLgN5i9T_fU4UIp-BHmPfFoc=.b657636c-3e7b-4370-a90c-23a81153902c@github.com>

On Fri, 25 Jul 2025 14:56:09 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Round up to do less iterations
>>   
>>   With the 1st iteration outside the loop, it is more convenient rounding up to ceiling.
>
> src/java.base/share/classes/java/math/MutableBigInteger.java line 1929:
> 
>> 1927:      * @return the integer {@code n}th root of {@code this} and the remainder
>> 1928:      */
>> 1929:     MutableBigInteger[] nthRootRem(final int n) {
> 
> We rarely use `final` on a parameter.

In this case, `final` serves to indicate that the value of `n` is never modified by the method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2231390118

From tom_L64 at hotmail.com  Fri Jul 25 15:19:04 2025
From: tom_L64 at hotmail.com (tom L)
Date: Fri, 25 Jul 2025 15:19:04 +0000
Subject: JavaFX TextInputControl private access yet supposed to be overrided
 problem
Message-ID: <PAXP251MB06716288867F1DCDF8FB5AEA8859A@PAXP251MB0671.EURP251.PROD.OUTLOOK.COM>

Hello.
I have this problem where a lot of methods and utility in TextInputControl have package private access while at the same time are expected to be used/overriden by children.
For example,
```
    String filterInput(String text) {
        // This method should be overridden by child classes.
        // It is overridden in TextField and TextArea as needed.
        return text;
    }
```
This method is clearly supposed to be overriden, and I am making a hex editor, requiring me to create my own text field, but I can't override it.
It is the same for other methods, also including utility methods, like for example, with the same name :
```
    static String filterInput(String txt, boolean stripNewlines, boolean stripTabs)
```
In order to do what I want, I am no choice but to copy paste half the code of this class, since even if I override the only method that uses filterInput, public void replaceText, there are a lot of package private stuff inside (mainly getFormatterAccessor), so I am ended up with trying to copy paste the whole class.

On another note, since I am talking about formatter accessor, this inner class in TextInputControl has a typos in it: TextInputControlFromatterAccessor.

Is it possible to fix this?
Thank you in advance.


Best regards,

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250725/9014ba47/attachment-0001.htm>

From duke at openjdk.org  Fri Jul 25 15:20:58 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 25 Jul 2025 15:20:58 GMT
Subject: RFR: 8077587: BigInteger Roots [v45]
In-Reply-To: <aTIf0PDMB0Lf_LLiWemJOGnmi8WFTP4U7QTj2a7ooc8=.b7bc7b3d-17f1-4c79-84ba-54956f25467f@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <I7aYp0FRNnbjVqayzg3HCOhx05ZMnJXih61G0tZHluI=.0cb682ba-bf40-4729-807e-100ce83b5753@github.com>
 <aTIf0PDMB0Lf_LLiWemJOGnmi8WFTP4U7QTj2a7ooc8=.b7bc7b3d-17f1-4c79-84ba-54956f25467f@github.com>
Message-ID: <5leWD-u1Xmk5MuOz2QQOI1E-Sw1psi35OuPKvGmQbQ4=.a751cdc3-f7ac-4b0f-8e7c-5e86dc5d03f8@github.com>

On Fri, 25 Jul 2025 14:56:47 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Round up to do less iterations
>>   
>>   With the 1st iteration outside the loop, it is more convenient rounding up to ceiling.
>
> src/java.base/share/classes/java/math/MutableBigInteger.java line 1934:
> 
>> 1932:             return new MutableBigInteger[] { this, new MutableBigInteger() };
>> 1933: 
>> 1934:         final int bitLength = (int) this.bitLength();
> 
> The method does not state that it is assuming that `bitLength()` fits in an `int`.

Indeed, I did not stated it because I was not sure if it were better to assume that `bitLength()` fits in an `int`, or to throw an `ArithmeticException` instead if it doesn't...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2231398839

From rgiulietti at openjdk.org  Fri Jul 25 15:28:58 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 25 Jul 2025 15:28:58 GMT
Subject: RFR: 8077587: BigInteger Roots [v45]
In-Reply-To: <6S90pN28akSc0KyrcgmwLgN5i9T_fU4UIp-BHmPfFoc=.b657636c-3e7b-4370-a90c-23a81153902c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <I7aYp0FRNnbjVqayzg3HCOhx05ZMnJXih61G0tZHluI=.0cb682ba-bf40-4729-807e-100ce83b5753@github.com>
 <aTIf0PDMB0Lf_LLiWemJOGnmi8WFTP4U7QTj2a7ooc8=.b7bc7b3d-17f1-4c79-84ba-54956f25467f@github.com>
 <6S90pN28akSc0KyrcgmwLgN5i9T_fU4UIp-BHmPfFoc=.b657636c-3e7b-4370-a90c-23a81153902c@github.com>
Message-ID: <VJxP1ZTAHc1aGUBra8aTMvoH8sdktNs9wrGjaWrk-wI=.c76d7c72-3f26-4148-b9c8-0246c51f01c8@github.com>

On Fri, 25 Jul 2025 15:14:42 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1929:
>> 
>>> 1927:      * @return the integer {@code n}th root of {@code this} and the remainder
>>> 1928:      */
>>> 1929:     MutableBigInteger[] nthRootRem(final int n) {
>> 
>> We rarely use `final` on a parameter.
>
> In this case, `final` serves to indicate that the value of `n` is never modified by the method.

Of course.
To the caller, a `final` parameter does not convey any information, and makes the method/constructor header less concise.
There are thousands of methods in the JDK that do no alter their parameters, and yet these are not annotated with `final`.
It's just a matter of convention.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2231413900

From duke at openjdk.org  Fri Jul 25 15:29:00 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 25 Jul 2025 15:29:00 GMT
Subject: RFR: 8077587: BigInteger Roots [v45]
In-Reply-To: <aTIf0PDMB0Lf_LLiWemJOGnmi8WFTP4U7QTj2a7ooc8=.b7bc7b3d-17f1-4c79-84ba-54956f25467f@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <I7aYp0FRNnbjVqayzg3HCOhx05ZMnJXih61G0tZHluI=.0cb682ba-bf40-4729-807e-100ce83b5753@github.com>
 <aTIf0PDMB0Lf_LLiWemJOGnmi8WFTP4U7QTj2a7ooc8=.b7bc7b3d-17f1-4c79-84ba-54956f25467f@github.com>
Message-ID: <88nHpGfj1GK63cG2-Rd2DyxkWER9n8FqCZczsshKtco=.1f14fb0c-37cf-4fe6-af84-9f703ffb23bf@github.com>

On Fri, 25 Jul 2025 14:57:10 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Round up to do less iterations
>>   
>>   With the 1st iteration outside the loop, it is more convenient rounding up to ceiling.
>
> src/java.base/share/classes/java/math/MutableBigInteger.java line 1967:
> 
>> 1965:                     sToN1 = BigInteger.unsignedLongPow(sLong, n - 1);
>> 1966:                     u = ((n - 1) * sLong + Long.divideUnsigned(x, sToN1)) / n;
>> 1967:                 } while (u < sLong); // Terminate when non-decreasing.
> 
> I'm not sure this is 100% correct.
> Since one "iteration" is done before even entering the loop, I think the loop condition should go to the beginning.
> As it is now, there are always two evaluations of the Newton recurrence formula.

No, the loop condition should not go to the beginning, because the 1st iteration is not related with the loop, but it serves to satisfy the precondition that guarantees the termination of the loop. Indeed, the loop condition can't be evaluated after the first iteration, because `u` is not defined yet. If it were, doing the 1st iteration in the loop would make no difference, but the loop could stop with a wrong value of `s`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2231416103

From duke at openjdk.org  Fri Jul 25 15:28:58 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 25 Jul 2025 15:28:58 GMT
Subject: RFR: 8077587: BigInteger Roots [v45]
In-Reply-To: <VJxP1ZTAHc1aGUBra8aTMvoH8sdktNs9wrGjaWrk-wI=.c76d7c72-3f26-4148-b9c8-0246c51f01c8@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <I7aYp0FRNnbjVqayzg3HCOhx05ZMnJXih61G0tZHluI=.0cb682ba-bf40-4729-807e-100ce83b5753@github.com>
 <aTIf0PDMB0Lf_LLiWemJOGnmi8WFTP4U7QTj2a7ooc8=.b7bc7b3d-17f1-4c79-84ba-54956f25467f@github.com>
 <6S90pN28akSc0KyrcgmwLgN5i9T_fU4UIp-BHmPfFoc=.b657636c-3e7b-4370-a90c-23a81153902c@github.com>
 <VJxP1ZTAHc1aGUBra8aTMvoH8sdktNs9wrGjaWrk-wI=.c76d7c72-3f26-4148-b9c8-0246c51f01c8@github.com>
Message-ID: <eHEiWeCle4tEW43spWoQgmwCzTEJIlqe3reX56lBpXY=.b6f4108f-9fb7-4e65-8ffa-5402b76aefb0@github.com>

On Fri, 25 Jul 2025 15:23:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> In this case, `final` serves to indicate that the value of `n` is never modified by the method.
>
> Of course.
> To the caller, a `final` parameter does not convey any information, and makes the method/constructor header less concise.
> There are thousands of methods in the JDK that do no alter their parameters, and yet these are not annotated with `final`.
> It's just a matter of convention.

Yes, but in this way you see at a glance that the parameter is a constant, and you do not have to check all the method's code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2231422159

From duke at openjdk.org  Fri Jul 25 15:35:57 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 25 Jul 2025 15:35:57 GMT
Subject: RFR: 8077587: BigInteger Roots [v45]
In-Reply-To: <88nHpGfj1GK63cG2-Rd2DyxkWER9n8FqCZczsshKtco=.1f14fb0c-37cf-4fe6-af84-9f703ffb23bf@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <I7aYp0FRNnbjVqayzg3HCOhx05ZMnJXih61G0tZHluI=.0cb682ba-bf40-4729-807e-100ce83b5753@github.com>
 <aTIf0PDMB0Lf_LLiWemJOGnmi8WFTP4U7QTj2a7ooc8=.b7bc7b3d-17f1-4c79-84ba-54956f25467f@github.com>
 <88nHpGfj1GK63cG2-Rd2DyxkWER9n8FqCZczsshKtco=.1f14fb0c-37cf-4fe6-af84-9f703ffb23bf@github.com>
Message-ID: <yekVxDsFjvw45zNW5v4VnYMhwNxpJT7gSQhXAcge3WY=.34c2abca-0784-487a-8cc5-632653d5caa3@github.com>

On Fri, 25 Jul 2025 15:24:22 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1967:
>> 
>>> 1965:                     sToN1 = BigInteger.unsignedLongPow(sLong, n - 1);
>>> 1966:                     u = ((n - 1) * sLong + Long.divideUnsigned(x, sToN1)) / n;
>>> 1967:                 } while (u < sLong); // Terminate when non-decreasing.
>> 
>> I'm not sure this is 100% correct.
>> Since one "iteration" is done before even entering the loop, I think the loop condition should go to the beginning.
>> As it is now, there are always two evaluations of the Newton recurrence formula.
>
> No, the loop condition should not go to the beginning, because the 1st iteration is not related with the loop, but it serves to satisfy the precondition that guarantees the correctness after the termination of the loop. Indeed, the loop condition can't be evaluated after the first iteration, because `u` is not defined yet. If it were, doing the 1st iteration in the loop would make no difference, but the loop could stop with a wrong value of `s`.

> As it is now, there are always two evaluations of the Newton recurrence formula.

In other words, two evaluations of the Newton recurrence are always needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2231438424

From rgiulietti at openjdk.org  Fri Jul 25 15:39:56 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 25 Jul 2025 15:39:56 GMT
Subject: RFR: 8077587: BigInteger Roots [v45]
In-Reply-To: <eHEiWeCle4tEW43spWoQgmwCzTEJIlqe3reX56lBpXY=.b6f4108f-9fb7-4e65-8ffa-5402b76aefb0@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <I7aYp0FRNnbjVqayzg3HCOhx05ZMnJXih61G0tZHluI=.0cb682ba-bf40-4729-807e-100ce83b5753@github.com>
 <aTIf0PDMB0Lf_LLiWemJOGnmi8WFTP4U7QTj2a7ooc8=.b7bc7b3d-17f1-4c79-84ba-54956f25467f@github.com>
 <6S90pN28akSc0KyrcgmwLgN5i9T_fU4UIp-BHmPfFoc=.b657636c-3e7b-4370-a90c-23a81153902c@github.com>
 <VJxP1ZTAHc1aGUBra8aTMvoH8sdktNs9wrGjaWrk-wI=.c76d7c72-3f26-4148-b9c8-0246c51f01c8@github.com>
 <eHEiWeCle4tEW43spWoQgmwCzTEJIlqe3reX56lBpXY=.b6f4108f-9fb7-4e65-8ffa-5402b76aefb0@github.com>
Message-ID: <7Wr42-KRyYBsjDrMWbx7uyUTSRorngS8y9-NZismtng=.fd56fd8b-ba7e-4e8b-97cc-c250acc7ecdc@github.com>

On Fri, 25 Jul 2025 15:26:37 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Of course.
>> To the caller, a `final` parameter does not convey any information, and makes the method/constructor header less concise.
>> There are thousands of methods in the JDK that do no alter their parameters, and yet these are not annotated with `final`.
>> It's just a matter of convention.
>
> Yes, but in this way you see at a glance that the parameter is a constant, and you do not have to check all the method's code.

I guess most developer use a Java IDE for Java development.
My IDE shows variables that are altered by underlying their name at every occurrence in the code. I can see at a glance that `n` is not modified even without `final`.
As said, it's a matter of convention. In the OpenJDK we usually don't use `final` on parameters, as it clutters the header. Just have a look at a random place in the codebase.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2231448074

From rgiulietti at openjdk.org  Fri Jul 25 15:39:56 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 25 Jul 2025 15:39:56 GMT
Subject: RFR: 8077587: BigInteger Roots [v45]
In-Reply-To: <7Wr42-KRyYBsjDrMWbx7uyUTSRorngS8y9-NZismtng=.fd56fd8b-ba7e-4e8b-97cc-c250acc7ecdc@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <I7aYp0FRNnbjVqayzg3HCOhx05ZMnJXih61G0tZHluI=.0cb682ba-bf40-4729-807e-100ce83b5753@github.com>
 <aTIf0PDMB0Lf_LLiWemJOGnmi8WFTP4U7QTj2a7ooc8=.b7bc7b3d-17f1-4c79-84ba-54956f25467f@github.com>
 <6S90pN28akSc0KyrcgmwLgN5i9T_fU4UIp-BHmPfFoc=.b657636c-3e7b-4370-a90c-23a81153902c@github.com>
 <VJxP1ZTAHc1aGUBra8aTMvoH8sdktNs9wrGjaWrk-wI=.c76d7c72-3f26-4148-b9c8-0246c51f01c8@github.com>
 <eHEiWeCle4tEW43spWoQgmwCzTEJIlqe3reX56lBpXY=.b6f4108f-9fb7-4e65-8ffa-5402b76aefb0@github.com>
 <7Wr42-KRyYBsjDrMWbx7uyUTSRorngS8y9-NZismtng=.fd56fd8b-ba7e-4e8b-97cc-c250acc7ecdc@github.com>
Message-ID: <yYgFQqJI3fboRY9vt00IfLtqP7bFZQJ5DD48pWSv2GA=.cb070f81-ac94-44f6-b193-6188b0021bcf@github.com>

On Fri, 25 Jul 2025 15:36:59 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Yes, but in this way you see at a glance that the parameter is a constant, and you do not have to check all the method's code.
>
> I guess most developer use a Java IDE for Java development.
> My IDE shows variables that are altered by underlying their name at every occurrence in the code. I can see at a glance that `n` is not modified even without `final`.
> As said, it's a matter of convention. In the OpenJDK we usually don't use `final` on parameters, as it clutters the header. Just have a look at a random place in the codebase.

underlying -> underlining

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2231449148

From rgiulietti at openjdk.org  Fri Jul 25 15:42:58 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 25 Jul 2025 15:42:58 GMT
Subject: RFR: 8077587: BigInteger Roots [v45]
In-Reply-To: <5leWD-u1Xmk5MuOz2QQOI1E-Sw1psi35OuPKvGmQbQ4=.a751cdc3-f7ac-4b0f-8e7c-5e86dc5d03f8@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <I7aYp0FRNnbjVqayzg3HCOhx05ZMnJXih61G0tZHluI=.0cb682ba-bf40-4729-807e-100ce83b5753@github.com>
 <aTIf0PDMB0Lf_LLiWemJOGnmi8WFTP4U7QTj2a7ooc8=.b7bc7b3d-17f1-4c79-84ba-54956f25467f@github.com>
 <5leWD-u1Xmk5MuOz2QQOI1E-Sw1psi35OuPKvGmQbQ4=.a751cdc3-f7ac-4b0f-8e7c-5e86dc5d03f8@github.com>
Message-ID: <dPSW30q_njfI46LGxliHYHA38FYQ0JU98LfLiyMphVc=.57a48730-1217-45fd-90b3-ec5a047d83ad@github.com>

On Fri, 25 Jul 2025 15:18:00 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1934:
>> 
>>> 1932:             return new MutableBigInteger[] { this, new MutableBigInteger() };
>>> 1933: 
>>> 1934:         final int bitLength = (int) this.bitLength();
>> 
>> The method does not state that it is assuming that `bitLength()` fits in an `int`.
>
> Indeed, I did not stated it because I was not sure if it were better to assume that `bitLength()` fits in an `int`, or to throw an `ArithmeticException` instead if it doesn't...

Not sure.
The method makes other assumptions that are not checked. Since the class is not public, that might be OK if the assumptions are all stated correctly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2231455849

From alan.bateman at oracle.com  Fri Jul 25 15:56:11 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Fri, 25 Jul 2025 16:56:11 +0100
Subject: JavaFX TextInputControl private access yet supposed to be
 overrided problem
In-Reply-To: <PAXP251MB06716288867F1DCDF8FB5AEA8859A@PAXP251MB0671.EURP251.PROD.OUTLOOK.COM>
References: <PAXP251MB06716288867F1DCDF8FB5AEA8859A@PAXP251MB0671.EURP251.PROD.OUTLOOK.COM>
Message-ID: <409f96b0-c693-4e77-8152-83248537cac5@oracle.com>

On 25/07/2025 16:19, tom L wrote:
> Hello.
> I have this problem where a lot of methods and utility in TextInputControl

I think you are looking for openjfx-dev.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250725/eb2fafe1/attachment.htm>

From alanb at openjdk.org  Fri Jul 25 16:10:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Jul 2025 16:10:55 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks
In-Reply-To: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
Message-ID: <KAxsoK5YKrGG8gqaYlSv1dBHrBL4qMs-hQAgJ1TPFxA=.09d2c1de-7a0a-4c63-8031-16d45fcae90e@github.com>

On Fri, 25 Jul 2025 12:21:43 GMT, Doug Lea <dl at openjdk.org> wrote:

> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.

I wonder if we should update forkjoin/Starvation.java now (or later) so that its exercises the second task as Runnable, Callable and ForkJoinTask. Happy to contribute more tests here as we've had so many fence issues on aarch64.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26479#issuecomment-3119042516

From jlu at openjdk.org  Fri Jul 25 16:34:58 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 25 Jul 2025 16:34:58 GMT
Subject: RFR: 8364089: JDK 25 RDP2 L10n resource files update
In-Reply-To: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
References: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
Message-ID: <r76j2NQHkxocAYYa9d5eDL_XoKTwi0Y-O0S4PQPBa0o=.53a4966d-b9de-4332-b82c-f4d40412f101@github.com>

On Fri, 25 Jul 2025 00:25:01 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Looks good. The JBS issue will need to be set as a P2 to be eligible for backport to 25.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties line 103:

> 101: 
> 102: # 0: string
> 103: launcher.err.cant.find.main.method=Konnte keine main(String[])- oder main()-Methode in der Klasse: {0} finden.

As we discussed, even though we used this suggestion last drop, the translation team rejected the translation.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 89:

> 87: MSG_BundlerConfigExceptionNoAdvice=Bundler {0} aufgrund eines Konfigurationsproblems ?bersprungen: {1}
> 88: MSG_BundlerRuntimeException=Bundler {0} nicht erfolgreich. Grund: {1}
> 89: MSG_BundlerFailed=Fehler: Bundler "{1}" ({0}) konnte kein Package generieren

Even though there was no change in the original, it looks like they removed this entry because it was a duplicate. We should consider filing a separate issue to have the duplicate removed in the original as well.

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26467#pullrequestreview-3056110784
PR Review Comment: https://git.openjdk.org/jdk/pull/26467#discussion_r2231568635
PR Review Comment: https://git.openjdk.org/jdk/pull/26467#discussion_r2231553322

From duke at openjdk.org  Fri Jul 25 16:58:03 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 25 Jul 2025 16:58:03 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v13]
In-Reply-To: <58dZrvPejcKmpsrPdcmzCJWoXR_Tu_inMfk8PuB1zmE=.096138ee-f88d-4a88-8e3b-657ca77d985d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <J-JqNtmP25GS9ovkcbl-IWtEZ2Oa8iGSROlZTuVAHJQ=.7c38d62a-020c-4edc-baac-c42833e5ca97@github.com>
 <58dZrvPejcKmpsrPdcmzCJWoXR_Tu_inMfk8PuB1zmE=.096138ee-f88d-4a88-8e3b-657ca77d985d@github.com>
Message-ID: <27jhMI1bDNx3Qo8knxSZsicmX41ZcJolvAxjzr0Eq_k=.58183dae-0ad5-45d9-b81e-a198df7e20b0@github.com>

On Wed, 23 Jul 2025 06:58:42 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.
>
> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 51:
> 
>> 49:  * file system friendly way. The jimage entries (resources, module and package
>> 50:  * information) are mapped into a unified hierarchy of named nodes, which serve
>> 51:  * as the underlying structure for the {@code JrtFileSystem} and other utilities.
> 
> I think it's a bit confusing to document this class as an adapter for a BasicImageReader because you obtain one with static open methods that specify the file path to the jimage file. So I think better to start out in the class description by saying that it provide an API that can be used to create file system and other views over the contents of the jimage file.

Except it's not *quite* a view over the contents. The change in namespace (resources now get the same "/modules" prefix as resources, and that namespace unification that is one of the key benefits of this class because it's suddenly compatible with the notion of paths in a filesystem. That's why I refer to the JRT filesystem (which is almost the only thing that actually uses this class).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2231606406

From duke at openjdk.org  Fri Jul 25 17:02:14 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 25 Jul 2025 17:02:14 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v13]
In-Reply-To: <58dZrvPejcKmpsrPdcmzCJWoXR_Tu_inMfk8PuB1zmE=.096138ee-f88d-4a88-8e3b-657ca77d985d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <J-JqNtmP25GS9ovkcbl-IWtEZ2Oa8iGSROlZTuVAHJQ=.7c38d62a-020c-4edc-baac-c42833e5ca97@github.com>
 <58dZrvPejcKmpsrPdcmzCJWoXR_Tu_inMfk8PuB1zmE=.096138ee-f88d-4a88-8e3b-657ca77d985d@github.com>
Message-ID: <CqTteW_TlTQxSWBx4QydU-Nc_NvXKNCIXYLtubkmLOw=.92fc327e-fade-4bbb-8b8c-12b4ec2c8f58@github.com>

On Wed, 23 Jul 2025 07:00: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:
>> 
>>   Feedback changes.
>
> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 138:
> 
>> 136:      * @param name a JRT file system name (path) of the form
>> 137:      * {@code "/modules/<module>/...} or {@code "/packages/<package>/...}.
>> 138:      * @return a node representing a resource, directory or symbolic link.
> 
> This is the jimage reader rather than the jrt file system so it's very confusing to see comments about "JRT file system" in this file.

This class is *almost* only here for building JrtFileSystem. Everything else is marginal usage. Hence, admitting that in these docs felt reasonable to me. I think it would be bad if someone reading the docs in this class didn't know that there's a strong reason for the namespace unification. I can reframe it to talk-around the fact this is all ultimately for file-system like semantics without naming JrtFileSystem, but they are extremely closely coupled in terms of usage.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2231614903

From alanb at openjdk.org  Fri Jul 25 17:12:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Jul 2025 17:12:00 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v13]
In-Reply-To: <CqTteW_TlTQxSWBx4QydU-Nc_NvXKNCIXYLtubkmLOw=.92fc327e-fade-4bbb-8b8c-12b4ec2c8f58@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <J-JqNtmP25GS9ovkcbl-IWtEZ2Oa8iGSROlZTuVAHJQ=.7c38d62a-020c-4edc-baac-c42833e5ca97@github.com>
 <58dZrvPejcKmpsrPdcmzCJWoXR_Tu_inMfk8PuB1zmE=.096138ee-f88d-4a88-8e3b-657ca77d985d@github.com>
 <CqTteW_TlTQxSWBx4QydU-Nc_NvXKNCIXYLtubkmLOw=.92fc327e-fade-4bbb-8b8c-12b4ec2c8f58@github.com>
Message-ID: <xpu8QRHMSjHQhZeVoH_f3BtSadymCvYQiZa4RX6i5ZQ=.3b8724d2-afd9-4017-8c0d-9b811c62bcdc@github.com>

On Fri, 25 Jul 2025 16:58:49 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 138:
>> 
>>> 136:      * @param name a JRT file system name (path) of the form
>>> 137:      * {@code "/modules/<module>/...} or {@code "/packages/<package>/...}.
>>> 138:      * @return a node representing a resource, directory or symbolic link.
>> 
>> This is the jimage reader rather than the jrt file system so it's very confusing to see comments about "JRT file system" in this file.
>
> This class is *almost* only here for building JrtFileSystem. Everything else is marginal usage. Hence, admitting that in these docs felt reasonable to me. I think it would be bad if someone reading the docs in this class didn't know that there's a strong reason for the namespace unification. I can reframe it to talk-around the fact this is all ultimately for file-system like semantics without naming JrtFileSystem, but they are extremely closely coupled in terms of usage.

It should be possible to move jrtfs to its own module, say jdk.jrtfs. It does not need to be in the base module. My comments are only to ensure that we keep the architectural boundaries clean.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2231635708

From duke at openjdk.org  Fri Jul 25 17:12:03 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 25 Jul 2025 17:12:03 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v13]
In-Reply-To: <ER3v_je0TyvgB2Jlnz2pQu0Spwuvva2dcog79VHAuKc=.d407cf55-4d16-4207-a7bf-ca1485c47dc1@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <J-JqNtmP25GS9ovkcbl-IWtEZ2Oa8iGSROlZTuVAHJQ=.7c38d62a-020c-4edc-baac-c42833e5ca97@github.com>
 <ER3v_je0TyvgB2Jlnz2pQu0Spwuvva2dcog79VHAuKc=.d407cf55-4d16-4207-a7bf-ca1485c47dc1@github.com>
Message-ID: <O_fTqc04K2iRfTT04zOABGzWwV-xnXnsgEBbRjOKxjk=.e68a0b83-1373-49c1-b915-69ffa609337b@github.com>

On Wed, 23 Jul 2025 06:37:34 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.
>
> src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 259:
> 
>> 257:         ImageReader reader = SystemImage.reader();
>> 258:         try {
>> 259:             return reader.findNode("/modules").getChildNames().map(mn -> readModuleAttributes(reader, mn));
> 
> Can you put the line over 3 lines so that it's easier to see the pipeline.

Done.

> src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 265:
> 
>> 263:     }
>> 264: 
>> 265:     // Every module is required to have a valid module-info.class.
> 
> The methods in this class use use /** ..*/ in the method descriptions so would prefer if the changes change that. Here the method should really say that it returns the module's module-info, returning a holder for its class file attributes.

That comment was JavaDoc, just an implementation note (since it's private and no separate doc would be created for it). I fleshed it out a bit though.

> src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 276:
> 
>> 274:             err = e;
>> 275:         }
>> 276:         throw new Error("Missing or invalid module-info.class for module: " + moduleName, err);
> 
> I assume this can move into the catch block.

No because the return is conditional above "node != null && node.isResource()".

> src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 457:
> 
>> 455:          * a non-resource node, then {@code null} is returned.
>> 456:          */
>> 457:         private ImageReader.Node findResourceNode(ImageReader reader, String name) throws IOException {
> 
> I think the usage would be clear if this were renamed to findResource.

Done.

> src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 470:
> 
>> 468:         public Optional<ByteBuffer> read(String name) throws IOException {
>> 469:             ImageReader reader = SystemImage.reader();
>> 470:             return Optional.ofNullable(findResourceNode(reader, name)).map(reader::getResourceBuffer);
> 
> Style wise, can you put the .map(...) on the next line so this is easier to read.

Done. Is there any documented best practice for this sort of line splitting (since there isn't an enforce formatter).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2231629846
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2231634425
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2231631736
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2231628586
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2231626965

From duke at openjdk.org  Fri Jul 25 17:16:45 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 25 Jul 2025 17:16:45 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v14]
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: <MkQJtnkihdEQ7AOs_EH-SZnihE6n6tAYbNVqsB3hqTU=.ee282be0-82de-4223-a9b2-2f9bf8c718ba@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 tweaks.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26054/files
  - new: https://git.openjdk.org/jdk/pull/26054/files/12f34994..a1742ebf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=12-13

  Stats: 18 lines in 2 files changed: 6 ins; 7 del; 5 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  Fri Jul 25 17:22:05 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 25 Jul 2025 17:22:05 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v13]
In-Reply-To: <xpu8QRHMSjHQhZeVoH_f3BtSadymCvYQiZa4RX6i5ZQ=.3b8724d2-afd9-4017-8c0d-9b811c62bcdc@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <J-JqNtmP25GS9ovkcbl-IWtEZ2Oa8iGSROlZTuVAHJQ=.7c38d62a-020c-4edc-baac-c42833e5ca97@github.com>
 <58dZrvPejcKmpsrPdcmzCJWoXR_Tu_inMfk8PuB1zmE=.096138ee-f88d-4a88-8e3b-657ca77d985d@github.com>
 <CqTteW_TlTQxSWBx4QydU-Nc_NvXKNCIXYLtubkmLOw=.92fc327e-fade-4bbb-8b8c-12b4ec2c8f58@github.com>
 <xpu8QRHMSjHQhZeVoH_f3BtSadymCvYQiZa4RX6i5ZQ=.3b8724d2-afd9-4017-8c0d-9b811c62bcdc@github.com>
Message-ID: <1gNyNe8zEjdG05GnVtkWKQ4qlcd3v8IwyaBuNCQZFyQ=.48a97057-3e32-467b-8100-82e4ee5c20ab@github.com>

On Fri, 25 Jul 2025 17:09:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This class is *almost* only here for building JrtFileSystem. Everything else is marginal usage. Hence, admitting that in these docs felt reasonable to me. I think it would be bad if someone reading the docs in this class didn't know that there's a strong reason for the namespace unification. I can reframe it to talk-around the fact this is all ultimately for file-system like semantics without naming JrtFileSystem, but they are extremely closely coupled in terms of usage.
>
> It should be possible to move jrtfs to its own module, say jdk.jrtfs. It does not need to be in the base module. My comments are only to ensure that we keep the architectural boundaries clean.

Also, the line:

"is used internally in the JDK to implement jimage/jrtfs access"

is just below so it's not the first admission that this is aligned closely with JrtFileSystem.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2231652596

From naoto at openjdk.org  Fri Jul 25 17:26:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 25 Jul 2025 17:26:55 GMT
Subject: RFR: 8364089: JDK 25 RDP2 L10n resource files update
In-Reply-To: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
References: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
Message-ID: <DAVpxfrk7RSbrseRryOh8LMEyykStSy5tLnPN4kqiUk=.d31ae25d-b093-4ad7-85e7-673191b7dba1@github.com>

On Fri, 25 Jul 2025 00:25:01 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26467#pullrequestreview-3056268896

From duke at openjdk.org  Fri Jul 25 17:32:19 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 25 Jul 2025 17:32:19 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v15]
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: <tF6q4wlxpAnHevpHtKkRK_slLbUSI7f4mvUZUnrEv9o=.362472f5-a976-4a2a-9412-c0c444c7287b@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:

  Removing direct references to JrtFS.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26054/files
  - new: https://git.openjdk.org/jdk/pull/26054/files/a1742ebf..a41b48df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=13-14

  Stats: 26 lines in 1 file changed: 7 ins; 3 del; 16 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  Fri Jul 25 17:35:59 2025
From: duke at openjdk.org (fabioromano1)
Date: Fri, 25 Jul 2025 17:35:59 GMT
Subject: RFR: 8077587: BigInteger Roots [v46]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <gE7trYGIe42TkyAR9oK4JRMRjOiaQuchAXptr4vkxNs=.02d9865c-d65d-4ead-a7bd-dfe9f7873210@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Revision changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/29ec5146..cd7f3342

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=45
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=44-45

  Stats: 21 lines in 1 file changed: 9 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From dnguyen at openjdk.org  Fri Jul 25 18:10:54 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 25 Jul 2025 18:10:54 GMT
Subject: RFR: 8364089: JDK 25 RDP2 L10n resource files update
In-Reply-To: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
References: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
Message-ID: <6mNG6Cl0KiLoDgm1jq8nS_YaE_r2mp_dI2LmYuf1Dg8=.c050b5ea-f590-4dbb-80a8-1b7628d7db92@github.com>

On Fri, 25 Jul 2025 00:25:01 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Marked as reviewed by dnguyen (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26467#pullrequestreview-3056385560

From dl at openjdk.org  Fri Jul 25 18:24:02 2025
From: dl at openjdk.org (Doug Lea)
Date: Fri, 25 Jul 2025 18:24:02 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks
In-Reply-To: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
Message-ID: <aoLvgz1MBxlM22e0WOpi1cQzf74jOzovmYKl0b1zflg=.a9ea2a3a-94cc-4e09-a22a-b19865909b53@github.com>

On Fri, 25 Jul 2025 12:21:43 GMT, Doug Lea <dl at openjdk.org> wrote:

> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.

Added a second test case to Starvation test for plain (non-Interruptible) tasks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26479#issuecomment-3119888769

From dl at openjdk.org  Fri Jul 25 18:24:01 2025
From: dl at openjdk.org (Doug Lea)
Date: Fri, 25 Jul 2025 18:24:01 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v2]
In-Reply-To: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
Message-ID: <rqKuQ0-J0EP1em1zTco3EblOcNhaQ2eFdrq6yyYPF4A=.d5c98820-8ef1-481c-b838-510e53639b2e@github.com>

> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Add adapt(callable) case to test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26479/files
  - new: https://git.openjdk.org/jdk/pull/26479/files/edd37c0e..64ba474a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=00-01

  Stats: 19 lines in 1 file changed: 18 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479

PR: https://git.openjdk.org/jdk/pull/26479

From duke at openjdk.org  Fri Jul 25 18:32:07 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 25 Jul 2025 18:32:07 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v13]
In-Reply-To: <ER3v_je0TyvgB2Jlnz2pQu0Spwuvva2dcog79VHAuKc=.d407cf55-4d16-4207-a7bf-ca1485c47dc1@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <J-JqNtmP25GS9ovkcbl-IWtEZ2Oa8iGSROlZTuVAHJQ=.7c38d62a-020c-4edc-baac-c42833e5ca97@github.com>
 <ER3v_je0TyvgB2Jlnz2pQu0Spwuvva2dcog79VHAuKc=.d407cf55-4d16-4207-a7bf-ca1485c47dc1@github.com>
Message-ID: <i36Fo-AnEDtCnJcv5c6VUauUft1uQzrsYUHAxQCfw1k=.101903ce-b476-4fe3-a69f-e286281a1d42@github.com>

On Wed, 23 Jul 2025 06:34:48 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.
>
> src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 464:
> 
>> 462:             String nodeName = "/modules/" + module + "/" + name;
>> 463:             ImageReader.Node node = reader.findNode(nodeName);
>> 464:             return node != null && node.isResource() ? node : null;
> 
> Style wise, can you put ( ) around the expression to avoid having to pause and check precedence.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2231771828

From jbhateja at openjdk.org  Fri Jul 25 20:09:40 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Jul 2025 20:09:40 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v2]
In-Reply-To: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
Message-ID: <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>

> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction.
> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails.
> 
>  Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java).
> 
> Vector API jtreg tests pass at AVX level 2, remaining validation in progress.
> 
> Performance numbers:
> 
> 
> System : 13th Gen Intel(R) Core(TM) i3-1315U
> 
> Baseline:
> Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2   9444.444          ops/ms
> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  10009.319          ops/ms
> VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9081.926          ops/ms
> VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2   6085.825          ops/ms
> VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2   6505.378          ops/ms
> VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6204.489          ops/ms
> VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2   1651.334          ops/ms
> VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   1642.784          ops/ms
> VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1474.808          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  10399.394          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  10502.894          ops/ms
> VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024 ...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Updating predicate checks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24104/files
  - new: https://git.openjdk.org/jdk/pull/24104/files/b2e93434..04be59a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104

PR: https://git.openjdk.org/jdk/pull/24104

From almatvee at openjdk.org  Fri Jul 25 21:31:05 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 25 Jul 2025 21:31:05 GMT
Subject: RFR: 8360507: JPKG002-006: SigningPackageTest: appOutput.txt cannot be
 found in user home directory and output doesn't contain: origin=Developer ID
 Application: jpackage.openjdk.java.net
Message-ID: <fAuoE-ZANsAJ2EpjGiWWAhur5mp9AmT2eSMYzelOdfw=.69551766-28bc-4627-b529-12b63d162e95@github.com>

- Wrong package was generated for SQE. Fixed by generating correct package for SQE.
- Issue with appOutput.txt is not created will be fixed with https://bugs.openjdk.org/browse/JDK-8358723.

-------------

Commit messages:
 - 8360507: JPKG002-006: SigningPackageTest: appOutput.txt cannot be found in user home directory and output doesn't contain: origin=Developer ID Application: jpackage.openjdk.java.net

Changes: https://git.openjdk.org/jdk/pull/26485/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26485&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360507
  Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26485.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26485/head:pull/26485

PR: https://git.openjdk.org/jdk/pull/26485

From duke at openjdk.org  Sat Jul 26 07:30:54 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 26 Jul 2025 07:30:54 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc.
In-Reply-To: <196EiVbN3eRqsKa6dSY6qlQuGcncN9gSihR5hTNuMVw=.ca7a4101-28b2-418f-870a-1cb25d00c0a0@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <196EiVbN3eRqsKa6dSY6qlQuGcncN9gSihR5hTNuMVw=.ca7a4101-28b2-418f-870a-1cb25d00c0a0@github.com>
Message-ID: <sQ6kbF1jG3RynZSbeJ0zMsRnXJhD3M2T8W1ebHqyJ6k=.c51b11a3-b41b-46b5-83e9-831d71e1f265@github.com>

On Thu, 24 Jul 2025 22:07:38 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
>> 
>> 
>> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>>     throw new Exception("exceeding length");
>> }
>> 
>> 
>> Is a CSR required to this change?
>
> src/java.base/share/classes/java/lang/Character.java line 9969:
> 
>> 9967:         int n = length;
>> 9968:         for (int i = 0; i < length; ) {
>> 9969:             if (isHighSurrogate(seq.charAt(i++)) && i < length &&
> 
> Imo this is quite hard to read, especially with `i++` inside of the if statement. What do you think about changing it to this? 
> ```java 
> for (int i = 1; i < length-1; i++) {
>     if (isHighSurrogate(seq.charAt(i)) &&
>         isLowSurrogate(seq.charAt(i + 1))) {
>         n--;
>         i++;
>     }
> }
> ``` 
> 
> edit: fixed a typo in my example

In the first place it yields an _incorrect_ result for sequences whose first character is a supplementary character.


jshell> int len(CharSequence seq) {
   ...>     final int length = seq.length();
   ...>     int n = length;
   ...>     for (int i = 1; i < length-1; i++) {
   ...>             if (isHighSurrogate(seq.charAt(i)) &&
   ...>                 isLowSurrogate(seq.charAt(i + 1))) {
   ...>                     n--;
   ...>                     i++;
   ...>             }
   ...>     }
   ...>     return n;
   ...> }
|  ????????: ???? len(CharSequence)????? method isHighSurrogate(char), and method isLowSurrogate(char)????????????????

jshell> boolean isHighSurrogate(char ch) {
   ...>     return 0xd800 <= ch && ch <= 0xdbff;
   ...> }
|  ????????: ???? isHighSurrogate(char)

jshell> boolean isLowSurrogate(char ch) {
   ...>     return 0xdc00 <= ch && ch <= 0xdfff;
   ...> }
|  ????????: ???? isLowSurrogate(char)

jshell> len("?");
$5 ==> 2

jshell> len("OK?");
$6 ==> 3

jshell> len("??");
$7 ==> 3


I will not change it alone unless the existing overload `int codePointCount(CharSequence seq, int beginIndex, int endIndex)` is also planned to be changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2232751973

From duke at openjdk.org  Sat Jul 26 07:51:01 2025
From: duke at openjdk.org (ExE Boss)
Date: Sat, 26 Jul 2025 07:51:01 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: <tYdVgQBeFsiI1UHHItThr7FhEluU5_1RclwEIYI2Ing=.8c7f471e-f0cf-4e4e-9709-6a8a9cd2147d@github.com>

On Thu, 19 Jun 2025 08:08:10 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/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?

No, because?those are?`private`, accessible only?through the?`public static`?getters.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2232777224

From duke at openjdk.org  Sat Jul 26 07:51:01 2025
From: duke at openjdk.org (ExE Boss)
Date: Sat, 26 Jul 2025 07:51:01 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: <goNlSp75pxPfwgD4zUK3kB9_3TKSm_O0z0G8I4zviGw=.fa378954-2a5f-46e0-93ee-ec91adb8082c@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/KQueuePoller.java line 44:

> 42: 
> 43:     KQueuePoller(boolean subPoller, boolean read) throws IOException {
> 44:         this.kqfd = kqueue_h.kqueue();

Note?that the?old?implementation of?`KQueue.create()` had?a?check for?negative `kqfd`:
https://github.com/openjdk/jdk/blob/d288ca28be7bfba3abe9f54cefbe53e73c25707e/src/java.base/macosx/native/libnio/ch/KQueue.c#L63-L71

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2232782518

From duke at openjdk.org  Sat Jul 26 08:36:41 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 26 Jul 2025 08:36:41 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc. [v2]
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <BAgjxwbEh8sYWfD2tJf7nSU_Pb5rdw9jBewrGCy8O8o=.d8325f59-50bd-4f4a-8fe1-3de2102a69aa@github.com>

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:

 - Discard changes out of than java.base
 - Fix copyright year
   
   Co-authored-by: Mikhail Yankelevich <myankelevich at openjdk.org>
 - Fix how to get code point count in StringBuilder
   
   Co-authored-By: Chen Liang <liach at openjdk.org>
 - Fix test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26461/files
  - new: https://git.openjdk.org/jdk/pull/26461/files/6f2e1d2b..63eb4a7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=00-01

  Stats: 10 lines in 7 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/26461.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461

PR: https://git.openjdk.org/jdk/pull/26461

From duke at openjdk.org  Sat Jul 26 08:36:41 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 26 Jul 2025 08:36:41 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc. [v2]
In-Reply-To: <y_R_o6taygSCoX84MIf4aCogNn_yVlejH3hzRVRZSgU=.85b8004b-dab6-4c58-9105-6a86b6cb267a@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <y_R_o6taygSCoX84MIf4aCogNn_yVlejH3hzRVRZSgU=.85b8004b-dab6-4c58-9105-6a86b6cb267a@github.com>
Message-ID: <AApM1SQJDnYua8EgKFE6MHAEcfQmQKjsMgualBjyN5w=.439c07a4-fdbe-4121-9456-277822927077@github.com>

On Thu, 24 Jul 2025 16:18:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Discard changes out of than java.base
>>  - Fix copyright year
>>    
>>    Co-authored-by: Mikhail Yankelevich <myankelevich at openjdk.org>
>>  - Fix how to get code point count in StringBuilder
>>    
>>    Co-authored-By: Chen Liang <liach at openjdk.org>
>>  - Fix test
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 545:
> 
>> 543:         byte[] value = this.value;
>> 544:         if (isLatin1(coder)) {
>> 545:             return value.length;
> 
> Suggestion:
> 
>             return count;

I see, I fixed the argument passed to `StringUTF16.codePointCount` too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2232795947

From duke at openjdk.org  Sat Jul 26 08:36:41 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 26 Jul 2025 08:36:41 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc. [v2]
In-Reply-To: <FkuVToJew8Yt-S4GV3S5hFEM2omQnXtS4a3LoACWRpk=.2f0c76b2-d634-40fc-b241-f97d274cf7d9@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <FkuVToJew8Yt-S4GV3S5hFEM2omQnXtS4a3LoACWRpk=.2f0c76b2-d634-40fc-b241-f97d274cf7d9@github.com>
Message-ID: <PspvQ2kci2XBVM0rUFweY_IAgTTNJ90nVJdfoO1kgbY=.4fa23aee-ff6c-43c6-a829-49f839445680@github.com>

On Thu, 24 Jul 2025 21:49:16 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Discard changes out of than java.base
>>  - Fix copyright year
>>    
>>    Co-authored-by: Mikhail Yankelevich <myankelevich at openjdk.org>
>>  - Fix how to get code point count in StringBuilder
>>    
>>    Co-authored-By: Chen Liang <liach at openjdk.org>
>>  - Fix test
>
> test/jdk/java/lang/StringBuilder/Supplementary.java line 216:
> 
>> 214:         testAppendCodePoint(Character.MAX_CODE_POINT+1, IllegalArgumentException.class);
>> 215:     }
>> 216: 
> 
> nit, as the other copyrights are updated: 
> 
> * Copyright (c) 2003, 2025, Oracle and/or its affiliates. All rights reserved.

My fault, I renewed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2232795594

From duke at openjdk.org  Sat Jul 26 08:50:55 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 26 Jul 2025 08:50:55 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc.
In-Reply-To: <_ZiQNuzt_mXMGd0GGi1XZhAjYFu0lc0ULkdlRdWQ-qE=.19c4501b-aa62-4b2f-b996-aed285ecc781@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <_ZiQNuzt_mXMGd0GGi1XZhAjYFu0lc0ULkdlRdWQ-qE=.19c4501b-aa62-4b2f-b996-aed285ecc781@github.com>
Message-ID: <zVRJSzj-TVoH1tbtPukFJGMtmyKWESLUZumA0LGa4O8=.002484e9-6b57-45f1-9a7f-817a83fa6cc2@github.com>

On Thu, 24 Jul 2025 15:10:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The recommended process for proposing new APIs is to put the proposal to the OpenJDK core-libs-dev mail alias.

I glanced over https://mail.openjdk.org/pipermail/core-libs-dev/2025-July/thread.html and those for some past months, but I did not get how to send one.

According to https://mail.openjdk.org/pipermail/core-libs-dev/2025-July/149338.html and sub messages, the content in this PR seems to be transferred to the mailing list.

> Also, do we need codePointCount on CharSequence?

I did not add it because it does not have an existing overload and has a simple (but not efficient) workaround (`codePoints().count()`), but it would be nice if it exists.

> Could you please add a bug number under @bug?

Which doc comments shall I add it?

> And yes, every change to the spec needs a CSR.

I got it, but do you know how non-Authors like me create ones?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3121518177

From duke at openjdk.org  Sat Jul 26 08:54:03 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 26 Jul 2025 08:54:03 GMT
Subject: RFR: 8077587: BigInteger Roots [v47]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <MZ-awXr8TPb66u7o3zvI7lVjl1bF5cbuOpPvY1UDvLI=.268c476f-0da7-4311-84e5-1108ea2b233b@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Avoid overflow after first iteration

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/cd7f3342..b23480cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=45-46

  Stats: 15 lines in 1 file changed: 4 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From duke at openjdk.org  Sat Jul 26 10:10:40 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 26 Jul 2025 10:10:40 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc. [v3]
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:

 - Update `@bug` in correct file
 - Add default implementation on codePointCount in CharSequence
 - Update `@bug` entries in test class doc comments
 - Discard changes on code whose form is not `str.codePointCount(0, str.length())`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26461/files
  - new: https://git.openjdk.org/jdk/pull/26461/files/63eb4a7d..0e55e35c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=01-02

  Stats: 32 lines in 5 files changed: 26 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26461.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461

PR: https://git.openjdk.org/jdk/pull/26461

From duke at openjdk.org  Sat Jul 26 10:22:53 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 26 Jul 2025 10:22:53 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc. [v3]
In-Reply-To: <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
Message-ID: <jVLO3nEjKz0T_0TBR-pRqQoA-QckJHFouSlGaah8uW8=.a3dcce0a-8582-4727-8645-f44a69c73205@github.com>

On Sat, 26 Jul 2025 10:10:40 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
>> 
>> 
>> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>>     throw new Exception("exceeding length");
>> }
>> 
>> 
>> Is a CSR required to this change?
>
> Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Update `@bug` in correct file
>  - Add default implementation on codePointCount in CharSequence
>  - Update `@bug` entries in test class doc comments
>  - Discard changes on code whose form is not `str.codePointCount(0, str.length())`

How and where can I add tests for default implementing methods in `CharSequence`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3121593297

From dl at openjdk.org  Sat Jul 26 12:12:43 2025
From: dl at openjdk.org (Doug Lea)
Date: Sat, 26 Jul 2025 12:12:43 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v3]
In-Reply-To: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
Message-ID: <ZwXtLw0rqD2GHTiPG1ve_Di6xG6i2cY2IDqtVfutdt8=.58d76232-e95c-498b-b0ef-53f71c8f3ba5@github.com>

> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Undo inadvertent acquire change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26479/files
  - new: https://git.openjdk.org/jdk/pull/26479/files/64ba474a..6b22e247

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479

PR: https://git.openjdk.org/jdk/pull/26479

From duke at openjdk.org  Sat Jul 26 12:57:54 2025
From: duke at openjdk.org (fabioromano1)
Date: Sat, 26 Jul 2025 12:57:54 GMT
Subject: RFR: 8077587: BigInteger Roots [v48]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <urVgOHnU4PVeY5WbcVubB11TMTsjzxPwPuF3IIPIZ-k=.57d90c7b-436d-4d95-9102-01550382550b@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Code simplification

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/b23480cd..c879edb4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=47
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=46-47

  Stats: 6 lines in 1 file changed: 2 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From jpai at openjdk.org  Sat Jul 26 14:24:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 26 Jul 2025 14:24:00 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc. [v3]
In-Reply-To: <jVLO3nEjKz0T_0TBR-pRqQoA-QckJHFouSlGaah8uW8=.a3dcce0a-8582-4727-8645-f44a69c73205@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
 <jVLO3nEjKz0T_0TBR-pRqQoA-QckJHFouSlGaah8uW8=.a3dcce0a-8582-4727-8645-f44a69c73205@github.com>
Message-ID: <YgNYs5M1Ys2vCTQ5KZpC7ndV3aIDSf-j_GODF3by2ZA=.1a2dc1cb-155c-4ad8-b800-167baa3533c4@github.com>

On Sat, 26 Jul 2025 10:20:20 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Update `@bug` in correct file
>>  - Add default implementation on codePointCount in CharSequence
>>  - Update `@bug` entries in test class doc comments
>>  - Discard changes on code whose form is not `str.codePointCount(0, str.length())`
>
> How and where can I add tests for default implementing methods in `CharSequence`?

Hello @tats-u,

> > The recommended process for proposing new APIs is to put the proposal to the OpenJDK core-libs-dev mail alias.
> 
> I glanced over https://mail.openjdk.org/pipermail/core-libs-dev/2025-July/thread.html and those for some past months, but I did not get how to send one.
> 
The OpenJDK contribution guide has the necessary details on how to contribute to the project. Specifically this section https://openjdk.org/guide/#socialize-your-change is of relevance. In order to send a mail to the core-libs-dev mailing list, please first subscribe to that mailing list https://mail.openjdk.org/mailman/listinfo/core-libs-dev and initiate a discussion explaining the need and motivation for this new API. After there's some agreement about this proposal, the implementation changes in this PR can be pursued further.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3121977983

From alanb at openjdk.org  Sat Jul 26 14:29:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 26 Jul 2025 14:29:54 GMT
Subject: RFR: 8364007: Add overload without arguments to codePointCount in
 String etc. [v3]
In-Reply-To: <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
Message-ID: <uLmMkM1XRQjEEitj1ErhvawNNE7ZvcHhHh6YweejsxE=.f48897bd-4f73-4d75-982d-ca4b3f6ebb36@github.com>

On Sat, 26 Jul 2025 10:10:40 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
>> 
>> 
>> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>>     throw new Exception("exceeding length");
>> }
>> 
>> 
>> Is a CSR required to this change?
>
> Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Update `@bug` in correct file
>  - Add default implementation on codePointCount in CharSequence
>  - Update `@bug` entries in test class doc comments
>  - Discard changes on code whose form is not `str.codePointCount(0, str.length())`

The addition to CharSequence will require static analysis to check for conflicts with implementation. It will also likely impact the CharBuffer spec.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3121986320

From asemenyuk at openjdk.org  Sat Jul 26 20:20:54 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 26 Jul 2025 20:20:54 GMT
Subject: RFR: 8360507: JPKG002-006: SigningPackageTest: appOutput.txt
 cannot be found in user home directory and output doesn't contain:
 origin=Developer ID Application: jpackage.openjdk.java.net
In-Reply-To: <fAuoE-ZANsAJ2EpjGiWWAhur5mp9AmT2eSMYzelOdfw=.69551766-28bc-4627-b529-12b63d162e95@github.com>
References: <fAuoE-ZANsAJ2EpjGiWWAhur5mp9AmT2eSMYzelOdfw=.69551766-28bc-4627-b529-12b63d162e95@github.com>
Message-ID: <S8Mz8_Yn_2rPMbDM2Vs5oBxWnPSUNXDUtM2pz_PU1sQ=.3c063b8a-c171-4fab-862a-aab63a05d540@github.com>

On Fri, 25 Jul 2025 21:25:36 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Wrong package was generated for SQE. Fixed by generating correct package for SQE.
> - Issue with appOutput.txt is not created will be fixed with https://bugs.openjdk.org/browse/JDK-8358723.

Marked as reviewed by asemenyuk (Reviewer).

Looks good!

-------------

PR Review: https://git.openjdk.org/jdk/pull/26485#pullrequestreview-3058505194
PR Comment: https://git.openjdk.org/jdk/pull/26485#issuecomment-3123232272

From swen at openjdk.org  Sun Jul 27 04:40:03 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 27 Jul 2025 04:40:03 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v8]
In-Reply-To: <Akc09cL762LAM8tZXqUuyIZiwKyYQpABKjAjjhqjeT0=.eadecf6b-1a3c-4061-8951-537e6e24742c@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
 <Akc09cL762LAM8tZXqUuyIZiwKyYQpABKjAjjhqjeT0=.eadecf6b-1a3c-4061-8951-537e6e24742c@github.com>
Message-ID: <YVXgIFUrrJVHUQCTjPB6eUjJGie7U-gTJMZJCkL4Igk=.ad4d5e6d-89c7-43e1-ac92-4a61cf5d369d@github.com>

On Thu, 24 Jul 2025 15:17:34 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/lang/StringUTF16.java
>>   
>>   Co-authored-by: Chen Liang <liach at openjdk.org>
>
> src/java.base/share/classes/java/lang/StringUTF16.java line 1489:
> 
>> 1487:                 Unsafe.ARRAY_CHAR_BASE_OFFSET + ((long) off << 1),
>> 1488:                 val,
>> 1489:                 Unsafe.ARRAY_BYTE_BASE_OFFSET + ((long) index << 1),
> 
> Suggestion:
> 
>                 Unsafe.ARRAY_BYTE_BASE_OFFSET + ((long) index << 1) * Unsafe.ARRAY_BYTE_INDEX_SCALE,

If we want to use ARRAY_CHAR_INDEX_SCALE, it should be used as follows

        Unsafe.getUnsafe().copyMemory(
                ca,
                Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off * Unsafe.ARRAY_CHAR_INDEX_SCALE,
                val,
                Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off * Unsafe.ARRAY_CHAR_INDEX_SCALE,
                (long) (end - off) << 1);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2233670252

From duke at openjdk.org  Sun Jul 27 07:35:14 2025
From: duke at openjdk.org (fabioromano1)
Date: Sun, 27 Jul 2025 07:35:14 GMT
Subject: RFR: 8077587: BigInteger Roots [v49]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <aNZy1y17283JCpsjpIMELc7tTKwBXlRHS1tvBQSLyVk=.92728df7-a446-4e4d-b228-63df6a15b058@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Minor optimization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/c879edb4..bbf58d5e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=48
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=47-48

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From duke at openjdk.org  Sun Jul 27 07:56:59 2025
From: duke at openjdk.org (fabioromano1)
Date: Sun, 27 Jul 2025 07:56:59 GMT
Subject: RFR: 8077587: BigInteger Roots [v50]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <jORjq44RdJeePfSqqKZBNiJO5r004QoG3CxkdsA_TXc=.39c552a8-7d99-4c70-87bd-b6d5b5e7d181@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  A zero root's shift can't be excluded

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/bbf58d5e..d6f4f0de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=49
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=48-49

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From duke at openjdk.org  Sun Jul 27 08:40:56 2025
From: duke at openjdk.org (fabioromano1)
Date: Sun, 27 Jul 2025 08:40:56 GMT
Subject: RFR: 8077587: BigInteger Roots [v50]
In-Reply-To: <jORjq44RdJeePfSqqKZBNiJO5r004QoG3CxkdsA_TXc=.39c552a8-7d99-4c70-87bd-b6d5b5e7d181@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <jORjq44RdJeePfSqqKZBNiJO5r004QoG3CxkdsA_TXc=.39c552a8-7d99-4c70-87bd-b6d5b5e7d181@github.com>
Message-ID: <sX7-WbAzqZOmcDn2mxAgEt7aOyJESC1U-9Vq--GD8Uk=.6e8f0921-0b4f-4568-ad9d-8848b8911bf8@github.com>

On Sun, 27 Jul 2025 07:56:59 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A zero root's shift can't be excluded

@rgiulietti What do you think about it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2233866616

From duke at openjdk.org  Sun Jul 27 10:25:54 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 27 Jul 2025 10:25:54 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v3]
In-Reply-To: <YgNYs5M1Ys2vCTQ5KZpC7ndV3aIDSf-j_GODF3by2ZA=.1a2dc1cb-155c-4ad8-b800-167baa3533c4@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
 <jVLO3nEjKz0T_0TBR-pRqQoA-QckJHFouSlGaah8uW8=.a3dcce0a-8582-4727-8645-f44a69c73205@github.com>
 <YgNYs5M1Ys2vCTQ5KZpC7ndV3aIDSf-j_GODF3by2ZA=.1a2dc1cb-155c-4ad8-b800-167baa3533c4@github.com>
Message-ID: <uJLlYCgzwC0iQI4LWU50dR2Z8hdbxQZIYB-UY-idpfg=.0485aaad-2c8d-4dbd-b511-5891a631b567@github.com>

On Sat, 26 Jul 2025 14:21:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> please first subscribe to that mailing list https://mail.openjdk.org/mailman/listinfo/core-libs-dev

Does this mailing list system require us to subscribe the list to post a new mail to the list? I would like to leave it at least after this PR is merged because I would not like my mailbox to be messed up by emails not related to this change.

> The addition to CharSequence will require static analysis to check for conflicts with implementation. It will also likely impact the CharBuffer spec.

The title of the JBS issue seems to be changed by you but it looks like the default method for `CharSequence` should be stripped for this time according to your concerns. No `codePointCount` methods have been added to `CharSequence` so it may be too early for us to add one to `CharSequence`. Do you think that you should replace `CharSequence` in the title with another class name?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3124289446

From duke at openjdk.org  Sun Jul 27 12:40:03 2025
From: duke at openjdk.org (Philippe Marschall)
Date: Sun, 27 Jul 2025 12:40:03 GMT
Subject: RFR: 8362893: Improve performance for MemorySegment::getString
Message-ID: <2Ylzaqh6EGpyeUXRRXrrDizXVqCghqobGmDHYEiTy0A=.078ad8e4-9eca-4ab6-86cd-60bf8b894201@github.com>

Use `JavaLangAccess::uncheckedNewStringNoRepl` in `MemorySegment::getString` to avoid byte[] allocation in the String constructor.

Fall back to the old code in the case of malformed input to get replacement characters as per Javadoc API specification. The existing tests in `TestStringEncoding` seem sufficient to me.

I ran the tier1 test suite and it passes.

For performance analysis I ran.

    make test TEST="micro:org.openjdk.bench.java.lang.foreign.ToJavaStringTest" MICRO="OPTIONS=-prof gc"

on an AMD Ryzen 7 PRO 5750GE.

These are the formatted results, the current master is the line on top, this feature branch is the line below. We can see an improvement in throughput driven by a reduction in allocation.


Benchmark                                              (size)  Mode  Cnt     Score    Error   Units

ToJavaStringTest.panama_readString                          5  avgt   30    18.996 ?  0.044   ns/op
ToJavaStringTest.panama_readString                          5  avgt   30    13.851 ?  0.028   ns/op

ToJavaStringTest.panama_readString                         20  avgt   30    23.570 ?  0.050   ns/op
ToJavaStringTest.panama_readString                         20  avgt   30    18.401 ?  0.069   ns/op

ToJavaStringTest.panama_readString                        100  avgt   30    32.094 ?  0.207   ns/op
ToJavaStringTest.panama_readString                        100  avgt   30    24.427 ?  0.112   ns/op

ToJavaStringTest.panama_readString                        200  avgt   30    43.029 ?  0.185   ns/op
ToJavaStringTest.panama_readString                        200  avgt   30    31.914 ?  0.064   ns/op

ToJavaStringTest.panama_readString                        451  avgt   30    81.145 ?  0.403   ns/op
ToJavaStringTest.panama_readString                        451  avgt   30    58.975 ?  0.233   ns/op

ToJavaStringTest.panama_readString:gc.alloc.rate.norm       5  avgt   30    72.000 ?  0.001    B/op
ToJavaStringTest.panama_readString:gc.alloc.rate.norm       5  avgt   30    48.000 ?  0.001    B/op

ToJavaStringTest.panama_readString:gc.alloc.rate.norm      20  avgt   30   104.000 ?  0.001    B/op
ToJavaStringTest.panama_readString:gc.alloc.rate.norm      20  avgt   30    64.000 ?  0.001    B/op

ToJavaStringTest.panama_readString:gc.alloc.rate.norm     100  avgt   30   264.000 ?  0.001    B/op
ToJavaStringTest.panama_readString:gc.alloc.rate.norm     100  avgt   30   144.000 ?  0.001    B/op

ToJavaStringTest.panama_readString:gc.alloc.rate.norm     200  avgt   30   456.001 ?  0.001    B/op
ToJavaStringTest.panama_readString:gc.alloc.rate.norm     200  avgt   30   240.000 ?  0.001    B/op

ToJavaStringTest.panama_readString:gc.alloc.rate.norm     451  avgt   30   968.001 ?  0.001    B/op
ToJavaStringTest.panama_readString:gc.alloc.rate.norm     451  avgt   30   496.001 ?  0.001    B/op


I looked into whether there are inlining issues with the current or proposed code. For this I ran


var segment = MemorySegment.ofArray(new byte[] {'c', 'o', 'f', 'f', 'e', 'e', ' ', 'b', 'a', 'b', 'e', 0});
for (int i = 0; i < 200_000_000; i++) {
  var string = segment.getString(0);
  if (System.identityHashCode(string) == 1) {
    System.out.println("x");
   }
}


with `-XX:+PrintCompilation -XX:+PrintInlining -XX:+UnlockDiagnosticVMOptions `

for the current master the simplified output is like this


@ 75   jdk.internal.foreign.AbstractMemorySegmentImpl::getString (9 bytes)   force inline by annotation   callee changed to  help.GetString::main (107 bytes)    -> TypeProfile (95646/95646 counts) = jdk/internal/foreign/HeapMemorySegmentImpl$OfByte
  @ 5   jdk.internal.foreign.AbstractMemorySegmentImpl::getString (12 bytes)   force inline by annotation
    @ 1   java.util.Objects::requireNonNull (14 bytes)   force inline by annotation
    @ 8   jdk.internal.foreign.StringSupport::read (67 bytes)   force inline by annotation
      @ 1   jdk.internal.foreign.StringSupport$CharsetKind::of (102 bytes)   inline (hot)
      @ 4   java.lang.Enum::ordinal (5 bytes)   accessor
      @ 45   jdk.internal.foreign.StringSupport::readByte (41 bytes)   force inline by annotation
        @ 3   jdk.internal.foreign.AbstractMemorySegmentImpl::byteSize (5 bytes)   accessor
        @ 6   jdk.internal.foreign.StringSupport::strlenByte (232 bytes)   force inline by annotation
          <snip>
        @ 27   java.lang.foreign.MemorySegment::copy (29 bytes)   force inline by annotation
          <snip>
        @ 37   java.lang.String::<init> (16 bytes)   inline (hot)
          @ 2   java.util.Objects::requireNonNull (14 bytes)   force inline by annotation
          @ 12   java.lang.String::<init> (86 bytes)   inline (hot)
            @ 23   java.lang.String::utf8 (271 bytes)   inline (hot)
              @ 9   java.lang.StringCoding::countPositives (33 bytes)   (intrinsic)
              @ 27   java.util.Arrays::copyOfRange (82 bytes)   inline (hot)
                @ 11   java.lang.Object::clone (0 bytes)   failed to inline: native method   (intrinsic)
              @ 31   java.lang.String::<init> (15 bytes)   inline (hot)
                @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
            @ 82   java.lang.String::<init> (37 bytes)   inline (hot)
              @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)


As we can see everything is inlined but since `String::utf8` explicitly asks for a copy of the `byte[]` https://github.com/openjdk/jdk/blob/3263361a28c7e8c02734cb94bc9576e9f3ba5b50/src/java.base/share/classes/java/lang/String.java#L575 this can not be optimized away.

This is the compliation log with the proposed changes


@ 75   jdk.internal.foreign.AbstractMemorySegmentImpl::getString (9 bytes)   force inline by annotation   callee changed to  help.GetString::main (107 bytes)    -> TypeProfile (121249/121249 counts) = jdk/internal/foreign/HeapMemorySegmentImpl$OfByte
  @ 5   jdk.internal.foreign.AbstractMemorySegmentImpl::getString (12 bytes)   force inline by annotation
    @ 1   java.util.Objects::requireNonNull (14 bytes)   force inline by annotation
    @ 8   jdk.internal.foreign.StringSupport::read (67 bytes)   force inline by annotation
      @ 1   jdk.internal.foreign.StringSupport$CharsetKind::of (102 bytes)   inline (hot)
      @ 4   java.lang.Enum::ordinal (5 bytes)   accessor
      @ 45   jdk.internal.foreign.StringSupport::readByte (55 bytes)   force inline by annotation
        @ 3   jdk.internal.foreign.AbstractMemorySegmentImpl::byteSize (5 bytes)   accessor
        @ 6   jdk.internal.foreign.StringSupport::strlenByte (232 bytes)   force inline by annotation
          <snip>
        @ 27   java.lang.foreign.MemorySegment::copy (29 bytes)   force inline by annotation
          <snip>
        @ 36   java.lang.System$1::uncheckedNewStringNoRepl (6 bytes)   inline (hot)
          @ 2   java.lang.String::newStringNoRepl (33 bytes)   inline (hot)
            @ 2   java.lang.String::newStringNoRepl1 (284 bytes)   inline (hot)
              @ 22   java.lang.String::newStringUTF8NoRepl (322 bytes)   inline (hot)
                @ 4   java.lang.String::checkBoundsOffCount (10 bytes)   inline (hot)
                  @ 6   jdk.internal.util.Preconditions::checkFromIndexSize (25 bytes)   inline (hot)
                @ 24   java.lang.StringCoding::countPositives (33 bytes)   (intrinsic)
                @ 73   java.lang.String::<init> (15 bytes)   inline (hot)
                  @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)


everything still inlines even though some methods are larger.

-------------

Commit messages:
 - 8362893: Improve performance for MemorySegment::getString

Changes: https://git.openjdk.org/jdk/pull/26493/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26493&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362893
  Stats: 19 lines in 1 file changed: 16 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26493.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26493/head:pull/26493

PR: https://git.openjdk.org/jdk/pull/26493

From alanb at openjdk.org  Sun Jul 27 15:21:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 27 Jul 2025 15:21:55 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v3]
In-Reply-To: <uJLlYCgzwC0iQI4LWU50dR2Z8hdbxQZIYB-UY-idpfg=.0485aaad-2c8d-4dbd-b511-5891a631b567@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
 <jVLO3nEjKz0T_0TBR-pRqQoA-QckJHFouSlGaah8uW8=.a3dcce0a-8582-4727-8645-f44a69c73205@github.com>
 <YgNYs5M1Ys2vCTQ5KZpC7ndV3aIDSf-j_GODF3by2ZA=.1a2dc1cb-155c-4ad8-b800-167baa3533c4@github.com>
 <uJLlYCgzwC0iQI4LWU50dR2Z8hdbxQZIYB-UY-idpfg=.0485aaad-2c8d-4dbd-b511-5891a631b567@github.com>
Message-ID: <O6vQUNsWJWeIo1PtkdJMarykqjebOV2Ve_BWIcBCvW0=.32fdb615-0bc6-43cb-80d3-25b57838a7d6@github.com>

On Sun, 27 Jul 2025 10:23:03 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> No `codePointCount` methods have been added to `CharSequence` so it may be too early for us to add one to `CharSequence`. Do you think that you should replace `CharSequence` in the title with another class name?

Can you clarify what you mean? Right now your PR is proposing to add a default method named codePointCount to CharSequence.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3124488657

From brett.okken.os at gmail.com  Sun Jul 27 20:45:46 2025
From: brett.okken.os at gmail.com (Brett Okken)
Date: Sun, 27 Jul 2025 15:45:46 -0500
Subject: String encodeUTF8 latin1 with negatives
Message-ID: <CANBJVOFLAWc_XqqT9vK4m4F6UG6_My3QsrBqgo+odz3gih7OrQ@mail.gmail.com>

In String.encodeUTF8, when the coder is latin1, there is a call to
StringCoding.hasNegatives to determine if any special handling is needed.
If not, a clone of the val is returned.
If there are negative values, it then loops, from the beginning, through
all the values to handle any individual negative values.

Would it be better to call StringCoding.countPositives? If the result
equals the length, the clone can still be returned. But if it does not, all
the values which are positive can be simply copied to the target byte[] and
only values beyond that point need to be checked again.

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L1287-L1300

        if (!StringCoding.hasNegatives(val, 0, val.length)) {
            return val.clone();
        }

        int dp = 0;
        byte[] dst = StringUTF16.newBytesFor(val.length);
        for (byte c : val) {
            if (c < 0) {
                dst[dp++] = (byte) (0xc0 | ((c & 0xff) >> 6));
                dst[dp++] = (byte) (0x80 | (c & 0x3f));
            } else {
                dst[dp++] = c;
            }
        }


Can be changed to look like:

        int positives = StringCoding.countPositives(val, 0, val.length);
        if (positives == val.length) {
            return val.clone();
        }

        int dp = positives;
        byte[] dst = StringUTF16.newBytesFor(val.length);
        if (positives > 0) {
            System.arraycopy(val, 0, dst, 0, positives);
        }
        for (int i=dp; i<val.length; ++i) {
            byte c = val[i];
            if (c < 0) {
                dst[dp++] = (byte) (0xc0 | ((c & 0xff) >> 6));
                dst[dp++] = (byte) (0x80 | (c & 0x3f));
            } else {
                dst[dp++] = c;
            }
        }



I have done a bit of testing with the StringEncode jmh benchmark on my
local windows device.

encodeLatin1LongEnd speeds up significantly (~70%)
encodeLatin1LongStart slows down (~20%)
encodeLatin1Mixed speeds up by ~30%

The remaining tests do not show much difference either way.

Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250727/1907c5d5/attachment.htm>

From duke at openjdk.org  Sun Jul 27 22:17:34 2025
From: duke at openjdk.org (fabioromano1)
Date: Sun, 27 Jul 2025 22:17:34 GMT
Subject: RFR: 8077587: BigInteger Roots [v51]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <Kzy8-Uc-2KOwswPVqLgG9S6Z_0LQRzVgnfhySfIvBSI=.83c479cb-566c-45b7-a01a-0676675ed6bb@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Minor changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/d6f4f0de..7cc53750

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=50
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=49-50

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From duke at openjdk.org  Sun Jul 27 22:17:34 2025
From: duke at openjdk.org (Thomas Zimmermann)
Date: Sun, 27 Jul 2025 22:17:34 GMT
Subject: RFR: 8077587: BigInteger Roots [v50]
In-Reply-To: <jORjq44RdJeePfSqqKZBNiJO5r004QoG3CxkdsA_TXc=.39c552a8-7d99-4c70-87bd-b6d5b5e7d181@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <jORjq44RdJeePfSqqKZBNiJO5r004QoG3CxkdsA_TXc=.39c552a8-7d99-4c70-87bd-b6d5b5e7d181@github.com>
Message-ID: <7WhtiCwHeX5nMLwZ1OYLPe4E-Dx7x3P9QwRrxfTL2ck=.d1183665-b780-4820-9613-20e52fbc7a07@github.com>

On Sun, 27 Jul 2025 07:56:59 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A zero root's shift can't be excluded

src/java.base/share/classes/java/math/BigInteger.java line 2773:

> 2771:      */
> 2772:     public BigInteger nthRoot(int n) {
> 2773:         return n == 1 ? this : (n == 2 ? sqrt() : nthRootAndRemainder(n, false)[0]);

I'm not a reviewer, but I noticed that inlining the `needRemainder`-flag into the callers arguably yields clearer flow, obviates the "Assume n != 1 && n != 2" javadoc and removes the array allocation for `nthRoot`:


    public BigInteger nthRoot(int n) {
        if (n == 1)
            return this;

        if (n == 2)
            return sqrt();

        checkNthRoot(n);
        MutableBigInteger[] rootRem = new MutableBigInteger(this.mag).nthRootRem(n);
        return rootRem[0].toBigInteger(signum);
    }

    public BigInteger[] nthRootAndRemainder(int n) {
        if (n == 1)
            return new BigInteger[] { this, ZERO };

        if (n == 2)
            return sqrtAndRemainder();

        checkNthRoot(n);
        MutableBigInteger[] rootRem = new MutableBigInteger(this.mag).nthRootRem(n);
        return new BigInteger[] {
                rootRem[0].toBigInteger(signum),
                rootRem[1].toBigInteger(signum)
        };
    }

    private static void checkNthRoot(int n) {
        if (n <= 0)
            throw new ArithmeticException("Non-positive root degree");

        if ((n & 1) == 0 && this.signum < 0)
            throw new ArithmeticException("Negative radicand with even root degree");
    }


What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2233863415

From duke at openjdk.org  Sun Jul 27 23:07:57 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 27 Jul 2025 23:07:57 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v3]
In-Reply-To: <O6vQUNsWJWeIo1PtkdJMarykqjebOV2Ve_BWIcBCvW0=.32fdb615-0bc6-43cb-80d3-25b57838a7d6@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
 <jVLO3nEjKz0T_0TBR-pRqQoA-QckJHFouSlGaah8uW8=.a3dcce0a-8582-4727-8645-f44a69c73205@github.com>
 <YgNYs5M1Ys2vCTQ5KZpC7ndV3aIDSf-j_GODF3by2ZA=.1a2dc1cb-155c-4ad8-b800-167baa3533c4@github.com>
 <uJLlYCgzwC0iQI4LWU50dR2Z8hdbxQZIYB-UY-idpfg=.0485aaad-2c8d-4dbd-b511-5891a631b567@github.com>
 <O6vQUNsWJWeIo1PtkdJMarykqjebOV2Ve_BWIcBCvW0=.32fdb615-0bc6-43cb-80d3-25b57838a7d6@github.com>
Message-ID: <vCc_NzBwMljkWVQ_sAuTlMYUzdpDizxOqHROFBEqD0k=.7e43b058-1a6f-49bc-b921-810eed05efa1@github.com>

On Sun, 27 Jul 2025 15:19:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Right now your PR is proposing to add a default method named codePointCount to CharSequence.

If it should be excluded for this time, I will push an additional commit to _remove_ it from the content in this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3124780267

From swen at openjdk.org  Mon Jul 28 01:09:09 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 28 Jul 2025 01:09:09 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v8]
In-Reply-To: <YVXgIFUrrJVHUQCTjPB6eUjJGie7U-gTJMZJCkL4Igk=.ad4d5e6d-89c7-43e1-ac92-4a61cf5d369d@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
 <Akc09cL762LAM8tZXqUuyIZiwKyYQpABKjAjjhqjeT0=.eadecf6b-1a3c-4061-8951-537e6e24742c@github.com>
 <YVXgIFUrrJVHUQCTjPB6eUjJGie7U-gTJMZJCkL4Igk=.ad4d5e6d-89c7-43e1-ac92-4a61cf5d369d@github.com>
Message-ID: <Q695EiN8cxxpCrgm2HtWNlZGA_4nfsnrjAFOT_90mbw=.ed5bfee8-2f06-40d2-a919-d8e6c8bc5a65@github.com>

On Sun, 27 Jul 2025 04:37:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringUTF16.java line 1489:
>> 
>>> 1487:                 Unsafe.ARRAY_CHAR_BASE_OFFSET + ((long) off << 1),
>>> 1488:                 val,
>>> 1489:                 Unsafe.ARRAY_BYTE_BASE_OFFSET + ((long) index << 1),
>> 
>> Suggestion:
>> 
>>                 Unsafe.ARRAY_BYTE_BASE_OFFSET + ((long) index << 1) * Unsafe.ARRAY_BYTE_INDEX_SCALE,
>
> If we want to use ARRAY_CHAR_INDEX_SCALE, it should be used as follows
> 
>         Unsafe.getUnsafe().copyMemory(
>                 ca,
>                 Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off * Unsafe.ARRAY_CHAR_INDEX_SCALE,
>                 val,
>                 Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off * Unsafe.ARRAY_CHAR_INDEX_SCALE,
>                 (long) (end - off) << 1);

I prefer to calculate an ARRAY_CHAR_SHIFT in the constant like ShortVector does, like this

static final int ARRAY_CHAR_SHIFT 
                   = 31 - Integer.numberOfLeadingZeros(Unsafe.ARRAY_CHAR_INDEX_SCALE);

        Unsafe.getUnsafe().copyMemory(
                ca,
                Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off << ARRAY_CHAR_SHIFT,
                val,
                Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off << ARRAY_CHAR_SHIFT,
                (long) (end - off) << 1);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2234230546

From swen at openjdk.org  Mon Jul 28 01:14:10 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 28 Jul 2025 01:14:10 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v8]
In-Reply-To: <Q695EiN8cxxpCrgm2HtWNlZGA_4nfsnrjAFOT_90mbw=.ed5bfee8-2f06-40d2-a919-d8e6c8bc5a65@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
 <Akc09cL762LAM8tZXqUuyIZiwKyYQpABKjAjjhqjeT0=.eadecf6b-1a3c-4061-8951-537e6e24742c@github.com>
 <YVXgIFUrrJVHUQCTjPB6eUjJGie7U-gTJMZJCkL4Igk=.ad4d5e6d-89c7-43e1-ac92-4a61cf5d369d@github.com>
 <Q695EiN8cxxpCrgm2HtWNlZGA_4nfsnrjAFOT_90mbw=.ed5bfee8-2f06-40d2-a919-d8e6c8bc5a65@github.com>
Message-ID: <nzlwUQNxY2Hp3oRjsWPNMHVzKBlDj9qTkArvQYApFf0=.7af6069d-85cf-4ace-a8dc-6e9f11b800f8@github.com>

On Mon, 28 Jul 2025 01:06:46 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> If we want to use ARRAY_CHAR_INDEX_SCALE, it should be used as follows
>> 
>>         Unsafe.getUnsafe().copyMemory(
>>                 ca,
>>                 Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off * Unsafe.ARRAY_CHAR_INDEX_SCALE,
>>                 val,
>>                 Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off * Unsafe.ARRAY_CHAR_INDEX_SCALE,
>>                 (long) (end - off) << 1);
>
> I prefer to calculate an ARRAY_CHAR_SHIFT in the constant like ShortVector does, like this
> 
> static final int ARRAY_CHAR_SHIFT 
>                    = 31 - Integer.numberOfLeadingZeros(Unsafe.ARRAY_CHAR_INDEX_SCALE);
> 
>         Unsafe.getUnsafe().copyMemory(
>                 ca,
>                 Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off << ARRAY_CHAR_SHIFT,
>                 val,
>                 Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off << ARRAY_CHAR_SHIFT,
>                 (long) (end - off) << 1);

String uses `<< coder` in many places. I think the following way of writing is also good:

        Unsafe.getUnsafe().copyMemory(
                ca,
                Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off << String.UTF16,
                val,
                Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off << String.UTF16,
                (long) (end - off) << 1);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2234242815

From duke at openjdk.org  Mon Jul 28 01:17:54 2025
From: duke at openjdk.org (simon)
Date: Mon, 28 Jul 2025 01:17:54 GMT
Subject: RFR: 8362893: Improve performance for MemorySegment::getString
In-Reply-To: <2Ylzaqh6EGpyeUXRRXrrDizXVqCghqobGmDHYEiTy0A=.078ad8e4-9eca-4ab6-86cd-60bf8b894201@github.com>
References: <2Ylzaqh6EGpyeUXRRXrrDizXVqCghqobGmDHYEiTy0A=.078ad8e4-9eca-4ab6-86cd-60bf8b894201@github.com>
Message-ID: <Tuf079C-mq9q7shmSx6qMTxz7Sk4rD8H2RfT-pbGDUE=.d4bb1da1-68bc-4796-b06c-1986066fb824@github.com>

On Sun, 27 Jul 2025 12:36:20 GMT, Philippe Marschall <duke at openjdk.org> wrote:

> Use `JavaLangAccess::uncheckedNewStringNoRepl` in `MemorySegment::getString` to avoid byte[] allocation in the String constructor.
> 
> Fall back to the old code in the case of malformed input to get replacement characters as per Javadoc API specification. The existing tests in `TestStringEncoding` seem sufficient to me.
> 
> I ran the tier1 test suite and it passes.
> 
> For performance analysis I ran.
> 
>     make test TEST="micro:org.openjdk.bench.java.lang.foreign.ToJavaStringTest" MICRO="OPTIONS=-prof gc"
> 
> on an AMD Ryzen 7 PRO 5750GE.
> 
> These are the formatted results, the current master is the line on top, this feature branch is the line below. We can see an improvement in throughput driven by a reduction in allocation.
> 
> 
> Benchmark                                              (size)  Mode  Cnt     Score    Error   Units
> 
> ToJavaStringTest.panama_readString                          5  avgt   30    18.996 ?  0.044   ns/op
> ToJavaStringTest.panama_readString                          5  avgt   30    13.851 ?  0.028   ns/op
> 
> ToJavaStringTest.panama_readString                         20  avgt   30    23.570 ?  0.050   ns/op
> ToJavaStringTest.panama_readString                         20  avgt   30    18.401 ?  0.069   ns/op
> 
> ToJavaStringTest.panama_readString                        100  avgt   30    32.094 ?  0.207   ns/op
> ToJavaStringTest.panama_readString                        100  avgt   30    24.427 ?  0.112   ns/op
> 
> ToJavaStringTest.panama_readString                        200  avgt   30    43.029 ?  0.185   ns/op
> ToJavaStringTest.panama_readString                        200  avgt   30    31.914 ?  0.064   ns/op
> 
> ToJavaStringTest.panama_readString                        451  avgt   30    81.145 ?  0.403   ns/op
> ToJavaStringTest.panama_readString                        451  avgt   30    58.975 ?  0.233   ns/op
> 
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm       5  avgt   30    72.000 ?  0.001    B/op
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm       5  avgt   30    48.000 ?  0.001    B/op
> 
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm      20  avgt   30   104.000 ?  0.001    B/op
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm      20  avgt   30    64.000 ?  0.001    B/op
> 
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm     100  avgt   30   264.000 ?  0.001    B/op
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm     100  avgt   30   144.000 ?  0.001    B/op
> 
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm     200  avgt ...

src/java.base/share/classes/jdk/internal/foreign/StringSupport.java line 33:

> 31: import jdk.internal.util.Architecture;
> 32: import jdk.internal.util.ArraysSupport;
> 33: import jdk.internal.vm.annotation.ForceInline;

Nitpick: update copyright year ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26493#discussion_r2234248805

From swen at openjdk.org  Mon Jul 28 05:04:54 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 28 Jul 2025 05:04:54 GMT
Subject: RFR: 8362893: Improve performance for MemorySegment::getString
In-Reply-To: <2Ylzaqh6EGpyeUXRRXrrDizXVqCghqobGmDHYEiTy0A=.078ad8e4-9eca-4ab6-86cd-60bf8b894201@github.com>
References: <2Ylzaqh6EGpyeUXRRXrrDizXVqCghqobGmDHYEiTy0A=.078ad8e4-9eca-4ab6-86cd-60bf8b894201@github.com>
Message-ID: <fMCUSc5XN29p0xsrgYnzmuLN6NVC2VPyKW2eWSN-XGg=.7aef213a-5ea1-4482-8064-887e4a0c7bf5@github.com>

On Sun, 27 Jul 2025 12:36:20 GMT, Philippe Marschall <duke at openjdk.org> wrote:

> Use `JavaLangAccess::uncheckedNewStringNoRepl` in `MemorySegment::getString` to avoid byte[] allocation in the String constructor.
> 
> Fall back to the old code in the case of malformed input to get replacement characters as per Javadoc API specification. The existing tests in `TestStringEncoding` seem sufficient to me.
> 
> I ran the tier1 test suite and it passes.
> 
> For performance analysis I ran.
> 
>     make test TEST="micro:org.openjdk.bench.java.lang.foreign.ToJavaStringTest" MICRO="OPTIONS=-prof gc"
> 
> on an AMD Ryzen 7 PRO 5750GE.
> 
> These are the formatted results, the current master is the line on top, this feature branch is the line below. We can see an improvement in throughput driven by a reduction in allocation.
> 
> 
> Benchmark                                              (size)  Mode  Cnt     Score    Error   Units
> 
> ToJavaStringTest.panama_readString                          5  avgt   30    18.996 ?  0.044   ns/op
> ToJavaStringTest.panama_readString                          5  avgt   30    13.851 ?  0.028   ns/op
> 
> ToJavaStringTest.panama_readString                         20  avgt   30    23.570 ?  0.050   ns/op
> ToJavaStringTest.panama_readString                         20  avgt   30    18.401 ?  0.069   ns/op
> 
> ToJavaStringTest.panama_readString                        100  avgt   30    32.094 ?  0.207   ns/op
> ToJavaStringTest.panama_readString                        100  avgt   30    24.427 ?  0.112   ns/op
> 
> ToJavaStringTest.panama_readString                        200  avgt   30    43.029 ?  0.185   ns/op
> ToJavaStringTest.panama_readString                        200  avgt   30    31.914 ?  0.064   ns/op
> 
> ToJavaStringTest.panama_readString                        451  avgt   30    81.145 ?  0.403   ns/op
> ToJavaStringTest.panama_readString                        451  avgt   30    58.975 ?  0.233   ns/op
> 
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm       5  avgt   30    72.000 ?  0.001    B/op
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm       5  avgt   30    48.000 ?  0.001    B/op
> 
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm      20  avgt   30   104.000 ?  0.001    B/op
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm      20  avgt   30    64.000 ?  0.001    B/op
> 
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm     100  avgt   30   264.000 ?  0.001    B/op
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm     100  avgt   30   144.000 ?  0.001    B/op
> 
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm     200  avgt ...

This optimization is not only needed within the JDK core library, but also by developers of basic class libraries and applications. This should be done by the C2 optimizer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26493#issuecomment-3125494530

From jbhateja at openjdk.org  Mon Jul 28 05:55:55 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 28 Jul 2025 05:55:55 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v2]
In-Reply-To: <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <qYktkjLtWr3FZZP-6N9zAegRIq_vf6JAcMIPZh1gRyA=.0b73a0f0-54cb-4315-90fb-8da02ff7f0aa@github.com>
Message-ID: <oduPnBt3gdTm9KsT-KUdoETpBGgX1JXbVxr6qEWK5CE=.6df7c181-0b37-4d24-9a99-aa158198f2d8@github.com>

On Fri, 25 Jul 2025 20:09:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction.
>> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails.
>> 
>>  Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java).
>> 
>> Vector API jtreg tests pass at AVX level 2, remaining validation in progress.
>> 
>> Performance numbers:
>> 
>> 
>> System : 13th Gen Intel(R) Core(TM) i3-1315U
>> 
>> Baseline:
>> Benchmark                                                (size)   Mode  Cnt      Score   Error   Units
>> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    2   9444.444          ops/ms
>> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    2  10009.319          ops/ms
>> VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    2   9081.926          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    2   6085.825          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    2   6505.378          ops/ms
>> VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6204.489          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2   1651.334          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    2   1642.784          ops/ms
>> VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    2   1474.808          ops/ms
>> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    2  10399.394          ops/ms
>> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    2  10502.894          ops/ms
>> VectorSliceB...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating predicate checks

Performance on AVX512 machine


Baseline:
Benchmark                                                (size)   Mode  Cnt      Score       Error   Units
VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt    4  35741.780 ?  1561.065  ops/ms
VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt    4  35011.929 ?  5886.902  ops/ms
VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt    4  32366.844 ?  1489.449  ops/ms
VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt    4  10636.281 ?   608.705  ops/ms
VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt    4  10750.833 ?   328.997  ops/ms
VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    4  10257.338 ?  2027.422  ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    4   5362.330 ?  4199.651  ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt    4   4992.399 ?  6053.641  ops/ms
VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt    4   4941.258 ?   478.193  ops/ms
VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt    4  40432.828 ? 26672.673  ops/ms
VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt    4  41300.811 ? 34342.482  ops/ms
VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024  thrpt    4  36958.309 ?  1899.676  ops/ms

Withopt:
Benchmark                                                (size)   Mode  Cnt      Score       Error   Units
VectorSliceBenchmark.byteVectorSliceWithConstantIndex1     1024  thrpt   10  67936.711 ?   389.783  ops/ms
VectorSliceBenchmark.byteVectorSliceWithConstantIndex2     1024  thrpt   10  70086.731 ?  5972.968  ops/ms
VectorSliceBenchmark.byteVectorSliceWithVariableIndex      1024  thrpt   10  31879.187 ?   148.213  ops/ms
VectorSliceBenchmark.intVectorSliceWithConstantIndex1      1024  thrpt   10  17676.883 ?   217.238  ops/ms
VectorSliceBenchmark.intVectorSliceWithConstantIndex2      1024  thrpt   10  16983.007 ?  3988.548  ops/ms
VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt   10   9851.266 ?    31.773  ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt   10   9194.216 ?    42.772  ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex2     1024  thrpt   10   8411.738 ?    33.209  ops/ms
VectorSliceBenchmark.longVectorSliceWithVariableIndex      1024  thrpt   10   5244.850 ?    12.214  ops/ms
VectorSliceBenchmark.shortVectorSliceWithConstantIndex1    1024  thrpt   10  61233.526 ? 20472.895  ops/ms
VectorSliceBenchmark.shortVectorSliceWithConstantIndex2    1024  thrpt   10  61545.276 ? 20722.066  ops/ms
VectorSliceBenchmark.shortVectorSliceWithVariableIndex     1024  thrpt   10  41208.718 ?  5374.829  ops/ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3125629912

From tschatzl at openjdk.org  Mon Jul 28 09:12:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 28 Jul 2025 09:12:53 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v45]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <XXmA7QD5fE0Dbv8OtC5xjWw3PhHAnmgBqOh0NA_ftf4=.fbf19b93-d6ab-4efb-a6c4-28681595287c@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 62 commits:

 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * remove unused G1DetachedRefinementStats_lock
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into pull/23739
 - 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
 - ... and 52 more: https://git.openjdk.org/jdk/compare/bdc1ef20...23aa2c8b

-------------

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=44
  Stats: 7123 lines in 112 files changed: 2588 ins; 3593 del; 942 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 alanb at openjdk.org  Mon Jul 28 09:19:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Jul 2025 09:19:05 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v3]
In-Reply-To: <vCc_NzBwMljkWVQ_sAuTlMYUzdpDizxOqHROFBEqD0k=.7e43b058-1a6f-49bc-b921-810eed05efa1@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
 <jVLO3nEjKz0T_0TBR-pRqQoA-QckJHFouSlGaah8uW8=.a3dcce0a-8582-4727-8645-f44a69c73205@github.com>
 <YgNYs5M1Ys2vCTQ5KZpC7ndV3aIDSf-j_GODF3by2ZA=.1a2dc1cb-155c-4ad8-b800-167baa3533c4@github.com>
 <uJLlYCgzwC0iQI4LWU50dR2Z8hdbxQZIYB-UY-idpfg=.0485aaad-2c8d-4dbd-b511-5891a631b567@github.com>
 <O6vQUNsWJWeIo1PtkdJMarykqjebOV2Ve_BWIcBCvW0=.32fdb615-0bc6-43cb-80d3-25b57838a7d6@github.com>
 <vCc_NzBwMljkWVQ_sAuTlMYUzdpDizxOqHROFBEqD0k=.7e43b058-1a6f-49bc-b921-810eed05efa1@github.com>
Message-ID: <TY5uV90caTqnIGo-ert8eSswDKqYDctFNpSQ6hPJ6Cw=.447d779f-cce1-472f-b0e2-84babae9bce0@github.com>

On Sun, 27 Jul 2025 23:05:25 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> > Right now your PR is proposing to add a default method named codePointCount to CharSequence.
> 
> If it should be excluded for this time, I will push an additional commit to _remove_ it from the content in this PR.

I think we should mull over the addition of CharSequence::codePointCount. On the surface it looks like it fits but we can't rush it (CharSequence is widely implemented and additions to this interface have a history of disruption in the eco system).

What is the reason for proposing Character.codePointCount(CharSequence) aswell?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3126308040

From vyazici at openjdk.org  Mon Jul 28 09:36:00 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 28 Jul 2025 09:36:00 GMT
Subject: RFR: 8361842: Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v13]
In-Reply-To: <t16yfpAYjX9Wm_qw-kEX4IGPsvv9KRyMudtRbGK7UZY=.30a8ab28-15b0-45f6-a0aa-aba54e387106@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <t16yfpAYjX9Wm_qw-kEX4IGPsvv9KRyMudtRbGK7UZY=.30a8ab28-15b0-45f6-a0aa-aba54e387106@github.com>
Message-ID: <7pEtXtLj_rHcJb_-M1FNge1GhM48UoW0ZMHhI44HH-w=.5401889c-3613-4cc6-aef6-52266066b821@github.com>

On Fri, 25 Jul 2025 07:40:46 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 IR or assembly code, and adapt them to cause VM crash on invalid input.
>> 
>> ## Implementation notes
>> 
>> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes,
>> 
>> 1. Move `@IntrinsicCandidate`-annotated `public` 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...
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 31 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Replace `requireNonNull` with implicit null checks to reduce bytecode size
>  - Add `@bug` tags
>  - Improve wording of `@param len`
>  - Make source array bound checks lenient too
>  - Cap destination array bounds
>  - Fix bit shifting
>  - Remove superseded `@throws` Javadoc
>  - Merge remote-tracking branch 'upstream/master' into strIntrinCheck
>  - Make `StringCoding` encoding intrinsics lenient
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/8888d41d...c322f0e0

Status update:

* Changes are pretty-much settled. I'm waiting for a final review from @cl4es.
* Checked the performance impact of changes against [DaCapo](https://www.dacapobench.org/) BioJava, and `org.openjdk.bench.java.lang.String{En,De}code` benchmarks on several platforms. Spotted one consistent significant (i.e., >2%) regression: `StringDecode::decodeShortMixed` ? explicitly forcing inlining<sup>1</sup> did not help either. Granted this is the only, and benchmark- and platform-specific regression, @RogerRiggs suggested creating a follow-up ticket for this particular regression and integrating this PR. I will wait for input from @cl4es.

<sup>1</sup> `-XX:CompileCommand=inline,java.lang.StringCoding::encodeISOArray -XX:CompileCommand=inline,java.lang.StringCoding::encodeAsciiArray`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3126372979

From vyazici at openjdk.org  Mon Jul 28 09:47:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 28 Jul 2025 09:47:04 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <Y55-lbbFBZEzGNqlIn4LTWLsW22B_KhakQVJD0eEaLI=.798762d3-b450-4215-afc7-13882758cc96@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <Y55-lbbFBZEzGNqlIn4LTWLsW22B_KhakQVJD0eEaLI=.798762d3-b450-4215-afc7-13882758cc96@github.com>
Message-ID: <abFTzVczJjF1TbG3euS56RNLSkDGuU6vk1FzL4_wp74=.7b208c21-c259-4b7c-97c3-1be4e41cdcd4@github.com>

On Mon, 21 Jul 2025 13:01:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)
>
> I strongly suggest against using CCE as the standard exception. The only place that relies on CCE is `Files`; IAE is more suitable for everywhere else. I recommend adding the special CCE handling in `Files` alone so we can remove the redundant try-catch everywhere else.

@liach, thanks so much for the prompt feedback!

> I strongly suggest against using CCE as the standard exception.

Would you mind elaborating on the rationale behind this preference, please?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26413#issuecomment-3096905451

From liach at openjdk.org  Mon Jul 28 09:47:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Jul 2025 09:47:05 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <abFTzVczJjF1TbG3euS56RNLSkDGuU6vk1FzL4_wp74=.7b208c21-c259-4b7c-97c3-1be4e41cdcd4@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <Y55-lbbFBZEzGNqlIn4LTWLsW22B_KhakQVJD0eEaLI=.798762d3-b450-4215-afc7-13882758cc96@github.com>
 <abFTzVczJjF1TbG3euS56RNLSkDGuU6vk1FzL4_wp74=.7b208c21-c259-4b7c-97c3-1be4e41cdcd4@github.com>
Message-ID: <5A1iktExyQTToHYQrz_0fGc6Uz-psGD4aGlUFcLtryM=.227fc254-37a6-4a48-b550-5c35ec349848@github.com>

On Mon, 21 Jul 2025 14:00:37 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Would you mind elaborating on the rationale behind this preference, please?

If you look at the history of `newStringNoRepl`, you will find it's originally added for JDK-8201276 in ca487166f4d18c162e8d8e4b2660d5d0381c5438. Since then, `newStringNoRepl` has been used by various other sites mostly as a utility. None of those further usages ever used the `CharacterCodingException`. In fact, in `String`, the actual implementation throws an IAE that is later wrapped in a CCE. I don't think we should punish all other users of this API just because `Files.readString` requires this CCE; the CCE wrapping can be moved to Files.readString.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26413#issuecomment-3097079813

From vyazici at openjdk.org  Mon Jul 28 09:47:03 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 28 Jul 2025 09:47:03 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
Message-ID: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>

`NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)

-------------

Commit messages:
 - Replace `requireNonNull` with implicit null checks
 - Merge remote-tracking branch 'upstream/master' into jlaNoRepl
 - Improve docs of touched methods and add NPE checks
 - Convert IAE-throwing methods into CCE-throwing ones
 - Rename `JavaLangAccess::*NoRepl` methods

Changes: https://git.openjdk.org/jdk/pull/26413/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26413&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356439
  Stats: 193 lines in 10 files changed: 82 ins; 34 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/26413.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26413/head:pull/26413

PR: https://git.openjdk.org/jdk/pull/26413

From liach at openjdk.org  Mon Jul 28 09:47:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Jul 2025 09:47:04 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
Message-ID: <Y55-lbbFBZEzGNqlIn4LTWLsW22B_KhakQVJD0eEaLI=.798762d3-b450-4215-afc7-13882758cc96@github.com>

On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)

I strongly suggest against using CCE as the standard exception. The only place that relies on CCE is `Files`; IAE is more suitable for everywhere else. I recommend adding the special CCE handling in `Files` alone so we can remove the redundant try-catch everywhere else.

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 328:

> 326:      * @throws CharacterCodingException for malformed or unmappable bytes
> 327:      */
> 328:     String uncheckedNewString(byte[] bytes, Charset cs) throws CharacterCodingException;

The docs should mention these two details:
1. This method does not replace upon malformed data but fails
2. This method does not copy the byte array for validation (can add to the warning)

-------------

Changes requested by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26413#pullrequestreview-3038008799
PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2219148757

From alanb at openjdk.org  Mon Jul 28 09:47:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Jul 2025 09:47:05 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
Message-ID: <PrrQBBv9ZvnJlAxL-e_E8J2LbMz6RVMO9XE2VYQogzI=.ad7b63f3-520f-49cd-85bc-56e35d44f733@github.com>

On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)

newStringNoRepl has confused several maintainers as it's not immediately obvious that it means "no replace", or more specifically CodingErrorAction.REPORT behavior. So it's good to see this getting attention.

Anyone working on String expects CodingErrorAction.REPLACE behavior so having String methods use methods that don't throw would feel right.

There are "far away" APIs, Files.readXXX was mentioned, that require CodingErrorAction.REPORT behavior methods so having JLA methods throw CharacterCodingException is helpful. 

There are other far away APIs such as UUID and ZipCoder that specify a Charset and know that no exception will be throw. They want CodingErrorAction.REPORT behavior except that it's a bug if CharacterCodingException is thrown. These cases catch CCE and throw AssertionError, which is okay, and hopefully we have enough tests in all these area to ensure that it doesn't happen.

Anyway, from a first read of the changes then I think we need to make sure that the method descriptions are accurate. There are several places where "IAE" is mentioned but the methods are changed to throw CCE.  IAE is awkward in this area because throwing it, instead of CCE, makes it difficult to know if the handling is correct. There is constant code churn in this area and too easy to introduce a regression and "unexpected exception" if IAE is used to in place of a CharacterCodingException. 

Another high level comment from a first read is that it feels like there are two forms needed. One form is REPLACE action and doesn't throw. The other is REPORT action and throws CharacterCodingException. That is what we have already, it's just the naming is awkward.  So it may be that it's more about finding good names so that it's clear from all the use sites.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26413#issuecomment-3103589181

From vyazici at openjdk.org  Mon Jul 28 09:47:05 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 28 Jul 2025 09:47:05 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <PrrQBBv9ZvnJlAxL-e_E8J2LbMz6RVMO9XE2VYQogzI=.ad7b63f3-520f-49cd-85bc-56e35d44f733@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <PrrQBBv9ZvnJlAxL-e_E8J2LbMz6RVMO9XE2VYQogzI=.ad7b63f3-520f-49cd-85bc-56e35d44f733@github.com>
Message-ID: <2ljiZ6ehU1zSgacWy0c58GV-AbU4ATDh40BWTufiWh4=.8f8ca1d6-89df-4b22-a261-4b493f4266f4@github.com>

On Tue, 22 Jul 2025 16:03:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There are several places where "IAE" is mentioned but the methods are changed to throw CCE.

@AlanBateman, thanks for the tip. Pushed 10cb72cf17b, which improves Javadoc in such places. While doing so, it also

* Ensures that `String` Javadoc matches the one shared in `JavaLangAccess`
* Adds some missing(?) `requireNonNull` checks, and documents them as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26413#issuecomment-3112627244

From vyazici at openjdk.org  Mon Jul 28 09:47:06 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 28 Jul 2025 09:47:06 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
Message-ID: <UA0pGbsuzu3uVXQiMX6bXjQOdbpmnAhVOyR1tuk5mEo=.327cbc19-fd65-40af-89a0-fd19c65d4672@github.com>

On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)

src/java.base/share/classes/java/lang/String.java line 1262:

> 1260:         MalformedInputException mie = new MalformedInputException(nb);
> 1261:         String msg = "malformed input off : " + off + ", length : " + nb;
> 1262:         mie.initCause(new IllegalArgumentException(msg));

Earlier `throw(Malformed|Unmappable)` methods were throwing `IAE` containing _extra diagnostics information_ and wrapping a `CCE` as a cause. After switching methods to throw `CCE`, which doesn't have a ctor accepting a `String` message, to retain this extra diagnostics information, I've added swapped their causal chain placement, and wrapped `IAE` with a `CCE` this time.

This played well with `CCE`-throwing methods, yet there are other `public` methods which did not have `throws CCE` in their footprint. For backward compatibility, in those spots, I've used `cce2iae` to obtain, again, a `IAE` wrapping the `CCE`, which matched the old behavior.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2219032735

From rgiulietti at openjdk.org  Mon Jul 28 12:21:59 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 28 Jul 2025 12:21:59 GMT
Subject: RFR: 8077587: BigInteger Roots [v50]
In-Reply-To: <7WhtiCwHeX5nMLwZ1OYLPe4E-Dx7x3P9QwRrxfTL2ck=.d1183665-b780-4820-9613-20e52fbc7a07@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <jORjq44RdJeePfSqqKZBNiJO5r004QoG3CxkdsA_TXc=.39c552a8-7d99-4c70-87bd-b6d5b5e7d181@github.com>
 <7WhtiCwHeX5nMLwZ1OYLPe4E-Dx7x3P9QwRrxfTL2ck=.d1183665-b780-4820-9613-20e52fbc7a07@github.com>
Message-ID: <cuNeE9dhUb1aPjiNhKwwuudsYioy5OHIgyAoitaYuHQ=.8c9d0bef-934d-448e-9c69-8a963714f0d1@github.com>

On Sun, 27 Jul 2025 08:26:59 GMT, Thomas Zimmermann <duke at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   A zero root's shift can't be excluded
>
> src/java.base/share/classes/java/math/BigInteger.java line 2773:
> 
>> 2771:      */
>> 2772:     public BigInteger nthRoot(int n) {
>> 2773:         return n == 1 ? this : (n == 2 ? sqrt() : nthRootAndRemainder(n, false)[0]);
> 
> I'm not a reviewer, but I noticed that inlining the `needRemainder`-flag into the callers arguably yields clearer flow, obviates the "Assume n != 1 && n != 2" javadoc and removes the array allocation for `nthRoot`:
> 
> 
>     public BigInteger nthRoot(int n) {
>         if (n == 1)
>             return this;
> 
>         if (n == 2)
>             return sqrt();
> 
>         checkNthRoot(n);
>         MutableBigInteger[] rootRem = new MutableBigInteger(this.mag).nthRootRem(n);
>         return rootRem[0].toBigInteger(signum);
>     }
> 
>     public BigInteger[] nthRootAndRemainder(int n) {
>         if (n == 1)
>             return new BigInteger[] { this, ZERO };
> 
>         if (n == 2)
>             return sqrtAndRemainder();
> 
>         checkNthRoot(n);
>         MutableBigInteger[] rootRem = new MutableBigInteger(this.mag).nthRootRem(n);
>         return new BigInteger[] {
>                 rootRem[0].toBigInteger(signum),
>                 rootRem[1].toBigInteger(signum)
>         };
>     }
> 
>     private static void checkNthRoot(int n) {
>         if (n <= 0)
>             throw new ArithmeticException("Non-positive root degree");
> 
>         if ((n & 1) == 0 && this.signum < 0)
>             throw new ArithmeticException("Negative radicand with even root degree");
>     }
> 
> 
> What do you think?

@zimmi Since you are reviewing, you _are_ a reviewer ;-), although not an official [Reviewer](https://openjdk.org/bylaws#reviewer).

@zimmi @fabioromano1 I'm fine with this change.
However, I wonder if it might be beneficial to avoid computing the remainder downstream when invoking `nthRoot(int n)`, returning `null` in the array.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2236168671

From duke at openjdk.org  Mon Jul 28 12:30:56 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Mon, 28 Jul 2025 12:30:56 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v3]
In-Reply-To: <TY5uV90caTqnIGo-ert8eSswDKqYDctFNpSQ6hPJ6Cw=.447d779f-cce1-472f-b0e2-84babae9bce0@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
 <jVLO3nEjKz0T_0TBR-pRqQoA-QckJHFouSlGaah8uW8=.a3dcce0a-8582-4727-8645-f44a69c73205@github.com>
 <YgNYs5M1Ys2vCTQ5KZpC7ndV3aIDSf-j_GODF3by2ZA=.1a2dc1cb-155c-4ad8-b800-167baa3533c4@github.com>
 <uJLlYCgzwC0iQI4LWU50dR2Z8hdbxQZIYB-UY-idpfg=.0485aaad-2c8d-4dbd-b511-5891a631b567@github.com>
 <O6vQUNsWJWeIo1PtkdJMarykqjebOV2Ve_BWIcBCvW0=.32fdb615-0bc6-43cb-80d3-25b57838a7d6@github.com>
 <vCc_NzBwMljkWVQ_sAuTlMYUzdpDizxOqHROFBEqD0k=.7e43b058-1a6f-49bc-b921-810eed05efa1@github.com>
 <TY5uV90caTqnIGo-ert8eSswDKqYDctFNpSQ6hPJ6Cw=.447d779f-cce1-472f-b0e2-84babae9bce0@github.com>
Message-ID: <LC7g_xU2q5VgdpdmZJkc4HWRKnn-G0HkRNsSGiBzdf8=.9b040b8a-3853-41b1-8d9c-aeb4af983521@github.com>

On Mon, 28 Jul 2025 09:16:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think we should mull over the addition of CharSequence::codePointCount. On the surface it looks like it fits but we can't rush it (CharSequence is widely implemented and additions to this interface have a history of disruption in the eco system).

We might as well defer it until another JBS issue if it is too difficult to decide whether it should be included in this PR.

> What is the reason for proposing Character.codePointCount(CharSequence) aswell?

1. It already has an overload with the start and end indices unlike `CharSequence` like `String` and `AbstractStringBuilder`
2. Less harmful than `CharSequence::codePointCount` because it is just a static method.
3. There are already the `(CharSequence, int, int)` and `(char[], int, int)` overloads and the `(char[], int, int)` overload is used for the test for `String::codePointCount(int, int)`. We should add the `(char[])` overload for test and also add the `(CharSequence)` for consistency.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3126999990

From rgiulietti at openjdk.org  Mon Jul 28 12:49:01 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 28 Jul 2025 12:49:01 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v8]
In-Reply-To: <nzlwUQNxY2Hp3oRjsWPNMHVzKBlDj9qTkArvQYApFf0=.7af6069d-85cf-4ace-a8dc-6e9f11b800f8@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
 <Akc09cL762LAM8tZXqUuyIZiwKyYQpABKjAjjhqjeT0=.eadecf6b-1a3c-4061-8951-537e6e24742c@github.com>
 <YVXgIFUrrJVHUQCTjPB6eUjJGie7U-gTJMZJCkL4Igk=.ad4d5e6d-89c7-43e1-ac92-4a61cf5d369d@github.com>
 <Q695EiN8cxxpCrgm2HtWNlZGA_4nfsnrjAFOT_90mbw=.ed5bfee8-2f06-40d2-a919-d8e6c8bc5a65@github.com>
 <nzlwUQNxY2Hp3oRjsWPNMHVzKBlDj9qTkArvQYApFf0=.7af6069d-85cf-4ace-a8dc-6e9f11b800f8@github.com>
Message-ID: <JrDV22PlThakQz2JV6IoC4RBJVqXpT8s4kShfNV3lbw=.066f00ba-879b-48f3-a32c-5e09575e591d@github.com>

On Mon, 28 Jul 2025 01:11:26 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> I prefer to calculate an ARRAY_CHAR_SHIFT in the constant like ShortVector does, like this
>> 
>> static final int ARRAY_CHAR_SHIFT 
>>                    = 31 - Integer.numberOfLeadingZeros(Unsafe.ARRAY_CHAR_INDEX_SCALE);
>> 
>>         Unsafe.getUnsafe().copyMemory(
>>                 ca,
>>                 Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off << ARRAY_CHAR_SHIFT,
>>                 val,
>>                 Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off << ARRAY_CHAR_SHIFT,
>>                 (long) (end - off) << ARRAY_CHAR_SHIFT);
>
> String uses `<< coder` in many places. I think the following way of writing is also good:
> 
>         Unsafe.getUnsafe().copyMemory(
>                 ca,
>                 Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off << String.UTF16,
>                 val,
>                 Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off << String.UTF16,
>                 (long) (end - off) << String.UTF16);

I agree that we can expect arrays to be laid out as a contiguous chunk of memory with the intuitively expected element size.
_But..._ AFAIK this is not specified anywhere in the JVMS, although it is true that it is tacitly assumed in many low-level parts of the codebase. So, in this sense, I'm fine with your code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2236290641

From duke at openjdk.org  Mon Jul 28 12:58:59 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 28 Jul 2025 12:58:59 GMT
Subject: RFR: 8077587: BigInteger Roots [v50]
In-Reply-To: <7WhtiCwHeX5nMLwZ1OYLPe4E-Dx7x3P9QwRrxfTL2ck=.d1183665-b780-4820-9613-20e52fbc7a07@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <jORjq44RdJeePfSqqKZBNiJO5r004QoG3CxkdsA_TXc=.39c552a8-7d99-4c70-87bd-b6d5b5e7d181@github.com>
 <7WhtiCwHeX5nMLwZ1OYLPe4E-Dx7x3P9QwRrxfTL2ck=.d1183665-b780-4820-9613-20e52fbc7a07@github.com>
Message-ID: <ODENgx9EjoOIlUUyDdZPCz8rPLz46a4lSlyalJph6KU=.26779c0a-fb0c-4f61-a1ab-53abd787ebba@github.com>

On Sun, 27 Jul 2025 08:26:59 GMT, Thomas Zimmermann <duke at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   A zero root's shift can't be excluded
>
> src/java.base/share/classes/java/math/BigInteger.java line 2773:
> 
>> 2771:      */
>> 2772:     public BigInteger nthRoot(int n) {
>> 2773:         return n == 1 ? this : (n == 2 ? sqrt() : nthRootAndRemainder(n, false)[0]);
> 
> I'm not a reviewer, but I noticed that inlining the `needRemainder`-flag into the callers arguably yields clearer flow, obviates the "Assume n != 1 && n != 2" javadoc and removes the array allocation for `nthRoot`:
> 
> 
>     public BigInteger nthRoot(int n) {
>         if (n == 1)
>             return this;
> 
>         if (n == 2)
>             return sqrt();
> 
>         checkNthRoot(n);
>         MutableBigInteger[] rootRem = new MutableBigInteger(this.mag).nthRootRem(n);
>         return rootRem[0].toBigInteger(signum);
>     }
> 
>     public BigInteger[] nthRootAndRemainder(int n) {
>         if (n == 1)
>             return new BigInteger[] { this, ZERO };
> 
>         if (n == 2)
>             return sqrtAndRemainder();
> 
>         checkNthRoot(n);
>         MutableBigInteger[] rootRem = new MutableBigInteger(this.mag).nthRootRem(n);
>         return new BigInteger[] {
>                 rootRem[0].toBigInteger(signum),
>                 rootRem[1].toBigInteger(signum)
>         };
>     }
> 
>     private static void checkNthRoot(int n) {
>         if (n <= 0)
>             throw new ArithmeticException("Non-positive root degree");
> 
>         if ((n & 1) == 0 && this.signum < 0)
>             throw new ArithmeticException("Negative radicand with even root degree");
>     }
> 
> 
> What do you think?

> @zimmi @fabioromano1 I'm fine with this change. However, I wonder if it might be beneficial to avoid computing the remainder downstream when invoking `nthRoot(int n)`, returning `null` in the array.

The remainder is used by `MBI.nthRootRem(int)` in order to avoid a further iteration in the last loop.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2236338849

From liach at openjdk.org  Mon Jul 28 13:03:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Jul 2025 13:03:57 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v8]
In-Reply-To: <OB-Z7utWaBYE0CKQCyApMsITbbiX7VH8PLYbHaU45Ck=.e7f3859f-d458-41ae-ba72-014e409127ff@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
 <I65deGg4JVnbt9YdlraqFb4g4RQ-9sztwNwopOvuFvc=.ce964a62-eef3-40a9-a11c-f7368991456b@github.com>
 <NPd54DHdF-RbZTJSTtEtSkHm4KGup1sao_HjCjdUChU=.9ec9394d-72ef-403c-8236-4979a952804b@github.com>
 <OB-Z7utWaBYE0CKQCyApMsITbbiX7VH8PLYbHaU45Ck=.e7f3859f-d458-41ae-ba72-014e409127ff@github.com>
Message-ID: <vUWtzUCt9bKLe0NIUB5x8rnNyXJyJxOgnuAmp-dZptA=.12de75c6-456f-43c2-8bdc-97f4cd471de0@github.com>

On Thu, 24 Jul 2025 14:38:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I recall runtime requires UTF16 byte array and char array have exactly the same layout - would be nice if we keep this in the design notes for the string implementation classes, such as on the class header.
>> 
>> (Useful notes could include that indices are char-based, UTF16 byte[] and char[] has identical layout, etc.)
>
> The StringUTF16.getChar and putChar methods are carefully written to use the platform endianness to compose and decompose char values from and to byte[] in terms of shifts of the lower and upper bytes.
> The mapping of that into other apis that try to optimize between char[] and the compact string byte[] are less well documented.

I've found the code that imposes this requirement:

https://github.com/openjdk/jdk/blob/7bf4c608e7b23398ea89cf0a592e9554af98144e/src/hotspot/share/opto/library_call.cpp#L1713-L1718

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2236359828

From duke at openjdk.org  Mon Jul 28 13:11:01 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 28 Jul 2025 13:11:01 GMT
Subject: RFR: 8077587: BigInteger Roots [v50]
In-Reply-To: <7WhtiCwHeX5nMLwZ1OYLPe4E-Dx7x3P9QwRrxfTL2ck=.d1183665-b780-4820-9613-20e52fbc7a07@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <jORjq44RdJeePfSqqKZBNiJO5r004QoG3CxkdsA_TXc=.39c552a8-7d99-4c70-87bd-b6d5b5e7d181@github.com>
 <7WhtiCwHeX5nMLwZ1OYLPe4E-Dx7x3P9QwRrxfTL2ck=.d1183665-b780-4820-9613-20e52fbc7a07@github.com>
Message-ID: <HItaIIYt7TdbgqO-L5UNh5vtGgt6Z-9CwUOPuI2t3rY=.996e6f53-6a61-4ee1-85be-2085d836c759@github.com>

On Sun, 27 Jul 2025 08:26:59 GMT, Thomas Zimmermann <duke at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   A zero root's shift can't be excluded
>
> src/java.base/share/classes/java/math/BigInteger.java line 2773:
> 
>> 2771:      */
>> 2772:     public BigInteger nthRoot(int n) {
>> 2773:         return n == 1 ? this : (n == 2 ? sqrt() : nthRootAndRemainder(n, false)[0]);
> 
> I'm not a reviewer, but I noticed that inlining the `needRemainder`-flag into the callers arguably yields clearer flow, obviates the "Assume n != 1 && n != 2" javadoc and removes the array allocation for `nthRoot`:
> 
> 
>     public BigInteger nthRoot(int n) {
>         if (n == 1)
>             return this;
> 
>         if (n == 2)
>             return sqrt();
> 
>         checkNthRoot(n);
>         MutableBigInteger[] rootRem = new MutableBigInteger(this.mag).nthRootRem(n);
>         return rootRem[0].toBigInteger(signum);
>     }
> 
>     public BigInteger[] nthRootAndRemainder(int n) {
>         if (n == 1)
>             return new BigInteger[] { this, ZERO };
> 
>         if (n == 2)
>             return sqrtAndRemainder();
> 
>         checkNthRoot(n);
>         MutableBigInteger[] rootRem = new MutableBigInteger(this.mag).nthRootRem(n);
>         return new BigInteger[] {
>                 rootRem[0].toBigInteger(signum),
>                 rootRem[1].toBigInteger(signum)
>         };
>     }
> 
>     private static void checkNthRoot(int n) {
>         if (n <= 0)
>             throw new ArithmeticException("Non-positive root degree");
> 
>         if ((n & 1) == 0 && this.signum < 0)
>             throw new ArithmeticException("Negative radicand with even root degree");
>     }
> 
> 
> What do you think?

> @zimmi @fabioromano1 I'm fine with this change. However, I wonder if it might be beneficial to avoid computing the remainder downstream when invoking `nthRoot(int n)`, returning `null` in the array.

Why do useless work to cast the remainder to `BigInteger` when it is not needed, considering that it could cost an allocation of a new `int[]` array?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2236387303

From coffeys at openjdk.org  Mon Jul 28 13:15:57 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 28 Jul 2025 13:15:57 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms
In-Reply-To: <84bqpOT-0Mvgqr3173feXu3KGIdl3RIFMK9Kxrr3w1Q=.2bf8673e-1bc1-4c7f-a01a-f2ff51f9cc48@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
 <84bqpOT-0Mvgqr3173feXu3KGIdl3RIFMK9Kxrr3w1Q=.2bf8673e-1bc1-4c7f-a01a-f2ff51f9cc48@github.com>
Message-ID: <X0XGe0QDop17hM8zBFl14Lz5VGxA9HgbEo5UumVJUfQ=.22f7a8d3-1d4a-4339-9691-e1ca0a5fc08c@github.com>

On Tue, 8 Jul 2025 05:13:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> 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.

It's a fair point Jai. Obtaining such data in a live JVM can be useful. IMO, it's also useful to have it recorded in launcher logs so perhaps both approaches are warranted (maybe a follow on JBS enhancement where jcmd can replay the XshowSettings launcher data ?)

@mpdonova  - do you plan to have some test coverage to track this addition ? Perhaps you could edit the original two test files at https://github.com/openjdk/jdk/commit/2e12a123c9955b7360fd752a6a33d59b6271c5af

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3127191512

From dl at openjdk.org  Mon Jul 28 13:22:36 2025
From: dl at openjdk.org (Doug Lea)
Date: Mon, 28 Jul 2025 13:22:36 GMT
Subject: RFR: 8360046: Scalability issue when submitting virtual threads
 with almost empty tasks [v4]
In-Reply-To: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
References: <MHIvw4YbJ1GwHcBKRKmrFyLTqOtbuSRGMx-jsC9zO-w=.b10ba078-2f22-4daa-911a-d770f901acea@github.com>
Message-ID: <FLeeaJ2bLQon98ZHj4AD_2V_K6lMzWwJZNbW7qo7L9g=.3f63a31d-2192-4aaf-96f4-a5759ca02026@github.com>

> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally.

Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8360046
 - Undo inadvertent acquire change
 - Add adapt(callable) case to test
 - Whitespace
 - Merge branch 'openjdk:master' into JDK-8360046
 - Avoid unnecessary use of InterruptibleTask; misc cleanup
 - revert runWorker; tweak external probes
 - reduce contention
 - Merge branch 'openjdk:master' into JDK-8360046
 - For testing
 - ... and 1 more: https://git.openjdk.org/jdk/compare/4c894902...c16c1282

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26479/files
  - new: https://git.openjdk.org/jdk/pull/26479/files/6b22e247..c16c1282

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=02-03

  Stats: 1514 lines in 102 files changed: 745 ins; 510 del; 259 mod
  Patch: https://git.openjdk.org/jdk/pull/26479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479

PR: https://git.openjdk.org/jdk/pull/26479

From duke at openjdk.org  Mon Jul 28 14:03:16 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 28 Jul 2025 14:03:16 GMT
Subject: RFR: 8077587: BigInteger Roots [v52]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <t2eAfbylc3XKJlKP5VF5vtSpBqDbDTPUeA_ZihVMqto=.329be2d0-fb32-4cd1-919c-5901d9c5001f@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Zimmermann suggestion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/7cc53750..31e5f890

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=51
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=50-51

  Stats: 30 lines in 1 file changed: 17 ins; 9 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From swen at openjdk.org  Mon Jul 28 14:06:58 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 28 Jul 2025 14:06:58 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v8]
In-Reply-To: <JrDV22PlThakQz2JV6IoC4RBJVqXpT8s4kShfNV3lbw=.066f00ba-879b-48f3-a32c-5e09575e591d@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
 <Akc09cL762LAM8tZXqUuyIZiwKyYQpABKjAjjhqjeT0=.eadecf6b-1a3c-4061-8951-537e6e24742c@github.com>
 <YVXgIFUrrJVHUQCTjPB6eUjJGie7U-gTJMZJCkL4Igk=.ad4d5e6d-89c7-43e1-ac92-4a61cf5d369d@github.com>
 <Q695EiN8cxxpCrgm2HtWNlZGA_4nfsnrjAFOT_90mbw=.ed5bfee8-2f06-40d2-a919-d8e6c8bc5a65@github.com>
 <nzlwUQNxY2Hp3oRjsWPNMHVzKBlDj9qTkArvQYApFf0=.7af6069d-85cf-4ace-a8dc-6e9f11b800f8@github.com>
 <JrDV22PlThakQz2JV6IoC4RBJVqXpT8s4kShfNV3lbw=.066f00ba-879b-48f3-a32c-5e09575e591d@github.com>
Message-ID: <n3DZQFajQ9Kupu1lw5N-hKa0fwBojVY3zI5He0kQqpQ=.73c2d725-98cf-451f-8331-66b51e029799@github.com>

On Mon, 28 Jul 2025 12:46:22 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> String uses `<< coder` in many places. I think the following way of writing is also good:
>> 
>>         Unsafe.getUnsafe().copyMemory(
>>                 ca,
>>                 Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) off << String.UTF16,
>>                 val,
>>                 Unsafe.ARRAY_CHAR_BASE_OFFSET + (long) index << String.UTF16,
>>                 (long) (end - off) << String.UTF16);
>
> I agree that we can expect arrays to be laid out as a contiguous chunk of memory with the intuitively expected element size.
> _But..._ AFAIK this is not specified anywhere in the JVMS, although it is true that it is tacitly assumed in many low-level parts of the codebase. So, in this sense, I'm fine with your code.

There are many places in the String class that use `<< 1` and `>> 1` to handle the length of UTF16 byte[], so is it okay to use `<< 1` directly in the current version of the code?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2236631515

From naoto at openjdk.org  Mon Jul 28 16:11:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 28 Jul 2025 16:11:56 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v3]
In-Reply-To: <uJLlYCgzwC0iQI4LWU50dR2Z8hdbxQZIYB-UY-idpfg=.0485aaad-2c8d-4dbd-b511-5891a631b567@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
 <jVLO3nEjKz0T_0TBR-pRqQoA-QckJHFouSlGaah8uW8=.a3dcce0a-8582-4727-8645-f44a69c73205@github.com>
 <YgNYs5M1Ys2vCTQ5KZpC7ndV3aIDSf-j_GODF3by2ZA=.1a2dc1cb-155c-4ad8-b800-167baa3533c4@github.com>
 <uJLlYCgzwC0iQI4LWU50dR2Z8hdbxQZIYB-UY-idpfg=.0485aaad-2c8d-4dbd-b511-5891a631b567@github.com>
Message-ID: <SIiclFMHb56wXYyhj7jaQS29MoivHhUXfKCnS6d1OOg=.80f35ddb-bcd0-417a-83ac-38accf8c70b3@github.com>

On Sun, 27 Jul 2025 10:23:03 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> The addition to CharSequence will require static analysis to check for conflicts with implementation. It will also likely impact the CharBuffer spec.

Looking at the original JSR 204 issue: https://bugs.openjdk.org/browse/JDK-4985217, it is interesting that the problem description included `CharSequence` but not in the proposed API. Tried to find the reason behind, but could not find any relevant information so far.
As to the general comment, I am not so sure adding the no-arg overrides, as they would simply be convenience methods to `codePointCount(0, length())` which to me adding not a significant benefit. My $0.02

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3127954858

From rriggs at openjdk.org  Mon Jul 28 16:12:00 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 28 Jul 2025 16:12:00 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v8]
In-Reply-To: <n3DZQFajQ9Kupu1lw5N-hKa0fwBojVY3zI5He0kQqpQ=.73c2d725-98cf-451f-8331-66b51e029799@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
 <Akc09cL762LAM8tZXqUuyIZiwKyYQpABKjAjjhqjeT0=.eadecf6b-1a3c-4061-8951-537e6e24742c@github.com>
 <YVXgIFUrrJVHUQCTjPB6eUjJGie7U-gTJMZJCkL4Igk=.ad4d5e6d-89c7-43e1-ac92-4a61cf5d369d@github.com>
 <Q695EiN8cxxpCrgm2HtWNlZGA_4nfsnrjAFOT_90mbw=.ed5bfee8-2f06-40d2-a919-d8e6c8bc5a65@github.com>
 <nzlwUQNxY2Hp3oRjsWPNMHVzKBlDj9qTkArvQYApFf0=.7af6069d-85cf-4ace-a8dc-6e9f11b800f8@github.com>
 <JrDV22PlThakQz2JV6IoC4RBJVqXpT8s4kShfNV3lbw=.066f00ba-879b-48f3-a32c-5e09575e591d@github.com>
 <n3DZQFajQ9Kupu1lw5N-hKa0fwBojVY3zI5He0kQqpQ=.73c2d725-98cf-451f-8331-66b51e029799@github.com>
Message-ID: <SVk17UXsyztC4iVCGGJ0SNjHkK6iXjRwYj8yF23lTqQ=.abd2a286-a0a6-4d70-a36c-34c0e780e029@github.com>

On Mon, 28 Jul 2025 14:04:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> I agree that we can expect arrays to be laid out as a contiguous chunk of memory with the intuitively expected element size.
>> _But..._ AFAIK this is not specified anywhere in the JVMS, although it is true that it is tacitly assumed in many low-level parts of the codebase. So, in this sense, I'm fine with your code.
>
> There are many places in the String class that use `<< 1` and `>> 1` to handle the length of UTF16 byte[], so is it okay to use `<< 1` directly in the current version of the code?

For consistency, I prefer the explicit constant shift `<< 1` and `>> 1`.
Using the String.UTF16 symbol makes the code more verbose.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24773#discussion_r2237112304

From asemenyuk at openjdk.org  Mon Jul 28 16:21:57 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 28 Jul 2025 16:21:57 GMT
Subject: RFR: 8364089: JDK 25 RDP2 L10n resource files update
In-Reply-To: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
References: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
Message-ID: <ht1okQrxkWG6QOaDhqlq_YxoxfM3E_fIZiog19cdumU=.931ade81-50b9-4dc2-b691-ac7685cbdbd6@github.com>

On Fri, 25 Jul 2025 00:25:01 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Marked as reviewed by asemenyuk (Reviewer).

jpackage changes look good

-------------

PR Review: https://git.openjdk.org/jdk/pull/26467#pullrequestreview-3063629934
PR Comment: https://git.openjdk.org/jdk/pull/26467#issuecomment-3128009012

From asemenyuk at openjdk.org  Mon Jul 28 16:21:58 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 28 Jul 2025 16:21:58 GMT
Subject: RFR: 8364089: JDK 25 RDP2 L10n resource files update
In-Reply-To: <r76j2NQHkxocAYYa9d5eDL_XoKTwi0Y-O0S4PQPBa0o=.53a4966d-b9de-4332-b82c-f4d40412f101@github.com>
References: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
 <r76j2NQHkxocAYYa9d5eDL_XoKTwi0Y-O0S4PQPBa0o=.53a4966d-b9de-4332-b82c-f4d40412f101@github.com>
Message-ID: <XprKcnLnzROWX33uhmcmSWgYzCXLfKS1vRWZHbVko5k=.60b9e6d7-1fb2-44f5-ad74-f58e64cfc192@github.com>

On Fri, 25 Jul 2025 16:23:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 89:
> 
>> 87: MSG_BundlerConfigExceptionNoAdvice=Bundler {0} aufgrund eines Konfigurationsproblems ?bersprungen: {1}
>> 88: MSG_BundlerRuntimeException=Bundler {0} nicht erfolgreich. Grund: {1}
>> 89: MSG_BundlerFailed=Fehler: Bundler "{1}" ({0}) konnte kein Package generieren
> 
> Even though there was no change in the original, it looks like they removed this entry because it was a duplicate. We should consider filing a separate issue to have the duplicate removed in the original as well.

@justin-curtis-lu the issue has been filed and resolved already - [JDK-8361697](https://bugs.openjdk.org/browse/JDK-8361697)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26467#discussion_r2237149723

From jlu at openjdk.org  Mon Jul 28 16:33:00 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 28 Jul 2025 16:33:00 GMT
Subject: RFR: 8364089: JDK 25 RDP2 L10n resource files update
In-Reply-To: <XprKcnLnzROWX33uhmcmSWgYzCXLfKS1vRWZHbVko5k=.60b9e6d7-1fb2-44f5-ad74-f58e64cfc192@github.com>
References: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
 <r76j2NQHkxocAYYa9d5eDL_XoKTwi0Y-O0S4PQPBa0o=.53a4966d-b9de-4332-b82c-f4d40412f101@github.com>
 <XprKcnLnzROWX33uhmcmSWgYzCXLfKS1vRWZHbVko5k=.60b9e6d7-1fb2-44f5-ad74-f58e64cfc192@github.com>
Message-ID: <y8EEf37XTMCbv3ex17Kf6nXXNHTAFOCU9wEHqnygXkY=.bbf01a07-a6ac-4a09-a914-4e6cbb0a6d58@github.com>

On Mon, 28 Jul 2025 16:19:07 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 89:
>> 
>>> 87: MSG_BundlerConfigExceptionNoAdvice=Bundler {0} aufgrund eines Konfigurationsproblems ?bersprungen: {1}
>>> 88: MSG_BundlerRuntimeException=Bundler {0} nicht erfolgreich. Grund: {1}
>>> 89: MSG_BundlerFailed=Fehler: Bundler "{1}" ({0}) konnte kein Package generieren
>> 
>> Even though there was no change in the original, it looks like they removed this entry because it was a duplicate. We should consider filing a separate issue to have the duplicate removed in the original as well.
>
> @justin-curtis-lu the issue has been filed and resolved already - [JDK-8361697](https://bugs.openjdk.org/browse/JDK-8361697)

Thanks, I missed that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26467#discussion_r2237188811

From almatvee at openjdk.org  Mon Jul 28 17:08:04 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 28 Jul 2025 17:08:04 GMT
Subject: Integrated: 8360507: JPKG002-006: SigningPackageTest: appOutput.txt
 cannot be found in user home directory and output doesn't contain:
 origin=Developer ID Application: jpackage.openjdk.java.net
In-Reply-To: <fAuoE-ZANsAJ2EpjGiWWAhur5mp9AmT2eSMYzelOdfw=.69551766-28bc-4627-b529-12b63d162e95@github.com>
References: <fAuoE-ZANsAJ2EpjGiWWAhur5mp9AmT2eSMYzelOdfw=.69551766-28bc-4627-b529-12b63d162e95@github.com>
Message-ID: <nCtqWxYRZu3ULIYMgopQjXqPV51gJA5izV2xm_Zv3uE=.ae8bc892-443e-437b-a5ce-65a00dfde096@github.com>

On Fri, 25 Jul 2025 21:25:36 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Wrong package was generated for SQE. Fixed by generating correct package for SQE.
> - Issue with appOutput.txt is not created will be fixed with https://bugs.openjdk.org/browse/JDK-8358723.

This pull request has now been integrated.

Changeset: fe4d7f8c
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fe4d7f8c1b1c5a64ed8f134c414d75da0b9cfdff
Stats:     19 lines in 1 file changed: 19 ins; 0 del; 0 mod

8360507: JPKG002-006: SigningPackageTest: appOutput.txt cannot be found in user home directory and output doesn't contain: origin=Developer ID Application: jpackage.openjdk.java.net

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/26485

From rgiulietti at openjdk.org  Mon Jul 28 17:08:04 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 28 Jul 2025 17:08:04 GMT
Subject: RFR: 8077587: BigInteger Roots [v52]
In-Reply-To: <t2eAfbylc3XKJlKP5VF5vtSpBqDbDTPUeA_ZihVMqto=.329be2d0-fb32-4cd1-919c-5901d9c5001f@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <t2eAfbylc3XKJlKP5VF5vtSpBqDbDTPUeA_ZihVMqto=.329be2d0-fb32-4cd1-919c-5901d9c5001f@github.com>
Message-ID: <b5vWCi2vkCkq2Yq8oxDZnvxFWOaJHUC9pWjN6fTafoU=.09fd5739-6f1c-4ea5-b4de-8d83e322aa56@github.com>

On Mon, 28 Jul 2025 14:03:16 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Zimmermann suggestion

src/java.base/share/classes/java/math/MutableBigInteger.java line 1993:

> 1991:              * non-significant bits), and the shift is performed in order to lose
> 1992:              * the smallest number of bits in the significand if necessary (minimizing loss of precision).
> 1993:              */

@fabioromano1 I've now spent several hours trying to "reverse engineer" (Java code -> maths) what is going on in the code below that tries to come up with a nice initial estimate of the end result, before starting Newton's loop.
I'm still not 100% sure I've got everything correctly, and whether each detail is mathematically sound.
The same will probably happen to other readers and maintainers in the future.

I understand the overall tactic described in the comment above. However, the details of the different (sub)cases deserve (and need) a more detailed documentation to help and guide future enhancements and fixes.
The best way, of course, is to use maths arguments whenever possible.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2237296712

From duke at openjdk.org  Mon Jul 28 17:10:13 2025
From: duke at openjdk.org (Philippe Marschall)
Date: Mon, 28 Jul 2025 17:10:13 GMT
Subject: RFR: 8362893: Improve performance for MemorySegment::getString
 [v2]
In-Reply-To: <2Ylzaqh6EGpyeUXRRXrrDizXVqCghqobGmDHYEiTy0A=.078ad8e4-9eca-4ab6-86cd-60bf8b894201@github.com>
References: <2Ylzaqh6EGpyeUXRRXrrDizXVqCghqobGmDHYEiTy0A=.078ad8e4-9eca-4ab6-86cd-60bf8b894201@github.com>
Message-ID: <T8sNkm9vcL9kWvFNVzyURvVNdHqwfQYe2-rjEQ-Rt1Q=.f0711da8-4c35-4d1e-aa35-a8f18cf79d44@github.com>

> Use `JavaLangAccess::uncheckedNewStringNoRepl` in `MemorySegment::getString` to avoid byte[] allocation in the String constructor.
> 
> Fall back to the old code in the case of malformed input to get replacement characters as per Javadoc API specification. The existing tests in `TestStringEncoding` seem sufficient to me.
> 
> I ran the tier1 test suite and it passes.
> 
> For performance analysis I ran.
> 
>     make test TEST="micro:org.openjdk.bench.java.lang.foreign.ToJavaStringTest" MICRO="OPTIONS=-prof gc"
> 
> on an AMD Ryzen 7 PRO 5750GE.
> 
> These are the formatted results, the current master is the line on top, this feature branch is the line below. We can see an improvement in throughput driven by a reduction in allocation.
> 
> 
> Benchmark                                              (size)  Mode  Cnt     Score    Error   Units
> 
> ToJavaStringTest.panama_readString                          5  avgt   30    18.996 ?  0.044   ns/op
> ToJavaStringTest.panama_readString                          5  avgt   30    13.851 ?  0.028   ns/op
> 
> ToJavaStringTest.panama_readString                         20  avgt   30    23.570 ?  0.050   ns/op
> ToJavaStringTest.panama_readString                         20  avgt   30    18.401 ?  0.069   ns/op
> 
> ToJavaStringTest.panama_readString                        100  avgt   30    32.094 ?  0.207   ns/op
> ToJavaStringTest.panama_readString                        100  avgt   30    24.427 ?  0.112   ns/op
> 
> ToJavaStringTest.panama_readString                        200  avgt   30    43.029 ?  0.185   ns/op
> ToJavaStringTest.panama_readString                        200  avgt   30    31.914 ?  0.064   ns/op
> 
> ToJavaStringTest.panama_readString                        451  avgt   30    81.145 ?  0.403   ns/op
> ToJavaStringTest.panama_readString                        451  avgt   30    58.975 ?  0.233   ns/op
> 
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm       5  avgt   30    72.000 ?  0.001    B/op
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm       5  avgt   30    48.000 ?  0.001    B/op
> 
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm      20  avgt   30   104.000 ?  0.001    B/op
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm      20  avgt   30    64.000 ?  0.001    B/op
> 
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm     100  avgt   30   264.000 ?  0.001    B/op
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm     100  avgt   30   144.000 ?  0.001    B/op
> 
> ToJavaStringTest.panama_readString:gc.alloc.rate.norm     200  avgt ...

Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26493/files
  - new: https://git.openjdk.org/jdk/pull/26493/files/24a83a5b..130ad859

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26493&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26493&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26493.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26493/head:pull/26493

PR: https://git.openjdk.org/jdk/pull/26493

From duke at openjdk.org  Mon Jul 28 17:10:13 2025
From: duke at openjdk.org (Philippe Marschall)
Date: Mon, 28 Jul 2025 17:10:13 GMT
Subject: RFR: 8362893: Improve performance for MemorySegment::getString
 [v2]
In-Reply-To: <Tuf079C-mq9q7shmSx6qMTxz7Sk4rD8H2RfT-pbGDUE=.d4bb1da1-68bc-4796-b06c-1986066fb824@github.com>
References: <2Ylzaqh6EGpyeUXRRXrrDizXVqCghqobGmDHYEiTy0A=.078ad8e4-9eca-4ab6-86cd-60bf8b894201@github.com>
 <Tuf079C-mq9q7shmSx6qMTxz7Sk4rD8H2RfT-pbGDUE=.d4bb1da1-68bc-4796-b06c-1986066fb824@github.com>
Message-ID: <Pq0i5TaVjHwW4KJCZzZvo0wPX3TGpF4b7zCQ8fPfO60=.1a336723-0c92-44d6-85ff-48af50a9602e@github.com>

On Mon, 28 Jul 2025 01:15:17 GMT, simon <duke at openjdk.org> wrote:

>> Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright year
>
> src/java.base/share/classes/jdk/internal/foreign/StringSupport.java line 33:
> 
>> 31: import jdk.internal.util.Architecture;
>> 32: import jdk.internal.util.ArraysSupport;
>> 33: import jdk.internal.vm.annotation.ForceInline;
> 
> Nitpick: update copyright year ?

Had it on my list but forgot it. Should be fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26493#discussion_r2237307075

From duke at openjdk.org  Mon Jul 28 17:17:00 2025
From: duke at openjdk.org (fabioromano1)
Date: Mon, 28 Jul 2025 17:17:00 GMT
Subject: RFR: 8077587: BigInteger Roots [v52]
In-Reply-To: <b5vWCi2vkCkq2Yq8oxDZnvxFWOaJHUC9pWjN6fTafoU=.09fd5739-6f1c-4ea5-b4de-8d83e322aa56@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <t2eAfbylc3XKJlKP5VF5vtSpBqDbDTPUeA_ZihVMqto=.329be2d0-fb32-4cd1-919c-5901d9c5001f@github.com>
 <b5vWCi2vkCkq2Yq8oxDZnvxFWOaJHUC9pWjN6fTafoU=.09fd5739-6f1c-4ea5-b4de-8d83e322aa56@github.com>
Message-ID: <C3pTQ-H31An6ViyH3s894aTNcLkxDA-klEEpvSArD0M=.7376beec-e9fd-4da2-936a-99f7a376da95@github.com>

On Mon, 28 Jul 2025 17:03:48 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Zimmermann suggestion
>
> src/java.base/share/classes/java/math/MutableBigInteger.java line 1993:
> 
>> 1991:              * non-significant bits), and the shift is performed in order to lose
>> 1992:              * the smallest number of bits in the significand if necessary (minimizing loss of precision).
>> 1993:              */
> 
> @fabioromano1 I've now spent several hours trying to "reverse engineer" (Java code -> maths) what is going on in the code below that tries to come up with a nice initial estimate of the end result, before starting Newton's loop.
> I'm still not 100% sure I've got everything correctly, and whether each detail is mathematically sound.
> The same will probably happen to other readers and maintainers in the future.
> 
> I understand the overall tactic described in the comment above. However, the details of the different (sub)cases deserve (and need) a more detailed documentation to help and guide future enhancements and fixes.
> The best way, of course, is to use maths arguments whenever possible.

@rgiulietti It would be helpful for me to know the points of the code that are still not completly clear, since there are already some comments in the code, so I can know where to add others.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2237324405

From rgiulietti at openjdk.org  Mon Jul 28 17:50:02 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 28 Jul 2025 17:50:02 GMT
Subject: RFR: 8077587: BigInteger Roots [v52]
In-Reply-To: <C3pTQ-H31An6ViyH3s894aTNcLkxDA-klEEpvSArD0M=.7376beec-e9fd-4da2-936a-99f7a376da95@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <t2eAfbylc3XKJlKP5VF5vtSpBqDbDTPUeA_ZihVMqto=.329be2d0-fb32-4cd1-919c-5901d9c5001f@github.com>
 <b5vWCi2vkCkq2Yq8oxDZnvxFWOaJHUC9pWjN6fTafoU=.09fd5739-6f1c-4ea5-b4de-8d83e322aa56@github.com>
 <C3pTQ-H31An6ViyH3s894aTNcLkxDA-klEEpvSArD0M=.7376beec-e9fd-4da2-936a-99f7a376da95@github.com>
Message-ID: <72fWWgFdaVV3ye4YTDWfqVo7EkQVT_mGU8GdPMsoTvI=.ee99de77-b293-4178-b354-1a69b35ce0bc@github.com>

On Mon, 28 Jul 2025 17:13:48 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1993:
>> 
>>> 1991:              * non-significant bits), and the shift is performed in order to lose
>>> 1992:              * the smallest number of bits in the significand if necessary (minimizing loss of precision).
>>> 1993:              */
>> 
>> @fabioromano1 I've now spent several hours trying to "reverse engineer" (Java code -> maths) what is going on in the code below that tries to come up with a nice initial estimate of the end result, before starting Newton's loop.
>> I'm still not 100% sure I've got everything correctly, and whether each detail is mathematically sound.
>> The same will probably happen to other readers and maintainers in the future.
>> 
>> I understand the overall tactic described in the comment above. However, the details of the different (sub)cases deserve (and need) a more detailed documentation to help and guide future enhancements and fixes.
>> The best way, of course, is to use maths arguments whenever possible.
>
> @rgiulietti It would be helpful for me to know the points of the code (or the details) that are still not completly clear, since there are already some comments in the code, so I can know where to add others.

Sure, I'll try to point them out in the next days.

A trick that works for me, when attempting to comment my own code, is to imagine explaining it to a colleague or trying to anticipate the comments of a reviewer ;-) This includes everything not self-evident, details about correctness, readability, performance, etc. In summary, trying to put myself in my audience's place. In my experience, finding a good balance is not easy.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2237432706

From sparasa at openjdk.org  Mon Jul 28 18:38:55 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 28 Jul 2025 18:38:55 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v2]
In-Reply-To: <9pe9LuUrBnk6A2TQ2emhgonljAvnJLcmSV_lEbrYIlo=.fec9b081-d6ae-4d85-8826-489828d9f442@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <9pe9LuUrBnk6A2TQ2emhgonljAvnJLcmSV_lEbrYIlo=.fec9b081-d6ae-4d85-8826-489828d9f442@github.com>
Message-ID: <sGS4YO1tkFeVCMVu_D-zTPiZPsGw8IMCEt7IeEMxRCE=.797cdce0-a0f0-4ff2-9b6f-7a3ab4223359@github.com>

On Thu, 17 Jul 2025 18:46:06 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.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move error bound to separate section in comment header

I reviewed the code, ran the benchmarks and correctness test and verified that it's passing. This PR looks good to me.

-------------

Marked as reviewed by sparasa (Author).

PR Review: https://git.openjdk.org/jdk/pull/26152#pullrequestreview-3064160746

From liach at openjdk.org  Mon Jul 28 19:06:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Jul 2025 19:06:13 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v13]
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: <0NP8NQWEtvwY6osQkaxM2_OPSM8D1RrX-5fla0RmPkg=.63ebe03c-cf48-45db-b9bb-a82e1190edc5@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 28 commits:

 - aot safe markers for runtime setup
 - 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
 - Restore non-public comments
 - 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
 - ... and 18 more: https://git.openjdk.org/jdk/compare/ea0b49c3...49f7bd5b

-------------

Changes: https://git.openjdk.org/jdk/pull/25922/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=12
  Stats: 494 lines in 39 files changed: 324 ins; 150 del; 20 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 iklam at openjdk.org  Mon Jul 28 19:47:59 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 28 Jul 2025 19:47:59 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v13]
In-Reply-To: <0NP8NQWEtvwY6osQkaxM2_OPSM8D1RrX-5fla0RmPkg=.63ebe03c-cf48-45db-b9bb-a82e1190edc5@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <0NP8NQWEtvwY6osQkaxM2_OPSM8D1RrX-5fla0RmPkg=.63ebe03c-cf48-45db-b9bb-a82e1190edc5@github.com>
Message-ID: <HKhZRheRVuBFmxhp7lc1WvWjej6acdBAGuncu20_MJw=.eb22b1aa-bb6a-45ad-800f-25d433a6fc17@github.com>

On Mon, 28 Jul 2025 19:06:13 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 28 commits:
> 
>  - aot safe markers for runtime setup
>  - 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
>  - Restore non-public comments
>  - 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
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/ea0b49c3...49f7bd5b

Updates look good to me.

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-3064404358

From duke at openjdk.org  Mon Jul 28 20:10:05 2025
From: duke at openjdk.org (Alice Pellegrini)
Date: Mon, 28 Jul 2025 20:10:05 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
Message-ID: <s6SK1ACAOIlxZROm0d0-EXIVox-NGYA8PLbOmKE1mdI=.f6bcac25-9091-4e28-87c6-6de583690b88@github.com>

On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini <duke at openjdk.org> wrote:

>> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
>> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.
>> 
>> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.
>
> Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print
>  - Update test/lib/jdk/test/lib/process/OutputBuffer.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Initial working solution

The need will be addressed in the affected test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25587#issuecomment-3129311861

From duke at openjdk.org  Mon Jul 28 20:10:06 2025
From: duke at openjdk.org (Alice Pellegrini)
Date: Mon, 28 Jul 2025 20:10:06 GMT
Subject: Withdrawn: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens
In-Reply-To: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
Message-ID: <iKap2LXfdXyhxtKUneQUWqgGNdRrMHK9K4QA0SSQjms=.c40228f4-ff39-4d8b-af21-090717734035@github.com>

On Mon, 2 Jun 2025 11:54:10 GMT, Alice Pellegrini <duke at openjdk.org> wrote:

> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.
> 
> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25587

From simon at 60hertz.com  Mon Jul 28 20:17:09 2025
From: simon at 60hertz.com (simon at 60hertz.com)
Date: Mon, 28 Jul 2025 21:17:09 +0100
Subject: Towards a JSON API for the JDK
Message-ID: <bdce9785-949e-4fe0-b85c-8415924c55b5@app.fastmail.com>

Hi All,

For anyone interested in experimenting with the proposed java.util.json API design, I've created a backport that works with JDK 21:

https://github.com/simbo1905/java.util.json.Java21

This is derived from the OpenJDK sandbox commit d22dc2ba (mid-July 2025). The backport:

- Works with JDK 21
- Focuses on API compatibility rather than performance
- Uses double-checked locking instead of StableValue
- Runs the JSON Test Suite

The repository includes examples showing the API in use with records, streams, and type conversions.

Regards,

Simon

From roger.riggs at oracle.com  Mon Jul 28 20:18:07 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 28 Jul 2025 16:18:07 -0400
Subject: String encodeUTF8 latin1 with negatives
In-Reply-To: <CANBJVOFLAWc_XqqT9vK4m4F6UG6_My3QsrBqgo+odz3gih7OrQ@mail.gmail.com>
References: <CANBJVOFLAWc_XqqT9vK4m4F6UG6_My3QsrBqgo+odz3gih7OrQ@mail.gmail.com>
Message-ID: <ea368e23-83b4-4696-8325-b5edef5e5f62@oracle.com>

Hi Brett,

Extra care is needed if the input array might be modified concurrently 
with the method execution.
When control flow decisions are made based on array contents, the 
integrity of the result depends on reading each byte of the array 
exactly once.

Regards, Roger



On 7/27/25 4:45 PM, Brett Okken wrote:
> In String.encodeUTF8, when the coder is latin1, there is a call to 
> StringCoding.hasNegatives to determine if any special handling is 
> needed. If not, a clone of the val is returned.
> If there are negative values, it then loops, from the beginning, 
> through all the values to handle any individual negative values.
>
> Would it be better to call StringCoding.countPositives? If the result 
> equals the length, the clone can still be returned. But if it does 
> not, all the values which are positive can be simply copied to the 
> target byte[] and only values beyond that point need to be checked again.
>
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L1287-L1300
>
> ? ? ? ? if (!StringCoding.hasNegatives(val, 0, val.length)) {
> ? ? ? ? ? ? return val.clone();
> ? ? ? ? }
>
> ? ? ? ? int dp = 0;
> ? ? ? ? byte[] dst = StringUTF16.newBytesFor(val.length);
> ? ? ? ? for (byte c : val) {
> ? ? ? ? ? ? if (c < 0) {
> ? ? ? ? ? ? ? ? dst[dp++] = (byte) (0xc0 | ((c & 0xff) >> 6));
> ? ? ? ? ? ? ? ? dst[dp++] = (byte) (0x80 | (c & 0x3f));
> ? ? ? ? ? ? } else {
> ? ? ? ? ? ? ? ? dst[dp++] = c;
> ? ? ? ? ? ? }
> ? ? ? ? }
>
>
> Can be changed to look like:
>
> ? ? ? ? int positives = StringCoding.countPositives(val, 0, val.length);
> ? ? ? ? if (positives == val.length) {
> ? ? ? ? ? ? return val.clone();
> ? ? ? ? }
>
> int dp = positives;
> ? ? ? ? byte[] dst = StringUTF16.newBytesFor(val.length);
> ? ? ? ? if (positives > 0) {
> ? ? ? ? ? ? System.arraycopy(val, 0, dst, 0, positives);
> ? ? ? ? }
> ? ? ? ? for (int i=dp; i<val.length; ++i) {
> ? ? ? ? ? ? byte c = val[i];
> ? ? ? ? ? ? if (c < 0) {
> ? ? ? ? ? ? ? ? dst[dp++] = (byte) (0xc0 | ((c & 0xff) >> 6));
> ? ? ? ? ? ? ? ? dst[dp++] = (byte) (0x80 | (c & 0x3f));
> ? ? ? ? ? ? } else {
> ? ? ? ? ? ? ? ? dst[dp++] = c;
> ? ? ? ? ? ? }
> ? ? ? ? }
>
>
>
> I have done a bit of testing with the StringEncode jmh benchmark on my 
> local windows device.
>
> encodeLatin1LongEnd speeds up significantly (~70%)
> encodeLatin1LongStart slows down (~20%)
> encodeLatin1Mixed speeds up by ~30%
>
> The remaining tests do not show much difference either way.
>
> Brett
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250728/9fc269c8/attachment-0001.htm>

From coleenp at openjdk.org  Mon Jul 28 20:19:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Jul 2025 20:19:31 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native
Message-ID: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>

This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
Tested with tier1-4.

-------------

Commit messages:
 - The only caller for getRawClassAccessFlags in Class.java doesn't call it for arrays so we really want the "raw" classfile access flags.
 - Add a comment
 - 8364187: Make getClassAccessFlagsRaw non-native

Changes: https://git.openjdk.org/jdk/pull/26517/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26517&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364187
  Stats: 98 lines in 16 files changed: 38 ins; 46 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/26517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26517/head:pull/26517

PR: https://git.openjdk.org/jdk/pull/26517

From liach at openjdk.org  Mon Jul 28 21:07:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Jul 2025 21:07:00 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v11]
In-Reply-To: <OQ2sjHpt-C0N9p8xrqcPj8p3QgfMsvDGL_VjXZEbG8M=.540d2bc1-c99b-40ce-877c-ad626c923250@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <l-0nLv2m8lEdI6wI7ukOFW4p-bDMASeWseu7gmYtUYU=.56c3fb4f-9d49-476d-91c3-e97e9bf89b73@github.com>
 <OQ2sjHpt-C0N9p8xrqcPj8p3QgfMsvDGL_VjXZEbG8M=.540d2bc1-c99b-40ce-877c-ad626c923250@github.com>
Message-ID: <_daElLoa9OY4GA4XulyLPcf23-SqZ1KkEGASLxUBz_s=.f34f362b-3a84-4b03-a27d-2e5db1b078a8@github.com>

On Thu, 24 Jul 2025 06:07:31 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 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
>
> Good fix.  I added some minor comments.  No logic changes requested!
> 
> I'm a little surprised to see the second annotation has survived; I'd prefer to see it totally nuked.  But I am not asking you to remove it; there is an argument that it is helpful.  I requested better documdentation and checking that the two annotations are properly interdependent.  The "runtime setup" annotation should not be allowed except in classes marked as AOT safe.
> 
> In a few places you removed an unrelated "non-public" comment.  That is not a good cleanup to incorporate in passing, since the comment is actually functional.
> 
> If somebody is arguing that such comments are somehow detrimental, let them make a separate argument and a separate PR to purge them.

@rose00 I have re-asserted that AOTRuntimeSetup requires AOTSafeCI as a prerequisite and rolled back `/*non-public/` comment changes. Can you re-review?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25922#issuecomment-3129885206

From brett.okken.os at gmail.com  Mon Jul 28 21:59:10 2025
From: brett.okken.os at gmail.com (Brett Okken)
Date: Mon, 28 Jul 2025 16:59:10 -0500
Subject: String encodeUTF8 latin1 with negatives
In-Reply-To: <ea368e23-83b4-4696-8325-b5edef5e5f62@oracle.com>
References: <CANBJVOFLAWc_XqqT9vK4m4F6UG6_My3QsrBqgo+odz3gih7OrQ@mail.gmail.com>
 <ea368e23-83b4-4696-8325-b5edef5e5f62@oracle.com>
Message-ID: <CANBJVOF_nUPE6RjSttxUpK6trOtGVi55TSBs7FEtSfU-0XMd_Q@mail.gmail.com>

Roger,

For a String, the byte[] val is immutable, right?
And even the current behavior of checking for negatives and then cloning
would not be safe in the face of a concurrent modification, right?
Is there something else going on here which I am missing?

Thanks,
Brett

On Mon, Jul 28, 2025 at 3:19?PM Roger Riggs <roger.riggs at oracle.com> wrote:

> Hi Brett,
>
> Extra care is needed if the input array might be modified concurrently
> with the method execution.
> When control flow decisions are made based on array contents, the
> integrity of the result depends on reading each byte of the array exactly
> once.
>
> Regards, Roger
>
>
>
> On 7/27/25 4:45 PM, Brett Okken wrote:
>
> In String.encodeUTF8, when the coder is latin1, there is a call to
> StringCoding.hasNegatives to determine if any special handling is needed.
> If not, a clone of the val is returned.
> If there are negative values, it then loops, from the beginning, through
> all the values to handle any individual negative values.
>
> Would it be better to call StringCoding.countPositives? If the result
> equals the length, the clone can still be returned. But if it does not, all
> the values which are positive can be simply copied to the target byte[] and
> only values beyond that point need to be checked again.
>
>
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L1287-L1300
>
>         if (!StringCoding.hasNegatives(val, 0, val.length)) {
>             return val.clone();
>         }
>
>         int dp = 0;
>         byte[] dst = StringUTF16.newBytesFor(val.length);
>         for (byte c : val) {
>             if (c < 0) {
>                 dst[dp++] = (byte) (0xc0 | ((c & 0xff) >> 6));
>                 dst[dp++] = (byte) (0x80 | (c & 0x3f));
>             } else {
>                 dst[dp++] = c;
>             }
>         }
>
>
> Can be changed to look like:
>
>         int positives = StringCoding.countPositives(val, 0, val.length);
>         if (positives == val.length) {
>             return val.clone();
>         }
>
>         int dp = positives;
>         byte[] dst = StringUTF16.newBytesFor(val.length);
>         if (positives > 0) {
>             System.arraycopy(val, 0, dst, 0, positives);
>         }
>         for (int i=dp; i<val.length; ++i) {
>             byte c = val[i];
>             if (c < 0) {
>                 dst[dp++] = (byte) (0xc0 | ((c & 0xff) >> 6));
>                 dst[dp++] = (byte) (0x80 | (c & 0x3f));
>             } else {
>                 dst[dp++] = c;
>             }
>         }
>
>
>
> I have done a bit of testing with the StringEncode jmh benchmark on my
> local windows device.
>
> encodeLatin1LongEnd speeds up significantly (~70%)
> encodeLatin1LongStart slows down (~20%)
> encodeLatin1Mixed speeds up by ~30%
>
> The remaining tests do not show much difference either way.
>
> Brett
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250728/08891dee/attachment-0001.htm>

From liach at openjdk.org  Mon Jul 28 22:00:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Jul 2025 22:00:59 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native
In-Reply-To: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
Message-ID: <pfIbYIcguGswbkbSOAMOVzWAOhUZSa3aajM6CNPPIq4=.8dcaa1a0-76f4-49b7-9601-e68d9a96c449@github.com>

On Mon, 28 Jul 2025 20:14:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
> Tested with tier1-4.

src/java.base/share/classes/java/lang/Class.java line 1012:

> 1010:     private transient Object[] signers; // Read by VM, mutable
> 1011:     private final transient char modifiers;  // Set by the VM
> 1012:     private final transient char rawAccessFlags;  // Set by the VM

I suggest `classFileFlags` in the spirit of `getClassFileVersion` - this is the flag on the JVMS 4 `ClassFile` structure, while the `modifiers` can be alternatively from `InnerClasses` attribute.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2237933184

From chen.l.liang at oracle.com  Mon Jul 28 22:25:48 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Mon, 28 Jul 2025 22:25:48 +0000
Subject: String encodeUTF8 latin1 with negatives
In-Reply-To: <CANBJVOF_nUPE6RjSttxUpK6trOtGVi55TSBs7FEtSfU-0XMd_Q@mail.gmail.com>
References: <CANBJVOFLAWc_XqqT9vK4m4F6UG6_My3QsrBqgo+odz3gih7OrQ@mail.gmail.com>
 <ea368e23-83b4-4696-8325-b5edef5e5f62@oracle.com>
 <CANBJVOF_nUPE6RjSttxUpK6trOtGVi55TSBs7FEtSfU-0XMd_Q@mail.gmail.com>
Message-ID: <SJ2PR10MB76692233ECEAE08EBC93931DA25AA@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Brett, you are right.

In the scenario Roger described, the current code would already be unsafe because the hasNegatives check and the clone copy are two distinct reads to each array element, between which a mutation can happen.

Roger is mainly concerned because byte[] with LATIN1 or UTF16 data exists not only in String, but also in StringBuilder, which has the problems Roger described.

Currently, these methods in the call hierarchy do not make it clear that they are not tolerant of mutable arrays.

It may be reasonable to mark the encoding methods as so with comments, or more simply, by converting them to private instance methods that always operate on String instances, making sure no invalid combinations of value-coder can ever pass through.

Chen
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Brett Okken <brett.okken.os at gmail.com>
Sent: Monday, July 28, 2025 4:59 PM
To: Roger Riggs <roger.riggs at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: String encodeUTF8 latin1 with negatives

Roger,

For a String, the byte[] val is immutable, right?
And even the current behavior of checking for negatives and then cloning would not be safe in the face of a concurrent modification, right?
Is there something else going on here which I am missing?

Thanks,
Brett

On Mon, Jul 28, 2025 at 3:19?PM Roger Riggs <roger.riggs at oracle.com<mailto:roger.riggs at oracle.com>> wrote:
Hi Brett,

Extra care is needed if the input array might be modified concurrently with the method execution.
When control flow decisions are made based on array contents, the integrity of the result depends on reading each byte of the array exactly once.

Regards, Roger



On 7/27/25 4:45 PM, Brett Okken wrote:
In String.encodeUTF8, when the coder is latin1, there is a call to StringCoding.hasNegatives to determine if any special handling is needed. If not, a clone of the val is returned.
If there are negative values, it then loops, from the beginning, through all the values to handle any individual negative values.

Would it be better to call StringCoding.countPositives? If the result equals the length, the clone can still be returned. But if it does not, all the values which are positive can be simply copied to the target byte[] and only values beyond that point need to be checked again.

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L1287-L1300

        if (!StringCoding.hasNegatives(val, 0, val.length)) {
            return val.clone();
        }

        int dp = 0;
        byte[] dst = StringUTF16.newBytesFor(val.length);
        for (byte c : val) {
            if (c < 0) {
                dst[dp++] = (byte) (0xc0 | ((c & 0xff) >> 6));
                dst[dp++] = (byte) (0x80 | (c & 0x3f));
            } else {
                dst[dp++] = c;
            }
        }


Can be changed to look like:

        int positives = StringCoding.countPositives(val, 0, val.length);
        if (positives == val.length) {
            return val.clone();
        }

        int dp = positives;
        byte[] dst = StringUTF16.newBytesFor(val.length);
        if (positives > 0) {
            System.arraycopy(val, 0, dst, 0, positives);
        }
        for (int i=dp; i<val.length; ++i) {
            byte c = val[i];
            if (c < 0) {
                dst[dp++] = (byte) (0xc0 | ((c & 0xff) >> 6));
                dst[dp++] = (byte) (0x80 | (c & 0x3f));
            } else {
                dst[dp++] = c;
            }
        }



I have done a bit of testing with the StringEncode jmh benchmark on my local windows device.

encodeLatin1LongEnd speeds up significantly (~70%)
encodeLatin1LongStart slows down (~20%)
encodeLatin1Mixed speeds up by ~30%

The remaining tests do not show much difference either way.

Brett





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250728/189c9eb0/attachment-0001.htm>

From brett.okken.os at gmail.com  Mon Jul 28 23:47:12 2025
From: brett.okken.os at gmail.com (Brett Okken)
Date: Mon, 28 Jul 2025 18:47:12 -0500
Subject: String encodeUTF8 latin1 with negatives
In-Reply-To: <SJ2PR10MB76692233ECEAE08EBC93931DA25AA@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CANBJVOFLAWc_XqqT9vK4m4F6UG6_My3QsrBqgo+odz3gih7OrQ@mail.gmail.com>
 <ea368e23-83b4-4696-8325-b5edef5e5f62@oracle.com>
 <CANBJVOF_nUPE6RjSttxUpK6trOtGVi55TSBs7FEtSfU-0XMd_Q@mail.gmail.com>
 <SJ2PR10MB76692233ECEAE08EBC93931DA25AA@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <CANBJVOH7ed=2c-DHtWGQYvbuX+0Z1S6K+2fpYeGV1uAknoNR7A@mail.gmail.com>

Chen,

Thanks for the clarification. The StringCoding methods are a bit light on
documentation, but presumably because of the package scope.

The specific method I am proposing a change to is a private method in
String.

Thanks,
Brett


On Mon, Jul 28, 2025 at 5:26?PM Chen Liang <chen.l.liang at oracle.com> wrote:

> Hi Brett, you are right.
>
> In the scenario Roger described, the current code would already be unsafe
> because the hasNegatives check and the clone copy are two distinct reads to
> each array element, between which a mutation can happen.
>
> Roger is mainly concerned because byte[] with LATIN1 or UTF16 data exists
> not only in String, but also in StringBuilder, which has the problems Roger
> described.
>
> Currently, these methods in the call hierarchy do not make it clear that
> they are not tolerant of mutable arrays.
>
> It may be reasonable to mark the encoding methods as so with comments, or
> more simply, by converting them to private instance methods that always
> operate on String instances, making sure no invalid combinations of
> value-coder can ever pass through.
>
> Chen
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Brett
> Okken <brett.okken.os at gmail.com>
> *Sent:* Monday, July 28, 2025 4:59 PM
> *To:* Roger Riggs <roger.riggs at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Re: String encodeUTF8 latin1 with negatives
>
> Roger,
>
> For a String, the byte[] val is immutable, right?
> And even the current behavior of checking for negatives and then cloning
> would not be safe in the face of a concurrent modification, right?
> Is there something else going on here which I am missing?
>
> Thanks,
> Brett
>
> On Mon, Jul 28, 2025 at 3:19?PM Roger Riggs <roger.riggs at oracle.com>
> wrote:
>
> Hi Brett,
>
> Extra care is needed if the input array might be modified concurrently
> with the method execution.
> When control flow decisions are made based on array contents, the
> integrity of the result depends on reading each byte of the array exactly
> once.
>
> Regards, Roger
>
>
>
> On 7/27/25 4:45 PM, Brett Okken wrote:
>
> In String.encodeUTF8, when the coder is latin1, there is a call to
> StringCoding.hasNegatives to determine if any special handling is needed.
> If not, a clone of the val is returned.
> If there are negative values, it then loops, from the beginning, through
> all the values to handle any individual negative values.
>
> Would it be better to call StringCoding.countPositives? If the result
> equals the length, the clone can still be returned. But if it does not, all
> the values which are positive can be simply copied to the target byte[] and
> only values beyond that point need to be checked again.
>
>
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L1287-L1300
>
>         if (!StringCoding.hasNegatives(val, 0, val.length)) {
>             return val.clone();
>         }
>
>         int dp = 0;
>         byte[] dst = StringUTF16.newBytesFor(val.length);
>         for (byte c : val) {
>             if (c < 0) {
>                 dst[dp++] = (byte) (0xc0 | ((c & 0xff) >> 6));
>                 dst[dp++] = (byte) (0x80 | (c & 0x3f));
>             } else {
>                 dst[dp++] = c;
>             }
>         }
>
>
> Can be changed to look like:
>
>         int positives = StringCoding.countPositives(val, 0, val.length);
>         if (positives == val.length) {
>             return val.clone();
>         }
>
>         int dp = positives;
>         byte[] dst = StringUTF16.newBytesFor(val.length);
>         if (positives > 0) {
>             System.arraycopy(val, 0, dst, 0, positives);
>         }
>         for (int i=dp; i<val.length; ++i) {
>             byte c = val[i];
>             if (c < 0) {
>                 dst[dp++] = (byte) (0xc0 | ((c & 0xff) >> 6));
>                 dst[dp++] = (byte) (0x80 | (c & 0x3f));
>             } else {
>                 dst[dp++] = c;
>             }
>         }
>
>
>
> I have done a bit of testing with the StringEncode jmh benchmark on my
> local windows device.
>
> encodeLatin1LongEnd speeds up significantly (~70%)
> encodeLatin1LongStart slows down (~20%)
> encodeLatin1Mixed speeds up by ~30%
>
> The remaining tests do not show much difference either way.
>
> Brett
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250728/bfde51d0/attachment.htm>

From jrose at openjdk.org  Tue Jul 29 01:54:17 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 29 Jul 2025 01:54:17 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v13]
In-Reply-To: <0NP8NQWEtvwY6osQkaxM2_OPSM8D1RrX-5fla0RmPkg=.63ebe03c-cf48-45db-b9bb-a82e1190edc5@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <0NP8NQWEtvwY6osQkaxM2_OPSM8D1RrX-5fla0RmPkg=.63ebe03c-cf48-45db-b9bb-a82e1190edc5@github.com>
Message-ID: <T2W0A5jcwk0nIKNIXtFqz-uDrYUQXQYyEJT5wll6B3M=.2f966afe-2b27-415b-81b2-05a032744fbf@github.com>

On Mon, 28 Jul 2025 19:06:13 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 28 commits:
> 
>  - aot safe markers for runtime setup
>  - 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
>  - Restore non-public comments
>  - 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
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/ea0b49c3...49f7bd5b

I sent you some updates to the javadocs.  Otherwise, everything is (still) ready to ship.

[Annotation-Javadoc-Updates.zip](https://github.com/user-attachments/files/21479022/Annotation-Javadoc-Updates.zip)

-------------

Changes requested by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-3064951754
PR Comment: https://git.openjdk.org/jdk/pull/25922#issuecomment-3130301216

From rgiulietti at openjdk.org  Tue Jul 29 11:09:00 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 29 Jul 2025 11:09:00 GMT
Subject: RFR: 8077587: BigInteger Roots [v52]
In-Reply-To: <t2eAfbylc3XKJlKP5VF5vtSpBqDbDTPUeA_ZihVMqto=.329be2d0-fb32-4cd1-919c-5901d9c5001f@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <t2eAfbylc3XKJlKP5VF5vtSpBqDbDTPUeA_ZihVMqto=.329be2d0-fb32-4cd1-919c-5901d9c5001f@github.com>
Message-ID: <y25IeAF03n6O8AV_sEAvbMPEnDF3n4uV5Ctjp5PXRoc=.e3a3a107-01c0-4395-92bf-dc01bff2e8a9@github.com>

On Mon, 28 Jul 2025 14:03:16 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Zimmermann suggestion

src/java.base/share/classes/java/math/MutableBigInteger.java line 2002:

> 2000:             // Try to shift as many bits as possible
> 2001:             // without losing precision in double's representation.
> 2002:             if (bitLength - (sh - shExcess) <= Double.MAX_EXPONENT) {

Here's an example of what I mean by "documenting the details"
Suggestion:

            if (bitLength - (sh - shExcess) <= Double.MAX_EXPONENT) {
                /*
                 * Let x = this, P = Double.PRECISION, ME = Double.MAX_EXPONENT,
                 * bl = bitLength, ex = shExcess, sh' = sh - ex
                 *
                 * We have
                 *      bl - (sh - ex) ? ME  ?  bl - (bl - P - ex) ? ME  ?  ex ? ME - P
                 * hence, recalling x < 2^bl
                 *      x 2^(-sh') = x 2^(ex-sh) = x 2^(-bl+ex+P) = x 2^(-bl) 2^(ex+P)
                 *          < 2^(ex+P) ? 2^ME < Double.MAX_VALUE
                 * Thus, x 2^(-sh') is in the range of finite doubles.
                 * All the more so, this holds for ?x / 2^sh'? ? x 2^(-sh'),
                 * which is what is computed below.
                 */

Without this, the reader has to reconstruct this "proof", which is arguably harder than just verifying its correctness.

OTOH, the statement "Adjust shift to a multiple of n" in the comment below is rather evident, and IMO does not need further explanations (but "mileage may vary" depending on the reader).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2239411008

From rgiulietti at openjdk.org  Tue Jul 29 11:09:00 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 29 Jul 2025 11:09:00 GMT
Subject: RFR: 8077587: BigInteger Roots [v52]
In-Reply-To: <y25IeAF03n6O8AV_sEAvbMPEnDF3n4uV5Ctjp5PXRoc=.e3a3a107-01c0-4395-92bf-dc01bff2e8a9@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <t2eAfbylc3XKJlKP5VF5vtSpBqDbDTPUeA_ZihVMqto=.329be2d0-fb32-4cd1-919c-5901d9c5001f@github.com>
 <y25IeAF03n6O8AV_sEAvbMPEnDF3n4uV5Ctjp5PXRoc=.e3a3a107-01c0-4395-92bf-dc01bff2e8a9@github.com>
Message-ID: <NAF6J0I2AVpj7B3xQTC90sQysMnAGN5tcob_6qwxGyk=.ee57ad2d-87b1-4e6e-be0c-3332a43cb9b1@github.com>

On Tue, 29 Jul 2025 11:03:24 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Zimmermann suggestion
>
> src/java.base/share/classes/java/math/MutableBigInteger.java line 2002:
> 
>> 2000:             // Try to shift as many bits as possible
>> 2001:             // without losing precision in double's representation.
>> 2002:             if (bitLength - (sh - shExcess) <= Double.MAX_EXPONENT) {
> 
> Here's an example of what I mean by "documenting the details"
> Suggestion:
> 
>             if (bitLength - (sh - shExcess) <= Double.MAX_EXPONENT) {
>                 /*
>                  * Let x = this, P = Double.PRECISION, ME = Double.MAX_EXPONENT,
>                  * bl = bitLength, ex = shExcess, sh' = sh - ex
>                  *
>                  * We have
>                  *      bl - (sh - ex) ? ME  ?  bl - (bl - P - ex) ? ME  ?  ex ? ME - P
>                  * hence, recalling x < 2^bl
>                  *      x 2^(-sh') = x 2^(ex-sh) = x 2^(-bl+ex+P) = x 2^(-bl) 2^(ex+P)
>                  *          < 2^(ex+P) ? 2^ME < Double.MAX_VALUE
>                  * Thus, x 2^(-sh') is in the range of finite doubles.
>                  * All the more so, this holds for ?x / 2^sh'? ? x 2^(-sh'),
>                  * which is what is computed below.
>                  */
> 
> Without this, the reader has to reconstruct this "proof", which is arguably harder than just verifying its correctness.
> 
> OTOH, the statement "Adjust shift to a multiple of n" in the comment below is rather evident, and IMO does not need further explanations (but "mileage may vary" depending on the reader).

The proof might help replacing the `if` condition bl - (sh - ex) ? ME with ex ? ME - P.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2239415806

From rgiulietti at openjdk.org  Tue Jul 29 11:17:00 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 29 Jul 2025 11:17:00 GMT
Subject: RFR: 8077587: BigInteger Roots [v52]
In-Reply-To: <NAF6J0I2AVpj7B3xQTC90sQysMnAGN5tcob_6qwxGyk=.ee57ad2d-87b1-4e6e-be0c-3332a43cb9b1@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <t2eAfbylc3XKJlKP5VF5vtSpBqDbDTPUeA_ZihVMqto=.329be2d0-fb32-4cd1-919c-5901d9c5001f@github.com>
 <y25IeAF03n6O8AV_sEAvbMPEnDF3n4uV5Ctjp5PXRoc=.e3a3a107-01c0-4395-92bf-dc01bff2e8a9@github.com>
 <NAF6J0I2AVpj7B3xQTC90sQysMnAGN5tcob_6qwxGyk=.ee57ad2d-87b1-4e6e-be0c-3332a43cb9b1@github.com>
Message-ID: <4fzk0PNrE0HPsFaimWxiuY3pfBOjXjMtNstCdqOoa84=.fac2dbd9-2521-480d-ae26-0361d2e0f389@github.com>

On Tue, 29 Jul 2025 11:05:43 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/MutableBigInteger.java line 2002:
>> 
>>> 2000:             // Try to shift as many bits as possible
>>> 2001:             // without losing precision in double's representation.
>>> 2002:             if (bitLength - (sh - shExcess) <= Double.MAX_EXPONENT) {
>> 
>> Here's an example of what I mean by "documenting the details"
>> Suggestion:
>> 
>>             if (bitLength - (sh - shExcess) <= Double.MAX_EXPONENT) {
>>                 /*
>>                  * Let x = this, P = Double.PRECISION, ME = Double.MAX_EXPONENT,
>>                  * bl = bitLength, ex = shExcess, sh' = sh - ex
>>                  *
>>                  * We have
>>                  *      bl - (sh - ex) ? ME  ?  bl - (bl - P - ex) ? ME  ?  ex ? ME - P
>>                  * hence, recalling x < 2^bl
>>                  *      x 2^(-sh') = x 2^(ex-sh) = x 2^(-bl+ex+P) = x 2^(-bl) 2^(ex+P)
>>                  *          < 2^(ex+P) ? 2^ME < Double.MAX_VALUE
>>                  * Thus, x 2^(-sh') is in the range of finite doubles.
>>                  * All the more so, this holds for ?x / 2^sh'? ? x 2^(-sh'),
>>                  * which is what is computed below.
>>                  */
>> 
>> Without this, the reader has to reconstruct this "proof", which is arguably harder than just verifying its correctness.
>> 
>> OTOH, the statement "Adjust shift to a multiple of n" in the comment below is rather evident, and IMO does not need further explanations (but "mileage may vary" depending on the reader).
>
> The proof might help replacing the `if` condition bl - (sh - ex) ? ME with ex ? ME - P.

To the above, we can also add

                 * 
                 * Noting that x ? 2^(bl-1) and ex ? 0, similarly to the above we further get
                 *      x 2^(-sh') ? 2^(ex+P-1) ? 2^(P-1)
                 * which shows that ?x / 2^sh'? has at least P bits of precision.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2239435080

From coleenp at openjdk.org  Tue Jul 29 12:02:14 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 29 Jul 2025 12:02:14 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native
In-Reply-To: <pfIbYIcguGswbkbSOAMOVzWAOhUZSa3aajM6CNPPIq4=.8dcaa1a0-76f4-49b7-9601-e68d9a96c449@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <pfIbYIcguGswbkbSOAMOVzWAOhUZSa3aajM6CNPPIq4=.8dcaa1a0-76f4-49b7-9601-e68d9a96c449@github.com>
Message-ID: <WaSIOivDQRRQnonz9wGKjhjtHhtDduz6boD7uMyM86Y=.e62e0a8c-0f0c-4e23-846f-3744707527fa@github.com>

On Mon, 28 Jul 2025 21:56:16 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
>> Tested with tier1-4.
>
> src/java.base/share/classes/java/lang/Class.java line 1012:
> 
>> 1010:     private transient Object[] signers; // Read by VM, mutable
>> 1011:     private final transient char modifiers;  // Set by the VM
>> 1012:     private final transient char rawAccessFlags;  // Set by the VM
> 
> I suggest `classFileFlags` in the spirit of `getClassFileVersion` - this is the flag on the JVMS 4 `ClassFile` structure, while the `modifiers` can be alternatively from `InnerClasses` attribute.

This is a good suggestion but I made it Raw to match getRawClassAnnotations this name.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2239571176

From duke at openjdk.org  Tue Jul 29 12:14:00 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Jul 2025 12:14:00 GMT
Subject: RFR: 8077587: BigInteger Roots [v52]
In-Reply-To: <4fzk0PNrE0HPsFaimWxiuY3pfBOjXjMtNstCdqOoa84=.fac2dbd9-2521-480d-ae26-0361d2e0f389@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <t2eAfbylc3XKJlKP5VF5vtSpBqDbDTPUeA_ZihVMqto=.329be2d0-fb32-4cd1-919c-5901d9c5001f@github.com>
 <y25IeAF03n6O8AV_sEAvbMPEnDF3n4uV5Ctjp5PXRoc=.e3a3a107-01c0-4395-92bf-dc01bff2e8a9@github.com>
 <NAF6J0I2AVpj7B3xQTC90sQysMnAGN5tcob_6qwxGyk=.ee57ad2d-87b1-4e6e-be0c-3332a43cb9b1@github.com>
 <4fzk0PNrE0HPsFaimWxiuY3pfBOjXjMtNstCdqOoa84=.fac2dbd9-2521-480d-ae26-0361d2e0f389@github.com>
Message-ID: <9aFNgADfBPmYg0xzUCI3kCt9q-a4i7uIXgLVxRyijWw=.4a32f24b-b1ae-477f-a19b-467a3d74228f@github.com>

On Tue, 29 Jul 2025 11:14:15 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> The proof might help replacing the `if` condition bl - (sh - ex) ? ME with ex ? ME - P.
>
> To the above, we can also add
> 
>                  * 
>                  * Noting that x ? 2^(bl-1) and ex ? 0, similarly to the above we further get
>                  *      x 2^(-sh') ? 2^(ex+P-1) ? 2^(P-1)
>                  * which shows that ?x / 2^sh'? has at least P bits of precision.

@rgiulietti Yes, but why that complication, it is not more natural to prove it in the following way?

recalling x < 2^bl:
x / 2^sh' = x / 2^(sh-ex) ? 2^bl / 2^(sh-ex) = 2^(bl - (sh-ex)) ? 2^ME < Double.MAX_VALUE
``` 
relying on the fact that `bl - (sh-ex)` is the length of the shifted value?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2239589611

From pminborg at openjdk.org  Tue Jul 29 12:21:59 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 29 Jul 2025 12:21:59 GMT
Subject: RFR: 8362893: Improve performance for MemorySegment::getString
In-Reply-To: <fMCUSc5XN29p0xsrgYnzmuLN6NVC2VPyKW2eWSN-XGg=.7aef213a-5ea1-4482-8064-887e4a0c7bf5@github.com>
References: <2Ylzaqh6EGpyeUXRRXrrDizXVqCghqobGmDHYEiTy0A=.078ad8e4-9eca-4ab6-86cd-60bf8b894201@github.com>
 <fMCUSc5XN29p0xsrgYnzmuLN6NVC2VPyKW2eWSN-XGg=.7aef213a-5ea1-4482-8064-887e4a0c7bf5@github.com>
Message-ID: <SEv3Le7-J8WdpI0pHSD1PfgunDTu82z9pFF2Q-VGcAg=.916fe3a6-b37b-471e-8d41-c7bc78e09c04@github.com>

On Mon, 28 Jul 2025 05:02:45 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> This optimization is not only needed within the JDK core library, but also by developers of basic class libraries and applications. This should be done by the C2 optimizer.

I suggest that we file a separate PR for C2 to fix all issues of this type and then continue with this PR as proposed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26493#issuecomment-3132227714

From duke at openjdk.org  Tue Jul 29 12:28:01 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Jul 2025 12:28:01 GMT
Subject: RFR: 8077587: BigInteger Roots [v52]
In-Reply-To: <9aFNgADfBPmYg0xzUCI3kCt9q-a4i7uIXgLVxRyijWw=.4a32f24b-b1ae-477f-a19b-467a3d74228f@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <t2eAfbylc3XKJlKP5VF5vtSpBqDbDTPUeA_ZihVMqto=.329be2d0-fb32-4cd1-919c-5901d9c5001f@github.com>
 <y25IeAF03n6O8AV_sEAvbMPEnDF3n4uV5Ctjp5PXRoc=.e3a3a107-01c0-4395-92bf-dc01bff2e8a9@github.com>
 <NAF6J0I2AVpj7B3xQTC90sQysMnAGN5tcob_6qwxGyk=.ee57ad2d-87b1-4e6e-be0c-3332a43cb9b1@github.com>
 <4fzk0PNrE0HPsFaimWxiuY3pfBOjXjMtNstCdqOoa84=.fac2dbd9-2521-480d-ae26-0361d2e0f389@github.com>
 <9aFNgADfBPmYg0xzUCI3kCt9q-a4i7uIXgLVxRyijWw=.4a32f24b-b1ae-477f-a19b-467a3d74228f@github.com>
Message-ID: <7EzdYtY7kawX6I8Acdx1Qk2CfsQeR8VP_eD6EKDaVLM=.5f737f45-c6f4-4a87-8ff9-e9b9482d6dca@github.com>

On Tue, 29 Jul 2025 12:06:37 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> To the above, we can also add
>> 
>>                  * 
>>                  * Noting that x ? 2^(bl-1) and ex ? 0, similarly to the above we further get
>>                  *      x 2^(-sh') ? 2^(ex+P-1) ? 2^(P-1)
>>                  * which shows that ?x / 2^sh'? has at least P bits of precision.
>
> @rgiulietti Yes, but why that complication, it is not more natural to prove it in the following way?
> 
> recalling x < 2^bl:
> x / 2^sh' = x / 2^(sh-ex) ? 2^bl / 2^(sh-ex) = 2^(bl - (sh-ex)) ? 2^ME < Double.MAX_VALUE
> ``` 
> relying on the fact that `bl - (sh-ex)` is the length of the shifted value?

> To the above, we can also add
> 
> ```
>                  * 
>                  * Noting that x ? 2^(bl-1) and ex ? 0, similarly to the above we further get
>                  *      x 2^(-sh') ? 2^(ex+P-1) ? 2^(P-1)
>                  * which shows that ?x / 2^sh'? has at least P bits of precision.
> ```

And this should follow by the fact that `bl - (sh-ex) ? bl - sh = bl - (bl - P) = P`, since `ex ? 0`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2239646258

From rgiulietti at openjdk.org  Tue Jul 29 13:07:00 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 29 Jul 2025 13:07:00 GMT
Subject: RFR: 8077587: BigInteger Roots [v52]
In-Reply-To: <7EzdYtY7kawX6I8Acdx1Qk2CfsQeR8VP_eD6EKDaVLM=.5f737f45-c6f4-4a87-8ff9-e9b9482d6dca@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <t2eAfbylc3XKJlKP5VF5vtSpBqDbDTPUeA_ZihVMqto=.329be2d0-fb32-4cd1-919c-5901d9c5001f@github.com>
 <y25IeAF03n6O8AV_sEAvbMPEnDF3n4uV5Ctjp5PXRoc=.e3a3a107-01c0-4395-92bf-dc01bff2e8a9@github.com>
 <NAF6J0I2AVpj7B3xQTC90sQysMnAGN5tcob_6qwxGyk=.ee57ad2d-87b1-4e6e-be0c-3332a43cb9b1@github.com>
 <4fzk0PNrE0HPsFaimWxiuY3pfBOjXjMtNstCdqOoa84=.fac2dbd9-2521-480d-ae26-0361d2e0f389@github.com>
 <9aFNgADfBPmYg0xzUCI3kCt9q-a4i7uIXgLVxRyijWw=.4a32f24b-b1ae-477f-a19b-467a3d74228f@github.com>
 <7EzdYtY7kawX6I8Acdx1Qk2CfsQeR8VP_eD6EKDaVLM=.5f737f45-c6f4-4a87-8ff9-e9b9482d6dca@github.com>
Message-ID: <8O9gYvHfBeeUNYIy3LlCXN5-XHp5o7MJOCCQS0i00eI=.5bbc5d33-e03a-4782-bd29-adcbee7ea467@github.com>

On Tue, 29 Jul 2025 12:25:21 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> @rgiulietti Yes, but why that complication, it is not more natural to prove it in the following way?
>> 
>> recalling x < 2^bl:
>> x / 2^sh' = x / 2^(sh-ex) ? 2^bl / 2^(sh-ex) = 2^(bl - (sh-ex)) ? 2^ME < Double.MAX_VALUE
>> ``` 
>> relying on the fact that `bl - (sh-ex)` is the length of the shifted value?
>
>> To the above, we can also add
>> 
>> ```
>>                  * 
>>                  * Noting that x ? 2^(bl-1) and ex ? 0, similarly to the above we further get
>>                  *      x 2^(-sh') ? 2^(ex+P-1) ? 2^(P-1)
>>                  * which shows that ?x / 2^sh'? has at least P bits of precision.
>> ```
> 
> And this should follow by the fact that `bl - (sh - ex) =  bl - (bl - P - ex) = P + ex`, since `ex ? 0`.

My point is that this should be done, not the exact form it takes. Mine or yours are both better than nothing.

Another point I wanted to make is that the `if` condition bl - (sh - ex) ? ME can be replaced with the simpler ex ? ME - P, whose right-hand side is a compile time constant.

> And this should follow by the fact that bl - (sh - ex) =  bl - (bl - P - ex) = P + ex, since ex ? 0.

To show that ?x / 2^sh'? has at least P bits of precision, I think you need to make use of x ? 2^(bl-1).

Anyway, I hope I made my point clear: it is better to write proofs rather than relying on readers to reverse-engineer them from the code. Surely, there's no need to be pedantic in every single detail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2239769849

From duke at openjdk.org  Tue Jul 29 13:19:03 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Jul 2025 13:19:03 GMT
Subject: RFR: 8077587: BigInteger Roots [v52]
In-Reply-To: <8O9gYvHfBeeUNYIy3LlCXN5-XHp5o7MJOCCQS0i00eI=.5bbc5d33-e03a-4782-bd29-adcbee7ea467@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <t2eAfbylc3XKJlKP5VF5vtSpBqDbDTPUeA_ZihVMqto=.329be2d0-fb32-4cd1-919c-5901d9c5001f@github.com>
 <y25IeAF03n6O8AV_sEAvbMPEnDF3n4uV5Ctjp5PXRoc=.e3a3a107-01c0-4395-92bf-dc01bff2e8a9@github.com>
 <NAF6J0I2AVpj7B3xQTC90sQysMnAGN5tcob_6qwxGyk=.ee57ad2d-87b1-4e6e-be0c-3332a43cb9b1@github.com>
 <4fzk0PNrE0HPsFaimWxiuY3pfBOjXjMtNstCdqOoa84=.fac2dbd9-2521-480d-ae26-0361d2e0f389@github.com>
 <9aFNgADfBPmYg0xzUCI3kCt9q-a4i7uIXgLVxRyijWw=.4a32f24b-b1ae-477f-a19b-467a3d74228f@github.com>
 <7EzdYtY7kawX6I8Acdx1Qk2CfsQeR8VP_eD6EKDaVLM=.5f737f45-c6f4-4a87-8ff9-e9b9482d6dca@github.com>
 <8O9gYvHfBeeUNYIy3LlCXN5-XHp5o7MJOCCQS0i00eI=.5bbc5d33-e03a-4782-bd29-adcbee7ea467@github.com>
Message-ID: <LEVdV4AU0PihZ7S_iwgriRzdZRWd-j-xqE0NzGH_IWw=.8125b572-edfe-4a5f-9769-4394ca5f0840@github.com>

On Tue, 29 Jul 2025 13:03:59 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Anyway, I hope I made my point clear: it is better to write proofs rather than relying on readers to reverse-engineer them from the code. Surely, there's no need to be pedantic in every single detail.

Surely, the problem is to understand what self-evident details to me, who wrote the code, could not be clear to others, and it is not that easy, even including comments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2239805158

From rriggs at openjdk.org  Tue Jul 29 13:27:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Jul 2025 13:27:56 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
Message-ID: <WObG1v-uiiW5td-qzSA06iRjh3U8fzfnKqX4DZf3gLE=.f63ef6b7-0e32-4345-8bec-24e7925b2b20@github.com>

On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)

If CCE should have a constructor with a message, it can be added if you have a clear idea how it would be used.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26413#issuecomment-3132536387

From duke at openjdk.org  Tue Jul 29 13:29:44 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Jul 2025 13:29:44 GMT
Subject: RFR: 8077587: BigInteger Roots [v53]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <jL2dsj3ar6FQpObI20OkD8fXSGNiaUgdBZd5VLNSBIM=.e58dd322-5ed4-45f2-85b9-da26018e102b@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Further documentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/31e5f890..885725ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=52
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=51-52

  Stats: 19 lines in 1 file changed: 17 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From duke at openjdk.org  Tue Jul 29 13:29:44 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Jul 2025 13:29:44 GMT
Subject: RFR: 8077587: BigInteger Roots [v52]
In-Reply-To: <8O9gYvHfBeeUNYIy3LlCXN5-XHp5o7MJOCCQS0i00eI=.5bbc5d33-e03a-4782-bd29-adcbee7ea467@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <t2eAfbylc3XKJlKP5VF5vtSpBqDbDTPUeA_ZihVMqto=.329be2d0-fb32-4cd1-919c-5901d9c5001f@github.com>
 <y25IeAF03n6O8AV_sEAvbMPEnDF3n4uV5Ctjp5PXRoc=.e3a3a107-01c0-4395-92bf-dc01bff2e8a9@github.com>
 <NAF6J0I2AVpj7B3xQTC90sQysMnAGN5tcob_6qwxGyk=.ee57ad2d-87b1-4e6e-be0c-3332a43cb9b1@github.com>
 <4fzk0PNrE0HPsFaimWxiuY3pfBOjXjMtNstCdqOoa84=.fac2dbd9-2521-480d-ae26-0361d2e0f389@github.com>
 <9aFNgADfBPmYg0xzUCI3kCt9q-a4i7uIXgLVxRyijWw=.4a32f24b-b1ae-477f-a19b-467a3d74228f@github.com>
 <7EzdYtY7kawX6I8Acdx1Qk2CfsQeR8VP_eD6EKDaVLM=.5f737f45-c6f4-4a87-8ff9-e9b9482d6dca@github.com>
 <8O9gYvHfBeeUNYIy3LlCXN5-XHp5o7MJOCCQS0i00eI=.5bbc5d33-e03a-4782-bd29-adcbee7ea467@github.com>
Message-ID: <LlOvdk8Dhl0k8DDr1RkiBt4xrv6S4hz1XUcl8V_cUTM=.918308f5-c52c-43f5-b919-a7642877ff01@github.com>

On Tue, 29 Jul 2025 13:03:59 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>>> To the above, we can also add
>>> 
>>> ```
>>>                  * 
>>>                  * Noting that x ? 2^(bl-1) and ex ? 0, similarly to the above we further get
>>>                  *      x 2^(-sh') ? 2^(ex+P-1) ? 2^(P-1)
>>>                  * which shows that ?x / 2^sh'? has at least P bits of precision.
>>> ```
>> 
>> And this should follow by the fact that `bl - (sh - ex) =  bl - (bl - P - ex) = P + ex`, since `ex ? 0`.
>
> My point is that this should be done, not the exact form it takes. Mine or yours are both better than nothing.
> 
> Another point I wanted to make is that the `if` condition bl - (sh - ex) ? ME can be replaced with the simpler ex ? ME - P, whose right-hand side is a compile time constant.
> 
>> And this should follow by the fact that bl - (sh - ex) =  bl - (bl - P - ex) = P + ex, since ex ? 0.
> 
> To show that ?x / 2^sh'? has at least P bits of precision, I think you need to make use of x ? 2^(bl-1).
> 
> Anyway, I hope I made my point clear: it is better to write proofs rather than relying on readers to reverse-engineer them from the code. Surely, there's no need to be pedantic in every single detail.

@rgiulietti Are there other points that are still not clear?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2239834907

From nbenalla at openjdk.org  Tue Jul 29 13:36:25 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 29 Jul 2025 13:36:25 GMT
Subject: RFR: 8358618: UnsupportedOperationException no-args constructor
 javadoc is not clear
Message-ID: <FCB3Dm42rtbmDto5TcsXSXBPl3Bo9yLLNq8i1PfGcPU=.cb826a32-eea5-48c9-8a96-b8f7bddfb45c@github.com>

Please review this patch that extends the javadoc of `UnsupportedOperationException` no-arg constructor, to clear up that the detail message is null.

-------------

Commit messages:
 - improve UOE javadoc

Changes: https://git.openjdk.org/jdk/pull/26533/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26533&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358618
  Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26533.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26533/head:pull/26533

PR: https://git.openjdk.org/jdk/pull/26533

From duke at openjdk.org  Tue Jul 29 13:38:03 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Jul 2025 13:38:03 GMT
Subject: RFR: 8077587: BigInteger Roots [v54]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <sDLarjclMNRUFBLZUm5b37bUQCWmrHxHBWj0qnU01E8=.eb6abe26-84e5-4ae8-ade8-73c081b73b4e@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  More comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/885725ca..9fe5c9c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=53
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=52-53

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From coleenp at openjdk.org  Tue Jul 29 13:43:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 29 Jul 2025 13:43:35 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
Message-ID: <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>

> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Rename getRawClassAccessFlags to getClassFileAccessFlags and fix the test to reflect what the JVM does.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26517/files
  - new: https://git.openjdk.org/jdk/pull/26517/files/b4daf731..163a8e5c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26517&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26517&range=00-01

  Stats: 57 lines in 6 files changed: 32 ins; 0 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/26517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26517/head:pull/26517

PR: https://git.openjdk.org/jdk/pull/26517

From duke at openjdk.org  Tue Jul 29 13:51:39 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Jul 2025 13:51:39 GMT
Subject: RFR: 8077587: BigInteger Roots [v55]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <BFSTZ0Y_Zbxhd0lkpfX2C76167XMpc9_J1NLXYMc4ic=.0242a32f-d504-4cf4-b19a-35e61c7ba3f2@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Comment abbreviations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/9fe5c9c3..a10fa4ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=54
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=53-54

  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From rgiulietti at openjdk.org  Tue Jul 29 13:51:39 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 29 Jul 2025 13:51:39 GMT
Subject: RFR: 8077587: BigInteger Roots [v52]
In-Reply-To: <LlOvdk8Dhl0k8DDr1RkiBt4xrv6S4hz1XUcl8V_cUTM=.918308f5-c52c-43f5-b919-a7642877ff01@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <t2eAfbylc3XKJlKP5VF5vtSpBqDbDTPUeA_ZihVMqto=.329be2d0-fb32-4cd1-919c-5901d9c5001f@github.com>
 <y25IeAF03n6O8AV_sEAvbMPEnDF3n4uV5Ctjp5PXRoc=.e3a3a107-01c0-4395-92bf-dc01bff2e8a9@github.com>
 <NAF6J0I2AVpj7B3xQTC90sQysMnAGN5tcob_6qwxGyk=.ee57ad2d-87b1-4e6e-be0c-3332a43cb9b1@github.com>
 <4fzk0PNrE0HPsFaimWxiuY3pfBOjXjMtNstCdqOoa84=.fac2dbd9-2521-480d-ae26-0361d2e0f389@github.com>
 <9aFNgADfBPmYg0xzUCI3kCt9q-a4i7uIXgLVxRyijWw=.4a32f24b-b1ae-477f-a19b-467a3d74228f@github.com>
 <7EzdYtY7kawX6I8Acdx1Qk2CfsQeR8VP_eD6EKDaVLM=.5f737f45-c6f4-4a87-8ff9-e9b9482d6dca@github.com>
 <8O9gYvHfBeeUNYIy3LlCXN5-XHp5o7MJOCCQS0i00eI=.5bbc5d33-e03a-4782-bd29-adcbee7ea467@github.com>
 <LlOvdk8Dhl0k8DDr1RkiBt4xrv6S4hz1XUcl8V_cUTM=.918308f5-c52c-43f5-b919-a7642877ff01@github.com>
Message-ID: <Plxn7dFDwG-lbM4MrfewFGieQYRgqXMv1JyLAoeeXhM=.b6e82e18-f401-46da-a77f-48365db92ad8@github.com>

On Tue, 29 Jul 2025 13:26:41 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> My point is that this should be done, not the exact form it takes. Mine or yours are both better than nothing.
>> 
>> Another point I wanted to make is that the `if` condition bl - (sh - ex) ? ME can be replaced with the simpler ex ? ME - P, whose right-hand side is a compile time constant.
>> 
>>> And this should follow by the fact that bl - (sh - ex) =  bl - (bl - P - ex) = P + ex, since ex ? 0.
>> 
>> To show that ?x / 2^sh'? has at least P bits of precision, I think you need to make use of x ? 2^(bl-1).
>> 
>> Anyway, I hope I made my point clear: it is better to write proofs rather than relying on readers to reverse-engineer them from the code. Surely, there's no need to be pedantic in every single detail.
>
> @rgiulietti Are there other points that are still not clear?

Well, that was the easy case!
(BTW, the condition shExcess != 0 on L.2025 is always true, as shExcess > Double.MAX_EXPONENT - Double.PRECISION there.)

There should be similar reasoning for the `else` part on L.2020.

And, more importantly so, for the more obscure parts (for a 1st time reader, not for the author ;-) ) starting at L.2034. This is the code that took most of my time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2239897015

From liach at openjdk.org  Tue Jul 29 13:56:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Jul 2025 13:56:04 GMT
Subject: RFR: 8358618: UnsupportedOperationException no-args constructor
 javadoc is not clear
In-Reply-To: <FCB3Dm42rtbmDto5TcsXSXBPl3Bo9yLLNq8i1PfGcPU=.cb826a32-eea5-48c9-8a96-b8f7bddfb45c@github.com>
References: <FCB3Dm42rtbmDto5TcsXSXBPl3Bo9yLLNq8i1PfGcPU=.cb826a32-eea5-48c9-8a96-b8f7bddfb45c@github.com>
Message-ID: <yf7-4U9aOFmUnn-GBwmD_b8eU_3yO0LDYaOIzD1st2s=.19f98a4a-4b1b-4783-b0b0-5677301499a5@github.com>

On Tue, 29 Jul 2025 12:54:56 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch that extends the javadoc of `UnsupportedOperationException` no-arg constructor, to clear up that the detail message is null.

Reviewed the CSR for the new assertion that the detail message is `null`.

src/java.base/share/classes/java/lang/RuntimeException.java line 47:

> 45:     static final long serialVersionUID = -7034897190745766939L;
> 46: 
> 47:     /** Constructs a new {@code RuntimeException} with {@code null} as its

All other constructors use "a new runtime exception". I suggest consistency for all constructors.

src/java.base/share/classes/java/lang/UnsupportedOperationException.java line 40:

> 38: public class UnsupportedOperationException extends RuntimeException {
> 39:     /**
> 40:      * Constructs a new {@code UnsupportedOperationException} with {@code null} as its

Similar consistency request for all constructors. Note the two cause-accepting constructors use "a new exception" which may be better updated to what you have here.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26533#pullrequestreview-3067655550
PR Review Comment: https://git.openjdk.org/jdk/pull/26533#discussion_r2239906599
PR Review Comment: https://git.openjdk.org/jdk/pull/26533#discussion_r2239909242

From duke at openjdk.org  Tue Jul 29 13:58:02 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Jul 2025 13:58:02 GMT
Subject: RFR: 8077587: BigInteger Roots [v52]
In-Reply-To: <Plxn7dFDwG-lbM4MrfewFGieQYRgqXMv1JyLAoeeXhM=.b6e82e18-f401-46da-a77f-48365db92ad8@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <t2eAfbylc3XKJlKP5VF5vtSpBqDbDTPUeA_ZihVMqto=.329be2d0-fb32-4cd1-919c-5901d9c5001f@github.com>
 <y25IeAF03n6O8AV_sEAvbMPEnDF3n4uV5Ctjp5PXRoc=.e3a3a107-01c0-4395-92bf-dc01bff2e8a9@github.com>
 <NAF6J0I2AVpj7B3xQTC90sQysMnAGN5tcob_6qwxGyk=.ee57ad2d-87b1-4e6e-be0c-3332a43cb9b1@github.com>
 <4fzk0PNrE0HPsFaimWxiuY3pfBOjXjMtNstCdqOoa84=.fac2dbd9-2521-480d-ae26-0361d2e0f389@github.com>
 <9aFNgADfBPmYg0xzUCI3kCt9q-a4i7uIXgLVxRyijWw=.4a32f24b-b1ae-477f-a19b-467a3d74228f@github.com>
 <7EzdYtY7kawX6I8Acdx1Qk2CfsQeR8VP_eD6EKDaVLM=.5f737f45-c6f4-4a87-8ff9-e9b9482d6dca@github.com>
 <8O9gYvHfBeeUNYIy3LlCXN5-XHp5o7MJOCCQS0i00eI=.5bbc5d33-e03a-4782-bd29-adcbee7ea467@github.com>
 <LlOvdk8Dhl0k8DDr1RkiBt4xrv6S4hz1XUcl8V_cUTM=.918308f5-c52c-43f5-b919-a7642877ff01@github.com>
 <Plxn7dFDwG-lbM4MrfewFGieQYRgqXMv1JyLAoeeXhM=.b6e82e18-f401-46da-a77f-48365db92ad8@github.com>
Message-ID: <XGzY4D4iITvWVwpcCXzZC7xb62OSXe1lBOwHHQ6MgNA=.e92ea912-1640-4971-9241-89086c615894@github.com>

On Tue, 29 Jul 2025 13:48:47 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> starting at L.2034. This is the code that took most of my time.

And at what line the obscure parts end?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2239917951

From rgiulietti at openjdk.org  Tue Jul 29 14:10:01 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 29 Jul 2025 14:10:01 GMT
Subject: RFR: 8077587: BigInteger Roots [v52]
In-Reply-To: <XGzY4D4iITvWVwpcCXzZC7xb62OSXe1lBOwHHQ6MgNA=.e92ea912-1640-4971-9241-89086c615894@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <t2eAfbylc3XKJlKP5VF5vtSpBqDbDTPUeA_ZihVMqto=.329be2d0-fb32-4cd1-919c-5901d9c5001f@github.com>
 <y25IeAF03n6O8AV_sEAvbMPEnDF3n4uV5Ctjp5PXRoc=.e3a3a107-01c0-4395-92bf-dc01bff2e8a9@github.com>
 <NAF6J0I2AVpj7B3xQTC90sQysMnAGN5tcob_6qwxGyk=.ee57ad2d-87b1-4e6e-be0c-3332a43cb9b1@github.com>
 <4fzk0PNrE0HPsFaimWxiuY3pfBOjXjMtNstCdqOoa84=.fac2dbd9-2521-480d-ae26-0361d2e0f389@github.com>
 <9aFNgADfBPmYg0xzUCI3kCt9q-a4i7uIXgLVxRyijWw=.4a32f24b-b1ae-477f-a19b-467a3d74228f@github.com>
 <7EzdYtY7kawX6I8Acdx1Qk2CfsQeR8VP_eD6EKDaVLM=.5f737f45-c6f4-4a87-8ff9-e9b9482d6dca@github.com>
 <8O9gYvHfBeeUNYIy3LlCXN5-XHp5o7MJOCCQS0i00eI=.5bbc5d33-e03a-4782-bd29-adcbee7ea467@github.com>
 <LlOvdk8Dhl0k8DDr1RkiBt4xrv6S4hz1XUcl8V_cUTM=.918308f5-c52c-43f5-b919-a7642877ff01@github.com>
 <Plxn7dFDwG-lbM4MrfewFGieQYRgqXMv1JyLAoeeXhM=.b6e82e18-f401-46da-a77f-48365db92ad8@github.com>
 <XGzY4D4iITvWVwpcCXzZC7xb62OSXe1lBOw
 HHQ6MgNA=.e92ea912-1640-4971-9241-89086c615894@github.com>
Message-ID: <TeFMPsT61isws-XLeTgXpyLdPabjGv3886MKoRnS-DM=.71449059-3cd8-4b04-bcf1-31c2fbfecd20@github.com>

On Tue, 29 Jul 2025 13:55:08 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Well, that was the easy case!
>> (BTW, the condition shExcess != 0 on L.2025 is always true, as shExcess > Double.MAX_EXPONENT - Double.PRECISION there.)
>> 
>> There should be similar reasoning for the `else` part on L.2020.
>> 
>> And, more importantly so, for the more obscure parts (for a 1st time reader, not for the author ;-) ) starting at L.2034. This is the code that took most of my time.
>
>> starting at L.2034. This is the code that took most of my time.
> 
> @rgiulietti And at what line the obscure parts end?

Ah sorry, it ends at L.2073, with the end of the loop.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2239970773

From duke at openjdk.org  Tue Jul 29 14:19:20 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Jul 2025 14:19:20 GMT
Subject: RFR: 8077587: BigInteger Roots [v56]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <wWIEDCrLmhGUmeGzFbU0kDpAgATW2woK8ApXXGvm04k=.7f484418-9746-46d2-a6b6-c439e7a5ceae@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/a10fa4ea..6a3625e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=55
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=54-55

  Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From duke at openjdk.org  Tue Jul 29 14:22:06 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Jul 2025 14:22:06 GMT
Subject: RFR: 8077587: BigInteger Roots [v56]
In-Reply-To: <wWIEDCrLmhGUmeGzFbU0kDpAgATW2woK8ApXXGvm04k=.7f484418-9746-46d2-a6b6-c439e7a5ceae@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <wWIEDCrLmhGUmeGzFbU0kDpAgATW2woK8ApXXGvm04k=.7f484418-9746-46d2-a6b6-c439e7a5ceae@github.com>
Message-ID: <FL6CVK34z9ODWMJGcexA_-D0oVUypXbdGpAr1U_gtiU=.15a56476-eb9f-468d-a4b2-f9f400f39334@github.com>

On Tue, 29 Jul 2025 14:19:20 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment

src/java.base/share/classes/java/math/MutableBigInteger.java line 2022:

> 2020:             } else { // x >> (sh-ex) could exceed finite double range, may lose precision
> 2021:                 // Shift the value into finite double range
> 2022:                 // x >> sh < 2^(bl-sh) = 2^(bl-(bl-P)) = 2^P < Double.MAX_VALUE

@rgiulietti By the comment in the then-case, I think this is sufficient to understand.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2240011576

From rriggs at openjdk.org  Tue Jul 29 14:26:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Jul 2025 14:26:56 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
Message-ID: <13urR68f8U8oqjrcaX1BtKI-EtD41ySuYt-oz333PdA=.c97d8293-2fbe-415d-983d-92b7e1c9d175@github.com>

On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)

src/java.base/share/classes/java/lang/String.java line 571:

> 569:     }
> 570: 
> 571:     private static String utf8ThrowingIae(byte[] bytes, int offset, int length) {

Iae should be all-caps. `IAE`

src/java.base/share/classes/java/lang/String.java line 579:

> 577:     }
> 578: 
> 579:     private static IllegalArgumentException cce2iae(CharacterCodingException cce) {

More readable would be "cceToIAE"
But this whole construct is suspect because of the contortions needed.

src/java.base/share/classes/java/lang/String.java line 1289:

> 1287:     }
> 1288: 
> 1289:     private static void throwMalformed(byte[] val) throws MalformedInputException {

It is unnecessary to add add @throws of RuntimeExceptions, conventionally they are omitted as clutter and any RuntimeException can be thrown at any time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2237974608
PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2239826290
PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2239865577

From rriggs at openjdk.org  Tue Jul 29 14:26:58 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Jul 2025 14:26:58 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <UA0pGbsuzu3uVXQiMX6bXjQOdbpmnAhVOyR1tuk5mEo=.327cbc19-fd65-40af-89a0-fd19c65d4672@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <UA0pGbsuzu3uVXQiMX6bXjQOdbpmnAhVOyR1tuk5mEo=.327cbc19-fd65-40af-89a0-fd19c65d4672@github.com>
Message-ID: <vpm4fE0UvlmqWd-E9O2vT_Me8_I6q0DRwGvFnEBO76E=.5a14fcac-a1c4-42be-8f83-a361ddd2e92f@github.com>

On Mon, 21 Jul 2025 12:19:11 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)
>
> src/java.base/share/classes/java/lang/String.java line 1262:
> 
>> 1260:         MalformedInputException mie = new MalformedInputException(nb);
>> 1261:         String msg = "malformed input off : " + off + ", length : " + nb;
>> 1262:         mie.initCause(new IllegalArgumentException(msg));
> 
> Earlier `throw(Malformed|Unmappable)` methods were throwing `IAE` containing _extra diagnostics information_ and wrapping a `CCE` as a cause. After switching methods to throw `CCE`, which doesn't have a ctor accepting a `String` message, to retain this extra diagnostics information, I've added swapped their causal chain placement, and wrapped `IAE` with a `CCE` this time.
> 
> This played well with `CCE`-throwing methods, yet there are other `public` methods which did not have `throws CCE` in their footprint. For backward compatibility, in those spots, I've used `cce2iae` to obtain, again, a `IAE` wrapping the `CCE`, which matched the old behavior.

Introducing CCE (an IOException) into more places in string handling is going in the wrong direction.
As declared exceptions, they have to be caught and handled or re-thrown. That makes the source more complex and harder to maintain, as seen in the cce2iae mechanism.
The prior use of IAE encapsulating a CCE as needed is simpler and more consistent with other Runtime exception handling in most of the String class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2240031460

From liach at openjdk.org  Tue Jul 29 14:36:08 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Jul 2025 14:36:08 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v6]
In-Reply-To: <JdxWpCBHtTssvz1lu08gRSrJr3So7vxoi5hiopLlxLo=.3931a767-c13c-455a-b631-616cbbd250ff@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <JdxWpCBHtTssvz1lu08gRSrJr3So7vxoi5hiopLlxLo=.3931a767-c13c-455a-b631-616cbbd250ff@github.com>
Message-ID: <wO8-ffEYIJdsOSU4I3G_wyj7z7yuQ9GOrNPYlkEfUdM=.883fda69-2b75-4b49-b531-e1d2736e6eac@github.com>

On Mon, 16 Jun 2025 21:19:45 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>> 
>> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
>> 
>> Testing:
>> - GHA
>> - Local run of tier 2 and jtreg:jdk/java/text
>> - New benchmark: DecimalFormatParseBench
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

@rgiulietti Would you mind reviewing this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25644#issuecomment-3132838883

From nbenalla at openjdk.org  Tue Jul 29 14:37:10 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 29 Jul 2025 14:37:10 GMT
Subject: RFR: 8358618: UnsupportedOperationException no-args constructor
 javadoc is not clear [v2]
In-Reply-To: <FCB3Dm42rtbmDto5TcsXSXBPl3Bo9yLLNq8i1PfGcPU=.cb826a32-eea5-48c9-8a96-b8f7bddfb45c@github.com>
References: <FCB3Dm42rtbmDto5TcsXSXBPl3Bo9yLLNq8i1PfGcPU=.cb826a32-eea5-48c9-8a96-b8f7bddfb45c@github.com>
Message-ID: <RQb8GqS0XDav5lSifF_PwygXGwG1UBdPLqmkxZrK-uU=.e36423d1-9b15-4adb-8ad3-a9c3fc19d7e0@github.com>

> Please review this patch that extends the javadoc of `UnsupportedOperationException` no-arg constructor, to clear up that the detail message is null.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  review comments about consistency

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26533/files
  - new: https://git.openjdk.org/jdk/pull/26533/files/7ec75a40..f1a2e8c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26533&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26533&range=00-01

  Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26533.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26533/head:pull/26533

PR: https://git.openjdk.org/jdk/pull/26533

From liach at openjdk.org  Tue Jul 29 14:37:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Jul 2025 14:37:59 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <WaSIOivDQRRQnonz9wGKjhjtHhtDduz6boD7uMyM86Y=.e62e0a8c-0f0c-4e23-846f-3744707527fa@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <pfIbYIcguGswbkbSOAMOVzWAOhUZSa3aajM6CNPPIq4=.8dcaa1a0-76f4-49b7-9601-e68d9a96c449@github.com>
 <WaSIOivDQRRQnonz9wGKjhjtHhtDduz6boD7uMyM86Y=.e62e0a8c-0f0c-4e23-846f-3744707527fa@github.com>
Message-ID: <h0k-2CPFK6Zh2eVLqfuvVDUmxXo5Drkgo-0XVM85A3s=.9b435eba-01c4-4dd3-933b-ed0cdb89187a@github.com>

On Tue, 29 Jul 2025 11:58:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 1012:
>> 
>>> 1010:     private transient Object[] signers; // Read by VM, mutable
>>> 1011:     private final transient char modifiers;  // Set by the VM
>>> 1012:     private final transient char rawAccessFlags;  // Set by the VM
>> 
>> I suggest `classFileFlags` in the spirit of `getClassFileVersion` - this is the flag on the JVMS 4 `ClassFile` structure, while the `modifiers` can be alternatively from `InnerClasses` attribute.
>
> This is a good suggestion but I made it Raw to match getRawClassAnnotations this name.

Thanks for the rename. I think `raw annotations` means the uninterpreted byte data in the attribute is carried over raw; this concept is less applicable to the access_flags u2 value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2240075254

From rgiulietti at openjdk.org  Tue Jul 29 14:42:01 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 29 Jul 2025 14:42:01 GMT
Subject: RFR: 8077587: BigInteger Roots [v56]
In-Reply-To: <FL6CVK34z9ODWMJGcexA_-D0oVUypXbdGpAr1U_gtiU=.15a56476-eb9f-468d-a4b2-f9f400f39334@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <wWIEDCrLmhGUmeGzFbU0kDpAgATW2woK8ApXXGvm04k=.7f484418-9746-46d2-a6b6-c439e7a5ceae@github.com>
 <FL6CVK34z9ODWMJGcexA_-D0oVUypXbdGpAr1U_gtiU=.15a56476-eb9f-468d-a4b2-f9f400f39334@github.com>
Message-ID: <U6oXHJOs4V3r3HH1LvQ0GpvLs1s4c-O3ZaRPKgQFEBI=.7c1e0da3-bc30-4a47-bf00-a9f40134bd7b@github.com>

On Tue, 29 Jul 2025 14:19:19 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comment
>
> src/java.base/share/classes/java/math/MutableBigInteger.java line 2022:
> 
>> 2020:             } else { // x >> (sh-ex) could exceed finite double range, may lose precision
>> 2021:                 // Shift the value into finite double range
>> 2022:                 // x >> sh < 2^(bl-sh) = 2^(bl-(bl-P)) = 2^P < Double.MAX_VALUE
> 
> @rgiulietti By the comment in the then-case, I think this is sufficient to understand.

Here we have a kind of opposite case: rad can become very imprecise, up to losing all bits from x and become 0.
I think this deserves a quick comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2240080558

From duke at openjdk.org  Tue Jul 29 14:42:02 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Jul 2025 14:42:02 GMT
Subject: RFR: 8077587: BigInteger Roots [v56]
In-Reply-To: <U6oXHJOs4V3r3HH1LvQ0GpvLs1s4c-O3ZaRPKgQFEBI=.7c1e0da3-bc30-4a47-bf00-a9f40134bd7b@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <wWIEDCrLmhGUmeGzFbU0kDpAgATW2woK8ApXXGvm04k=.7f484418-9746-46d2-a6b6-c439e7a5ceae@github.com>
 <FL6CVK34z9ODWMJGcexA_-D0oVUypXbdGpAr1U_gtiU=.15a56476-eb9f-468d-a4b2-f9f400f39334@github.com>
 <U6oXHJOs4V3r3HH1LvQ0GpvLs1s4c-O3ZaRPKgQFEBI=.7c1e0da3-bc30-4a47-bf00-a9f40134bd7b@github.com>
Message-ID: <rTLzSQ0o3ZVHPuO2Xjy69LQGHwzrjHN4PwWE3fNnU90=.402a7a3b-4dca-4173-8b54-6f5584689a75@github.com>

On Tue, 29 Jul 2025 14:36:57 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Here we have a kind of opposite case: rad can become very imprecise, up to losing all bits from x and become 0. I think this deserves a quick comment.

Later there is `rad = Math.nextUp(rad)`, that ensures `rad > 0.0`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2240085390

From rgiulietti at openjdk.org  Tue Jul 29 14:42:59 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 29 Jul 2025 14:42:59 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v6]
In-Reply-To: <JdxWpCBHtTssvz1lu08gRSrJr3So7vxoi5hiopLlxLo=.3931a767-c13c-455a-b631-616cbbd250ff@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <JdxWpCBHtTssvz1lu08gRSrJr3So7vxoi5hiopLlxLo=.3931a767-c13c-455a-b631-616cbbd250ff@github.com>
Message-ID: <nN4VjZFkM_5rrfLABolpsnQF0M3Ae9RbkPRFZYIoS6o=.ebf2fef7-e104-452c-ad98-6417f66206eb@github.com>

On Mon, 16 Jun 2025 21:19:45 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>> 
>> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
>> 
>> Testing:
>> - GHA
>> - Local run of tier 2 and jtreg:jdk/java/text
>> - New benchmark: DecimalFormatParseBench
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

Ah yes, I'll take a look at latest tomorrow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25644#issuecomment-3132865733

From aivanov at openjdk.org  Tue Jul 29 14:48:04 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 29 Jul 2025 14:48:04 GMT
Subject: RFR: 8358618: UnsupportedOperationException no-args constructor
 javadoc is not clear [v2]
In-Reply-To: <RQb8GqS0XDav5lSifF_PwygXGwG1UBdPLqmkxZrK-uU=.e36423d1-9b15-4adb-8ad3-a9c3fc19d7e0@github.com>
References: <FCB3Dm42rtbmDto5TcsXSXBPl3Bo9yLLNq8i1PfGcPU=.cb826a32-eea5-48c9-8a96-b8f7bddfb45c@github.com>
 <RQb8GqS0XDav5lSifF_PwygXGwG1UBdPLqmkxZrK-uU=.e36423d1-9b15-4adb-8ad3-a9c3fc19d7e0@github.com>
Message-ID: <BhfkC_6-rtrE2HjlteNV4Wqcq0Hpu86MWbX4nAABG6I=.686f45af-854c-4e92-96e7-1711912884df@github.com>

On Tue, 29 Jul 2025 14:37:10 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this patch that extends the javadoc of `UnsupportedOperationException` no-arg constructor, to clear up that the detail message is null.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments about consistency

Changes requested by aivanov (Reviewer).

src/java.base/share/classes/java/lang/UnsupportedOperationException.java line 49:

> 47:     /**
> 48:      * Constructs a new {@code UnsupportedOperationException} with the specified
> 49:      * detail message.

I think it makes sense to expand the description of this constructor with `?The cause is not initialized, and may subsequently be initialized by a call to {@link #initCause(Throwable)}.?` as per no-arg constructor.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26533#pullrequestreview-3067935684
PR Review Comment: https://git.openjdk.org/jdk/pull/26533#discussion_r2240103648

From rgiulietti at openjdk.org  Tue Jul 29 14:48:06 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 29 Jul 2025 14:48:06 GMT
Subject: RFR: 8077587: BigInteger Roots [v56]
In-Reply-To: <rTLzSQ0o3ZVHPuO2Xjy69LQGHwzrjHN4PwWE3fNnU90=.402a7a3b-4dca-4173-8b54-6f5584689a75@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <wWIEDCrLmhGUmeGzFbU0kDpAgATW2woK8ApXXGvm04k=.7f484418-9746-46d2-a6b6-c439e7a5ceae@github.com>
 <FL6CVK34z9ODWMJGcexA_-D0oVUypXbdGpAr1U_gtiU=.15a56476-eb9f-468d-a4b2-f9f400f39334@github.com>
 <U6oXHJOs4V3r3HH1LvQ0GpvLs1s4c-O3ZaRPKgQFEBI=.7c1e0da3-bc30-4a47-bf00-a9f40134bd7b@github.com>
 <rTLzSQ0o3ZVHPuO2Xjy69LQGHwzrjHN4PwWE3fNnU90=.402a7a3b-4dca-4173-8b54-6f5584689a75@github.com>
Message-ID: <3UAU5OZfdeXPiZVd86R5NGNLozOrVVF200e4Izo_0q4=.b0f02376-b836-4c23-a77d-bba89d5dd475@github.com>

On Tue, 29 Jul 2025 14:38:40 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Here we have a kind of opposite case: rad can become very imprecise, up to losing all bits from x and become 0.
>> I think this deserves a quick comment.
>
>> Here we have a kind of opposite case: rad can become very imprecise, up to losing all bits from x and become 0. I think this deserves a quick comment.
> 
> Later there is `rad = Math.nextUp(rad)`, that ensures `rad > 0.0`.

Sure.

But L.2024-25 read

                // Complete the shift to a multiple of n,
                // avoiding to lose more bits than necessary.

which is a bit misleading, as it seems there's some hope that some bits can be preserved, which is not completely true.

The comment can be as succinct as a one liner, so it is worthwhile IMO.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2240102989

From nbenalla at openjdk.org  Tue Jul 29 14:56:58 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 29 Jul 2025 14:56:58 GMT
Subject: RFR: 8358618: UnsupportedOperationException no-args constructor
 javadoc is not clear [v2]
In-Reply-To: <BhfkC_6-rtrE2HjlteNV4Wqcq0Hpu86MWbX4nAABG6I=.686f45af-854c-4e92-96e7-1711912884df@github.com>
References: <FCB3Dm42rtbmDto5TcsXSXBPl3Bo9yLLNq8i1PfGcPU=.cb826a32-eea5-48c9-8a96-b8f7bddfb45c@github.com>
 <RQb8GqS0XDav5lSifF_PwygXGwG1UBdPLqmkxZrK-uU=.e36423d1-9b15-4adb-8ad3-a9c3fc19d7e0@github.com>
 <BhfkC_6-rtrE2HjlteNV4Wqcq0Hpu86MWbX4nAABG6I=.686f45af-854c-4e92-96e7-1711912884df@github.com>
Message-ID: <TZWzr3Q0SgUIc6tGOTzJKiTiZhIH6b2JHhxjf2MzTqo=.582a3510-0b0a-4ffe-aa7e-e64e760a5871@github.com>

On Tue, 29 Jul 2025 14:44:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments about consistency
>
> src/java.base/share/classes/java/lang/UnsupportedOperationException.java line 49:
> 
>> 47:     /**
>> 48:      * Constructs a new {@code UnsupportedOperationException} with the specified
>> 49:      * detail message.
> 
> I think it makes sense to expand the description of this constructor with `?The cause is not initialized, and may subsequently be initialized by a call to {@link #initCause(Throwable)}.?` as per no-arg constructor.

Thanks for the suggestion!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26533#discussion_r2240131490

From nbenalla at openjdk.org  Tue Jul 29 15:00:11 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 29 Jul 2025 15:00:11 GMT
Subject: RFR: 8358618: UnsupportedOperationException no-args constructor
 javadoc is not clear [v3]
In-Reply-To: <FCB3Dm42rtbmDto5TcsXSXBPl3Bo9yLLNq8i1PfGcPU=.cb826a32-eea5-48c9-8a96-b8f7bddfb45c@github.com>
References: <FCB3Dm42rtbmDto5TcsXSXBPl3Bo9yLLNq8i1PfGcPU=.cb826a32-eea5-48c9-8a96-b8f7bddfb45c@github.com>
Message-ID: <fQlxwTv2P4mOsfMCzkBosXe9KdE0x3b6BWtHp_BoIxs=.6e538e5a-a8c5-40a7-a3c7-12cd4903d903@github.com>

> Please review this patch that extends the javadoc of `UnsupportedOperationException` no-arg constructor, to clear up that the detail message is null.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Feedback from Alexey.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26533/files
  - new: https://git.openjdk.org/jdk/pull/26533/files/f1a2e8c4..965d5263

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26533&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26533&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26533.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26533/head:pull/26533

PR: https://git.openjdk.org/jdk/pull/26533

From rriggs at openjdk.org  Tue Jul 29 15:02:59 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Jul 2025 15:02:59 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
Message-ID: <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>

On Tue, 29 Jul 2025 13:43:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename getRawClassAccessFlags to getClassFileAccessFlags and fix the test to reflect what the JVM does.

src/java.base/share/classes/java/lang/Class.java line 248:

> 246:         protectionDomain = pd;
> 247:         primitive = isPrim;
> 248:         classFileAccessFlags = flags;

Its not that hard to add a field, why not have done this for identity?

src/java.base/share/classes/java/lang/Class.java line 4143:

> 4141:       * {@code FINAL}.
> 4142:       * If this {@code Class} object represents an array type return 0. This
> 4143:       * is not called in Class but can be called with an array type in Reflection.

The comment about "not called in Class" may get stale. I don't think it needs to be specified.

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 87:

> 85:         class Holder {
> 86:             static final JavaLangAccess JLA = SharedSecrets.getJavaLangAccess();
> 87:         }

Yuck, another class and another shared secret.
There's no need for a Holder class, just call SharedSecrets.getJavaLangAccess every time.
It just returning a value from a static field.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2240132537
PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2240117128
PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2240126279

From duke at openjdk.org  Tue Jul 29 15:04:18 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Jul 2025 15:04:18 GMT
Subject: RFR: 8077587: BigInteger Roots [v57]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <7Yj2gj0BSi3_d42svI0VYRXNUvTzJv1l8i_qnBN8lUI=.6ec67e3f-69bc-4477-8af5-6e47ea778cb6@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  More comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/6a3625e9..a291f78b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=56
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=55-56

  Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From duke at openjdk.org  Tue Jul 29 15:21:12 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Jul 2025 15:21:12 GMT
Subject: RFR: 8077587: BigInteger Roots [v58]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <a3zHLYsKfjT3zbCG9i1pmuUoqZE4TuPTAg7oWB9ujxg=.b00d596d-95b2-47db-9311-4d36cb24dd73@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/a291f78b..71514e00

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=57
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=56-57

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From liach at openjdk.org  Tue Jul 29 15:26:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Jul 2025 15:26:56 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
Message-ID: <ZMUB7AU3sYZp_6eERmc8K7rkiaEMi5XGqbF0GKfVgYc=.772ca1c9-e101-4d4d-9c27-22622ca0a584@github.com>

On Tue, 29 Jul 2025 14:55:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename getRawClassAccessFlags to getClassFileAccessFlags and fix the test to reflect what the JVM does.
>
> src/java.base/share/classes/java/lang/Class.java line 248:
> 
>> 246:         protectionDomain = pd;
>> 247:         primitive = isPrim;
>> 248:         classFileAccessFlags = flags;
> 
> Its not that hard to add a field, why not have done this for identity?

Fields are initialized by injection in javaClasses instead of through this constructor, so it's easy for us to accidentally forget to inject a field.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2240207422

From rgiulietti at openjdk.org  Tue Jul 29 15:48:56 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 29 Jul 2025 15:48:56 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v8]
In-Reply-To: <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
Message-ID: <QzJ-CEevmTcVrlGhficqeT1vUVCxpnJBnQ6GyfcHBls=.e8b71fc4-420e-4804-84d4-fd8fd66a5eab@github.com>

On Fri, 27 Jun 2025 01:04:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string.
>> 
>> For these scenarios, we can Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed.
>> 
>> @RogerRiggs completed the optimization when the encoder is LATIN1 in PR #24967. This PR continues to complete the optimization when the encoder is UTF16.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/StringUTF16.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

LGTM

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24773#pullrequestreview-3068164265

From liach at openjdk.org  Tue Jul 29 16:06:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Jul 2025 16:06:59 GMT
Subject: RFR: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory [v8]
In-Reply-To: <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
 <b-UBk1aeCLNrmwSmhaTkJvLUoRkvl05tDhh8GR2SBIM=.8a6c4867-facb-4d65-a73b-451baa639ed9@github.com>
Message-ID: <VFz1eUD5pVNcT8t0UBOAYc24TZueUJazajlrZ2r0hKI=.26c9bb6a-32ab-49d0-b6d9-45aa954fa70b@github.com>

On Fri, 27 Jun 2025 01:04:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string.
>> 
>> For these scenarios, we can Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed.
>> 
>> @RogerRiggs completed the optimization when the encoder is LATIN1 in PR #24967. This PR continues to complete the optimization when the encoder is UTF16.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/StringUTF16.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

I consulted @rose00 - Intrinsics are costly, so a next step might be removing the intrinsic for `toBytes` (which allocates a new byte array, unsuitable for here) and `getChars` in UTF16. This looks like a right direction to move along.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24773#issuecomment-3133162231

From duke at openjdk.org  Tue Jul 29 16:12:57 2025
From: duke at openjdk.org (fabioromano1)
Date: Tue, 29 Jul 2025 16:12:57 GMT
Subject: RFR: 8077587: BigInteger Roots [v59]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <wq40WPMp2QtHkTPIVjAIsW2IHbxYpLbV5zHE4MJlMeQ=.f13b9ee1-ca4d-49b9-b80e-66add88d9dbe@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Refine the comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/71514e00..8905cada

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=58
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=57-58

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From liach at openjdk.org  Tue Jul 29 16:32:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Jul 2025 16:32:51 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v14]
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: <qXtiZHt-RZPilsJy1tV_2YlDcslyLEmc16t0MibSmig=.980daa1e-3ed8-4986-9c6c-e1a2306f72a3@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:

  Docs from Rose

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25922/files
  - new: https://git.openjdk.org/jdk/pull/25922/files/49f7bd5b..d979778d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=12-13

  Stats: 127 lines in 2 files changed: 77 ins; 0 del; 50 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 duke at openjdk.org  Tue Jul 29 16:42:56 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 29 Jul 2025 16:42:56 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
Message-ID: <Eea49uyVwF368HDpvdFACpnLb6LDOUl412l4cGaxpUM=.465c6bae-19a4-422c-848a-3f63c706da84@github.com>

On Tue, 29 Jul 2025 14:52:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename getRawClassAccessFlags to getClassFileAccessFlags and fix the test to reflect what the JVM does.
>
> src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 87:
> 
>> 85:         class Holder {
>> 86:             static final JavaLangAccess JLA = SharedSecrets.getJavaLangAccess();
>> 87:         }
> 
> Yuck, another class and another shared secret.
> There's no need for a Holder class, just call SharedSecrets.getJavaLangAccess every time.
> It just returning a value from a static field.

Arguably, the?fields in?`SharedSecrets` should?be?made `@Stable`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2240401098

From liach at openjdk.org  Tue Jul 29 16:45:42 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Jul 2025 16:45:42 GMT
Subject: RFR: 8361638: java.lang.classfile.CodeBuilder.catchingAll doesn't
 throw IllegalArgumentException if an existing catch block catches all
 exceptions [v2]
In-Reply-To: <EsgujIABpxOwwcDzA9fsWpfB9YMY0XIzlmJIFwipVXY=.8f40bdea-49b4-468b-83df-b22951a23d41@github.com>
References: <EsgujIABpxOwwcDzA9fsWpfB9YMY0XIzlmJIFwipVXY=.8f40bdea-49b4-468b-83df-b22951a23d41@github.com>
Message-ID: <6uVZNrHSwCr2TcD0eICRj2vSFOImtUu79YODoJQ5syI=.ff471459-3f70-452a-8828-ec58643338c6@github.com>

> The detection of catch builder arguments is not working for catch-all blocks. Update this to track CP indices including 0 so we can more easily validate the incoming ClassDesc are all non-primitive and there is no duplicate.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Update to allow duplicate types, note instead
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-catch-type-validation
 - Formatting
 - 8361638: java.lang.classfile.CodeBuilder.catchingAll doesn't throw IllegalArgumentException if an existing catch block catches all exceptions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26372/files
  - new: https://git.openjdk.org/jdk/pull/26372/files/5bd5fb94..11d269c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26372&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26372&range=00-01

  Stats: 15779 lines in 474 files changed: 7352 ins; 6329 del; 2098 mod
  Patch: https://git.openjdk.org/jdk/pull/26372.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26372/head:pull/26372

PR: https://git.openjdk.org/jdk/pull/26372

From alanb at openjdk.org  Tue Jul 29 17:06:06 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Jul 2025 17:06:06 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v15]
In-Reply-To: <tF6q4wlxpAnHevpHtKkRK_slLbUSI7f4mvUZUnrEv9o=.362472f5-a976-4a2a-9412-c0c444c7287b@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <tF6q4wlxpAnHevpHtKkRK_slLbUSI7f4mvUZUnrEv9o=.362472f5-a976-4a2a-9412-c0c444c7287b@github.com>
Message-ID: <ZCubiy1lnVL4QSQOkBZA8m90BWYKiezNwUmyin6ojCs=.bda6dd80-6f27-498b-84fd-1fbc386ee2f5@github.com>

On Fri, 25 Jul 2025 17:32:19 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:
> 
>   Removing direct references to JrtFS.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 71:

> 69:  * <p>While similar to {@code BasicImageReader}, this class is not a conceptual
> 70:  * subtype of, it and deliberately hides types such as {@code ImageLocation} to
> 71:  * give a focused API based only on nodes.

Good.

src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 257:

> 255:     private static Stream<ModuleInfo.Attributes> allModuleAttributes() {
> 256:         // System reader is a singleton and should not be closed by callers.
> 257:         ImageReader reader = SystemImage.reader();

The changes to SystemModuleFinders looks okay but I think we should drop the "System reader is a singleton and should not be closed by callers" here as it sets doubt that the ImageReader might be closed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2240456695
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2240453692

From liach at openjdk.org  Tue Jul 29 17:06:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Jul 2025 17:06:44 GMT
Subject: RFR: 8361638: java.lang.classfile.CodeBuilder.CatchBuilder should
 not throw IllegalArgumentException for representable exception
 handlers [v3]
In-Reply-To: <EsgujIABpxOwwcDzA9fsWpfB9YMY0XIzlmJIFwipVXY=.8f40bdea-49b4-468b-83df-b22951a23d41@github.com>
References: <EsgujIABpxOwwcDzA9fsWpfB9YMY0XIzlmJIFwipVXY=.8f40bdea-49b4-468b-83df-b22951a23d41@github.com>
Message-ID: <xYg9aPaPJ8m-VVywcsyvq5Yj6lzPFbyE6NnvArsAPk4=.47e19c03-ee26-45eb-b090-275a3a200248@github.com>

> CatchBuilder has a simple check for duplicate catch types. However, this check is never comprehensive as it still allows subtypes covered by supertypes, and covering that would be too costly; in addition, the "illegal" duplicate catch types are still valid `class` files. We should remove this duplicate catch type check, and compensate with documentation on the effects of duplicate types.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Wrong ref

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26372/files
  - new: https://git.openjdk.org/jdk/pull/26372/files/11d269c6..00aca654

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26372&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26372&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26372.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26372/head:pull/26372

PR: https://git.openjdk.org/jdk/pull/26372

From alanb at openjdk.org  Tue Jul 29 17:14:02 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Jul 2025 17:14:02 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v15]
In-Reply-To: <tF6q4wlxpAnHevpHtKkRK_slLbUSI7f4mvUZUnrEv9o=.362472f5-a976-4a2a-9412-c0c444c7287b@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <tF6q4wlxpAnHevpHtKkRK_slLbUSI7f4mvUZUnrEv9o=.362472f5-a976-4a2a-9412-c0c444c7287b@github.com>
Message-ID: <rnTrM1C_f2-DgXtPaInMsZkdJoQYcH9IsXQUD5twyAE=.b66d6278-c4fc-4675-860b-786c6f8003f8@github.com>

On Fri, 25 Jul 2025 17:32:19 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:
> 
>   Removing direct references to JrtFS.

test/jdk/jdk/internal/jimage/JImageReadTest.java line 350:

> 348:         try (ImageReader badReader = ImageReader.open(imageFile, otherOrder)) {
> 349:             Assert.fail("Reader should not be openable with the wrong byte order.");
> 350:         } catch (IOException expected) {

In passing, you can use `assertThrows(IOException.class(), () -> ImageReader.open(..))` here if you want.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2240472988

From alanb at openjdk.org  Tue Jul 29 17:34:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Jul 2025 17:34:03 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v15]
In-Reply-To: <tF6q4wlxpAnHevpHtKkRK_slLbUSI7f4mvUZUnrEv9o=.362472f5-a976-4a2a-9412-c0c444c7287b@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <tF6q4wlxpAnHevpHtKkRK_slLbUSI7f4mvUZUnrEv9o=.362472f5-a976-4a2a-9412-c0c444c7287b@github.com>
Message-ID: <SPtkZxcv71RVc_sSus2Uw612H4WkdfVgnmKRp1I5yoM=.d824b853-05a5-484c-b8d2-4376a4dc5fc1@github.com>

On Fri, 25 Jul 2025 17:32:19 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:
> 
>   Removing direct references to JrtFS.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 686:

> 684:     /// to child nodes, while retaining efficiency when child nodes are accessed
> 685:     /// (since any incomplete nodes will be created and placed in the node cache
> 686:     /// when the parent was first returned to the user).

The new class descriptions for Node, Directory and Resource are very useful for future maintainers. Can you convert these to /* */ style as we've ended up with a mix in this update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2240513046

From duke at openjdk.org  Tue Jul 29 17:55:04 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 29 Jul 2025 17:55:04 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v15]
In-Reply-To: <ZCubiy1lnVL4QSQOkBZA8m90BWYKiezNwUmyin6ojCs=.bda6dd80-6f27-498b-84fd-1fbc386ee2f5@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <tF6q4wlxpAnHevpHtKkRK_slLbUSI7f4mvUZUnrEv9o=.362472f5-a976-4a2a-9412-c0c444c7287b@github.com>
 <ZCubiy1lnVL4QSQOkBZA8m90BWYKiezNwUmyin6ojCs=.bda6dd80-6f27-498b-84fd-1fbc386ee2f5@github.com>
Message-ID: <sNBpZtqIkSRRcdba2W-6bF4bRuSStHbJAdAEZxGFigw=.1e2952fa-1ec8-4523-89c6-aaacac4dbdbd@github.com>

On Tue, 29 Jul 2025 17:02:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing direct references to JrtFS.
>
> src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 257:
> 
>> 255:     private static Stream<ModuleInfo.Attributes> allModuleAttributes() {
>> 256:         // System reader is a singleton and should not be closed by callers.
>> 257:         ImageReader reader = SystemImage.reader();
> 
> The changes to SystemModuleFinders looks okay but I think we should drop the "System reader is a singleton and should not be closed by callers" here as it sets doubt that the ImageReader might be closed.

I mean without that, as a reader of the code who doesn't know details, I'd definitely be questioning why a closeable object (ImageReader) is being obtained and used, but not closed. I probably even added it because I'd had to dig around the code to understand that it was actually correct to not close it here.

Perhaps the docs for SystemImage (currently `Holder class for the ImageReader.` could be improved to make the lifecycle clear and benefit all callers of `reader()` ?)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2240555715

From duke at openjdk.org  Tue Jul 29 17:59:02 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 29 Jul 2025 17:59:02 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v15]
In-Reply-To: <rnTrM1C_f2-DgXtPaInMsZkdJoQYcH9IsXQUD5twyAE=.b66d6278-c4fc-4675-860b-786c6f8003f8@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <tF6q4wlxpAnHevpHtKkRK_slLbUSI7f4mvUZUnrEv9o=.362472f5-a976-4a2a-9412-c0c444c7287b@github.com>
 <rnTrM1C_f2-DgXtPaInMsZkdJoQYcH9IsXQUD5twyAE=.b66d6278-c4fc-4675-860b-786c6f8003f8@github.com>
Message-ID: <rKnKLZeDI3kGz7YPIfNBsZmtMKt4EgmyiuYsFcSFUWM=.8c2760c2-0785-4dad-b002-563c73d7f6cf@github.com>

On Tue, 29 Jul 2025 17:11: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:
>> 
>>   Removing direct references to JrtFS.
>
> test/jdk/jdk/internal/jimage/JImageReadTest.java line 350:
> 
>> 348:         try (ImageReader badReader = ImageReader.open(imageFile, otherOrder)) {
>> 349:             Assert.fail("Reader should not be openable with the wrong byte order.");
>> 350:         } catch (IOException expected) {
> 
> In passing, you can use `assertThrows(IOException.class(), () -> ImageReader.open(..))` here if you want.

I don't think I can, can I? That method takes a Runnable, not some sort of Callable that throws E.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2240563330

From jrose at openjdk.org  Tue Jul 29 18:06:59 2025
From: jrose at openjdk.org (John R Rose)
Date: Tue, 29 Jul 2025 18:06:59 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v14]
In-Reply-To: <qXtiZHt-RZPilsJy1tV_2YlDcslyLEmc16t0MibSmig=.980daa1e-3ed8-4986-9c6c-e1a2306f72a3@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <qXtiZHt-RZPilsJy1tV_2YlDcslyLEmc16t0MibSmig=.980daa1e-3ed8-4986-9c6c-e1a2306f72a3@github.com>
Message-ID: <pqu5PL1gbS0T8-oTG9tYv825aSj_ggQGfPTBA3mnGcs=.317bf43b-1285-4fa2-a717-02cdb7ee53a0@github.com>

On Tue, 29 Jul 2025 16:32:51 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:
> 
>   Docs from Rose

Marked as reviewed by jrose (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-3068641494

From bpb at openjdk.org  Tue Jul 29 18:50:56 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 29 Jul 2025 18:50:56 GMT
Subject: RFR: 8363720: Follow up to JDK-8360411 with post review comments
 [v3]
In-Reply-To: <bxhUtcshp1dDVJgMzQtJAGz5C6u4ckZ3KGiBdpWLh20=.431191d5-0682-4983-9598-280763356282@github.com>
References: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
 <bxhUtcshp1dDVJgMzQtJAGz5C6u4ckZ3KGiBdpWLh20=.431191d5-0682-4983-9598-280763356282@github.com>
Message-ID: <raOLWlnapE13NGdaDjraiok_GRt5zR7r3-_7ZdyibgA=.2b7a865f-0e02-4655-97e8-0ebabf21f2a9@github.com>

On Thu, 24 Jul 2025 10:06:39 GMT, Darragh Conway <duke at openjdk.org> wrote:

>> There were a couple of post review comments after the /integrate command was submitted. This issue will address those comments. Also created constants for hardcoded values and tests. Fixed some typos.
>
> Darragh Conway has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix remaining indentation errors (From my first commit on this branch)

test/jdk/java/io/File/MaxPathLength.java line 69:

> 67:     }
> 68: 
> 69:     private static void setIsWindows() {

Instead of `isWindows` and `setIsWindows`, perhaps you should consider using `jdk.test.lib.Platform.isWindows()`? See, for example, [GetXSpace.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/io/File/GetXSpace.java), lines 30-31, 46, and 109.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26445#discussion_r2240679861

From iklam at openjdk.org  Tue Jul 29 18:52:00 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 29 Jul 2025 18:52:00 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v14]
In-Reply-To: <qXtiZHt-RZPilsJy1tV_2YlDcslyLEmc16t0MibSmig=.980daa1e-3ed8-4986-9c6c-e1a2306f72a3@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <qXtiZHt-RZPilsJy1tV_2YlDcslyLEmc16t0MibSmig=.980daa1e-3ed8-4986-9c6c-e1a2306f72a3@github.com>
Message-ID: <VEyiMBwGZC0dwBCZQPVETSm9tgMaO2wMiPnnxSZBDR0=.2ab71d4e-194d-45fb-8f76-965c8a1e9643@github.com>

On Tue, 29 Jul 2025 16:32:51 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:
> 
>   Docs from Rose

Good to go!

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-3068776696

From coleenp at openjdk.org  Tue Jul 29 19:58:11 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 29 Jul 2025 19:58:11 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <ZMUB7AU3sYZp_6eERmc8K7rkiaEMi5XGqbF0GKfVgYc=.772ca1c9-e101-4d4d-9c27-22622ca0a584@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <ZMUB7AU3sYZp_6eERmc8K7rkiaEMi5XGqbF0GKfVgYc=.772ca1c9-e101-4d4d-9c27-22622ca0a584@github.com>
Message-ID: <5gvsQ413EdL2Lvs-rmusDgTPMiT7lVag5H4fF5Fk4P4=.1416ddb9-6161-419e-8fc2-653e073dd399@github.com>

On Tue, 29 Jul 2025 15:22:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 248:
>> 
>>> 246:         protectionDomain = pd;
>>> 247:         primitive = isPrim;
>>> 248:         classFileAccessFlags = flags;
>> 
>> Its not that hard to add a field, why not have done this for identity?
>
> Fields are initialized by injection in javaClasses instead of through this constructor, so it's easy for us to accidentally forget to inject a field.

For IDENTITY, I didn't have to inject that one because the Java code knew when to set it, not the JVM code reading the data out of the classfile.  And the logic belongs in the Java code, not the JVM. This one comes from the classfile, there isn't another way to get the information to the java.lang.Class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2240783242

From coleenp at openjdk.org  Tue Jul 29 19:58:14 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 29 Jul 2025 19:58:14 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <Eea49uyVwF368HDpvdFACpnLb6LDOUl412l4cGaxpUM=.465c6bae-19a4-422c-848a-3f63c706da84@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <Eea49uyVwF368HDpvdFACpnLb6LDOUl412l4cGaxpUM=.465c6bae-19a4-422c-848a-3f63c706da84@github.com>
Message-ID: <APTJ1xmxtC3sPBSuDTdcD6aYduD72_4itf6v3LLwD1E=.48f0a7e5-eb97-425f-bb57-3280b2d8cfcb@github.com>

On Tue, 29 Jul 2025 16:40:22 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 87:
>> 
>>> 85:         class Holder {
>>> 86:             static final JavaLangAccess JLA = SharedSecrets.getJavaLangAccess();
>>> 87:         }
>> 
>> Yuck, another class and another shared secret.
>> There's no need for a Holder class, just call SharedSecrets.getJavaLangAccess every time.
>> It just returning a value from a static field.
>
> Arguably, the?fields in?`SharedSecrets` should?be?made `@Stable`.

Okay, I'll remove the Holder class.  I copied it from another method in the file.  yeah, sorry for the additional shared secret but I didn't want to make the java.lang.Class method public.

I didn't add a field to SharedSecrets, and the field in Class is transient which I think supersedes @Stable - at least that's what I remember from our discussion of the modifiers field in Class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2240789122

From coleenp at openjdk.org  Tue Jul 29 19:58:10 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 29 Jul 2025 19:58:10 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v3]
In-Reply-To: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
Message-ID: <r9nTP7uf6V154eA4HObVm2pDNFjYQZ6AGhUjUqn__Eg=.942299ad-ab36-4254-b96b-a7b174d63af2@github.com>

> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix comments and remove Holder.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26517/files
  - new: https://git.openjdk.org/jdk/pull/26517/files/163a8e5c..a4974473

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26517&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26517&range=01-02

  Stats: 6 lines in 2 files changed: 0 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26517/head:pull/26517

PR: https://git.openjdk.org/jdk/pull/26517

From coleenp at openjdk.org  Tue Jul 29 19:58:12 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 29 Jul 2025 19:58:12 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
Message-ID: <0vCCEQN8w5kI1KG08bFyMXlpNkQ0ijhI6SSxrhkWPUs=.8104e221-c4fc-4524-ba67-79ab6b080dc0@github.com>

On Tue, 29 Jul 2025 14:49:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename getRawClassAccessFlags to getClassFileAccessFlags and fix the test to reflect what the JVM does.
>
> src/java.base/share/classes/java/lang/Class.java line 4143:
> 
>> 4141:       * {@code FINAL}.
>> 4142:       * If this {@code Class} object represents an array type return 0. This
>> 4143:       * is not called in Class but can be called with an array type in Reflection.
> 
> The comment about "not called in Class" may get stale. I don't think it needs to be specified.

Okay, I'll remove it.  I wanted to explain the change of the algorithm, and why I removed the handling for arrays.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2240785622

From liach at openjdk.org  Tue Jul 29 20:46:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Jul 2025 20:46:12 GMT
Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and
 AOTSafeClassInitializer [v14]
In-Reply-To: <qXtiZHt-RZPilsJy1tV_2YlDcslyLEmc16t0MibSmig=.980daa1e-3ed8-4986-9c6c-e1a2306f72a3@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <qXtiZHt-RZPilsJy1tV_2YlDcslyLEmc16t0MibSmig=.980daa1e-3ed8-4986-9c6c-e1a2306f72a3@github.com>
Message-ID: <RuJVFyrfMPhXBVElRJ6jdP4Qbb-FGTOyQnenYyHJMjw=.8aeae265-bae2-4052-afea-d1b6022b5ffb@github.com>

On Tue, 29 Jul 2025 16:32:51 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:
> 
>   Docs from Rose

Thanks for the reviews! I will go ahead and integrate to facilitate further work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25922#issuecomment-3134009692

From liach at openjdk.org  Tue Jul 29 20:46:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Jul 2025 20:46:13 GMT
Subject: Integrated: 8360163: Replace hard-coded checks with AOTRuntimeSetup
 and AOTSafeClassInitializer
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: <rpKLbPIgjNoo382AHdiGkDJoKsyEI8ydp-hPSCLozGI=.5f99f2e1-aa0e-482c-8dee-0eba9e66e541@github.com>

On Sat, 21 Jun 2025 00:03:26 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.

This pull request has now been integrated.

Changeset: 330ee871
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/330ee871315348594171c43aa75b58f6027001af
Stats:     571 lines in 39 files changed: 401 ins; 150 del; 20 mod

8360163: Replace hard-coded checks with AOTRuntimeSetup and AOTSafeClassInitializer

Reviewed-by: jrose, iklam

-------------

PR: https://git.openjdk.org/jdk/pull/25922

From liach at openjdk.org  Tue Jul 29 21:15:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Jul 2025 21:15:07 GMT
Subject: RFR: 8364317: Explicitly document some assumptions of StringUTF16
Message-ID: <vTct6VRmglYJEqYaS3A4oeMBvXEYDRXGtJ_iD1YC2lM=.efc00627-2856-4c45-8dcf-55b1a9907680@github.com>

In #24773, people were concerned that the layout of a UTF16 byte array and a char array may be incompatible. In fact, they are - they are asserted in a corner in `LibraryCallKit::inline_string_char_access` in `library_call.cpp`.

In addition, another frequent error I see is that contributors have confused the meaning of indices in StringUTF16 - the indices are always in char array indices. I think we should make these explicit to help future maintenance.

-------------

Commit messages:
 - Miscellaneous docs and checks for UTF16

Changes: https://git.openjdk.org/jdk/pull/26541/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26541&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364317
  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26541.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26541/head:pull/26541

PR: https://git.openjdk.org/jdk/pull/26541

From liach at openjdk.org  Tue Jul 29 21:46:42 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 29 Jul 2025 21:46:42 GMT
Subject: RFR: 8364319: Move java.lang.constant.AsTypeMethodHandleDesc to
 jdk.internal
Message-ID: <mfrVbVcScpwmdWcGnFiabumfpIhI1wLse_FAHPJ7qRY=.2ed0cfcc-cd5a-4de0-b77b-f41a178912e5@github.com>

java.lang.constant.AsTypeMethodHandleDesc is an implementation class for the Constant API. It was omitted in the move probably because its name does not end with Impl. We should move it to the implementation package instead.

-------------

Commit messages:
 - Move AsTypeMethodHandleDesc to constant API impl package

Changes: https://git.openjdk.org/jdk/pull/26542/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26542&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364319
  Stats: 156 lines in 4 files changed: 80 ins; 74 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26542/head:pull/26542

PR: https://git.openjdk.org/jdk/pull/26542

From duke at openjdk.org  Tue Jul 29 22:11:58 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 29 Jul 2025 22:11:58 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <APTJ1xmxtC3sPBSuDTdcD6aYduD72_4itf6v3LLwD1E=.48f0a7e5-eb97-425f-bb57-3280b2d8cfcb@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <Eea49uyVwF368HDpvdFACpnLb6LDOUl412l4cGaxpUM=.465c6bae-19a4-422c-848a-3f63c706da84@github.com>
 <APTJ1xmxtC3sPBSuDTdcD6aYduD72_4itf6v3LLwD1E=.48f0a7e5-eb97-425f-bb57-3280b2d8cfcb@github.com>
Message-ID: <R-3QlGXUoiVYAs0pB9mFV69btIOdMoJRGV9unYwCBZI=.0d686d0b-82d7-40da-ba9d-00b1137a6ce5@github.com>

On Tue, 29 Jul 2025 19:46:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Arguably, the?fields in?`SharedSecrets` should?be?made `@Stable`.
>
> Okay, I'll remove the Holder class.  I copied it from another method in the file.  yeah, sorry for the additional shared secret but I didn't want to make the java.lang.Class method public.
> 
> I didn't add a field to SharedSecrets, and the field in Class is transient which I think supersedes @Stable - at least that's what I remember from our discussion of the modifiers field in Class.

I?mean the?existing private?fields of?`SharedSecrets`[^1] so?that the?JIT is?able to?constant?fold calls?to?`SharedSecrets?::getJava*Access()` so?that it?becomes equally?as?performant as?using a?`Holder`?class.

Modifiers are?transient, as?those are?sourced?from the?`InnerClasses`?attribute, which?can?be?changed when?classes are?redefined by?a?**JVMTI**?agent, but?access?flags can?t?be?changed through?redefinition.

[^1]: https://github.com/openjdk/jdk/blob/330ee871315348594171c43aa75b58f6027001af/src/java.base/share/classes/jdk/internal/access/SharedSecrets.java#L62-L92

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2241100994

From duke at openjdk.org  Tue Jul 29 22:11:58 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 29 Jul 2025 22:11:58 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v3]
In-Reply-To: <r9nTP7uf6V154eA4HObVm2pDNFjYQZ6AGhUjUqn__Eg=.942299ad-ab36-4254-b96b-a7b174d63af2@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <r9nTP7uf6V154eA4HObVm2pDNFjYQZ6AGhUjUqn__Eg=.942299ad-ab36-4254-b96b-a7b174d63af2@github.com>
Message-ID: <aWPGX886C2xiXvj-FM0Zuv_0n-lBkxu9FvJO_KgFDAE=.117026b1-282e-4b54-9b2f-34e965c2869b@github.com>

On Tue, 29 Jul 2025 19:58:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments and remove Holder.

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 86:

> 84:     public static int getClassAccessFlags(Class<?> c) {
> 85:         JavaLangAccess JLA = SharedSecrets.getJavaLangAccess();
> 86:         return JLA.getClassFileAccessFlags(c);

Suggestion:

        return SharedSecrets.getJavaLangAccess().getClassFileAccessFlags(c);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2241101969

From achung at openjdk.org  Wed Jul 30 01:59:10 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 30 Jul 2025 01:59:10 GMT
Subject: Integrated: 8364089: JDK 25 RDP2 L10n resource files update
In-Reply-To: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
References: <NdtpGKmo--0qlPalyQddD6a-dIC5XRIoULHSSrnVGrY=.bd888aca-843a-4ec5-91c2-010ad313f593@github.com>
Message-ID: <SikYgrKEa81qT9eL-M4o94o8JAkVv3CyZAuk2iHi9-Q=.da234125-164d-4bbb-992a-73182fa5a8e9@github.com>

On Fri, 25 Jul 2025 00:25:01 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

This pull request has now been integrated.

Changeset: c671089d
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c671089d6e9aa147ffd056a83c84abf6aff444dc
Stats:     90 lines in 14 files changed: 71 ins; 9 del; 10 mod

8364089: JDK 25 RDP2 L10n resource files update

Reviewed-by: jlu, naoto, dnguyen, asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/26467

From achung at openjdk.org  Wed Jul 30 02:19:34 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 30 Jul 2025 02:19:34 GMT
Subject: [jdk25] RFR: 8364089: JDK 25 RDP2 L10n resource files update
Message-ID: <PIPIWgdCQBNP85HGvDyTg2VDsebvTiXhA9nGg_5O6P0=.b850540b-0994-48d1-af28-e68d00c01c5d@github.com>

8364089: JDK 25 RDP2 L10n resource files update

-------------

Commit messages:
 - Backport c671089d6e9aa147ffd056a83c84abf6aff444dc

Changes: https://git.openjdk.org/jdk/pull/26543/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26543&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364089
  Stats: 90 lines in 14 files changed: 71 ins; 9 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/26543.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26543/head:pull/26543

PR: https://git.openjdk.org/jdk/pull/26543

From haosun at openjdk.org  Wed Jul 30 06:04:55 2025
From: haosun at openjdk.org (Hao Sun)
Date: Wed, 30 Jul 2025 06:04:55 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <4Mxnjj-pjt-LP4gFxL8HMA5805Nam6TbotfFsuC5Oj8=.65109ba8-508a-4674-9d32-82ec1b2fd80f@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

Hi, I encountered two jtreg failures with this new version `8` on both AArch64 and x86_64 platforms.
Note that these two jtreg cases can pass with jtreg `7.5.2+1` version.

### some details

JDK source: master
jtreg version: `8+2` version
JDK build: `fastdebug`
OS: `ubuntu 24.04`
two jtreg test cases

test/jdk/java/security/SignedJar/spi-calendar-provider/TestSPISigned.java
test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003/TestDescription.java

how to reproduce:

make test TEST="test/jdk/java/security/SignedJar/spi-calendar-provider/TestSPISigned.java"
make test TEST=test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003/TestDescription.java


### the snippet of error log for case `TestSPISigned.java` on AArch64


STDERR:                                                                                                                                                                                                                                                      
java.nio.file.NoSuchFileException: /tmp/build-fastdebug/test-support/jtreg_test_jdk_java_security_SignedJar_spi_calendar_provider_TestSPISigned_java/classes/0/java/security/SignedJar/spi-calendar-provider/TestSPISigned.d/../provider/.                   
        at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)                                   
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
        at java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:57)
        at java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:161)
        at java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
        at java.base/java.nio.file.Files.readAttributes(Files.java:1702)
        at java.base/java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:216)                                                                                                                                                                     
        at java.base/java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:268)   
        at java.base/java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:306)                                                                                                                                                                              
        at java.base/java.nio.file.FileTreeIterator.<init>(FileTreeIterator.java:69)                                          
        at java.base/java.nio.file.Files.find(Files.java:3649)                                                                
        at jdk.test.lib.util.JarUtils.findAllRegularFiles(JarUtils.java:425)                                                                                                                                                                                 
        at jdk.test.lib.util.JarUtils.createJarFile(JarUtils.java:75)                                                         
        at jdk.test.lib.util.JarUtils.createJarFile(JarUtils.java:106)                                                        
        at jdk.test.lib.util.JarUtils.createJarFile(JarUtils.java:115)                                                        
        at TestSPISigned.main(TestSPISigned.java:84)                                                                                                                                                                                                         
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)              
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)                                                         
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)                                                                                                                                                            at java.base/java.lang.Thread.run(Thread.java:1474)
                                                                                                                                                                                                                                                             
JavaTest Message: Test threw exception: java.nio.file.NoSuchFileException                                                     
JavaTest Message: shutting down test                 
                                                               
                                                                                                                                                                                                                                                             
TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.NoSuchFileException: /tmp/build-fastdebug/test-support/jtreg_test_jdk_java_security_SignedJar_spi_calendar_provider_TestSPISigned_java/classes/0/java/security/SignedJar/spi-cal
endar-provider/TestSPISigned.d/../provider/.
--------------------------------------------------
Test results: failed: 1

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3134956713

From duke at openjdk.org  Wed Jul 30 09:53:19 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 30 Jul 2025 09:53:19 GMT
Subject: RFR: 8077587: BigInteger Roots [v60]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <tF4fAAW4pn7pV_ro61tUKFrgYnDKp8L3ZUTESavQ-Ic=.a15ce9c1-4f91-4da8-9ce0-ff26d11f85c9@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Refine comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/8905cada..37a52e13

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=59
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=58-59

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From duke at openjdk.org  Wed Jul 30 10:02:23 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 30 Jul 2025 10:02:23 GMT
Subject: RFR: 8077587: BigInteger Roots [v61]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <WpqJmiAhF8P0g0hvuKmcdX-Q__IkDyNSII0gYEqlLZY=.e510826b-a17c-49e4-b593-8c1e6aeb226e@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Update javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/37a52e13..a724dc8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=60
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=59-60

  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From duke at openjdk.org  Wed Jul 30 10:34:01 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 30 Jul 2025 10:34:01 GMT
Subject: RFR: 8077587: BigInteger Roots [v61]
In-Reply-To: <WpqJmiAhF8P0g0hvuKmcdX-Q__IkDyNSII0gYEqlLZY=.e510826b-a17c-49e4-b593-8c1e6aeb226e@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <WpqJmiAhF8P0g0hvuKmcdX-Q__IkDyNSII0gYEqlLZY=.e510826b-a17c-49e4-b593-8c1e6aeb226e@github.com>
Message-ID: <XLAo4JQw8iftv_K0tctm0JMdZDACeW_-13kZkiA3ciE=.7b40d8cf-117b-4b42-9fcd-dcd7adb82bb5@github.com>

On Wed, 30 Jul 2025 10:02:23 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update javadoc

src/java.base/share/classes/java/math/MutableBigInteger.java line 1921:

> 1919:      * The contents of {@code this} are <em>not</em> changed. The value of {@code this}
> 1920:      * is assumed to be non-negative and the root degree {@code n >= 3}.
> 1921:      * Assumes {@code bitLength() <= Integer.MAX_VALUE}.

@rgiulietti This assumption could be dropped, if the shift methods of `MutableBigInteger` would accept `long` shift values too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2242202995

From duke at openjdk.org  Wed Jul 30 10:39:22 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 30 Jul 2025 10:39:22 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v16]
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: <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@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:

  Convert non-visible markdown comments to JavaDoc for consistency.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26054/files
  - new: https://git.openjdk.org/jdk/pull/26054/files/a41b48df..5b8e8250

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=14-15

  Stats: 129 lines in 1 file changed: 37 ins; 0 del; 92 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 30 10:39:22 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 30 Jul 2025 10:39:22 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v15]
In-Reply-To: <SPtkZxcv71RVc_sSus2Uw612H4WkdfVgnmKRp1I5yoM=.d824b853-05a5-484c-b8d2-4376a4dc5fc1@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <tF6q4wlxpAnHevpHtKkRK_slLbUSI7f4mvUZUnrEv9o=.362472f5-a976-4a2a-9412-c0c444c7287b@github.com>
 <SPtkZxcv71RVc_sSus2Uw612H4WkdfVgnmKRp1I5yoM=.d824b853-05a5-484c-b8d2-4376a4dc5fc1@github.com>
Message-ID: <RJKRVt_Jf_0kf9M4xZM5TCcfu83v6_MCyicep-Hfr8Q=.c89860b9-cc59-4f12-9cc5-a703a9996fb2@github.com>

On Tue, 29 Jul 2025 17:30:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing direct references to JrtFS.
>
> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 686:
> 
>> 684:     /// to child nodes, while retaining efficiency when child nodes are accessed
>> 685:     /// (since any incomplete nodes will be created and placed in the node cache
>> 686:     /// when the parent was first returned to the user).
> 
> The new class descriptions for Node, Directory and Resource are very useful for future maintainers. Can you convert these to /* */ style as we've ended up with a mix in this update.

As discussed offline, I converted all the markdown comments for non-visible elements to HTML/JavaDoc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2242217898

From coleenp at openjdk.org  Wed Jul 30 10:59:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 30 Jul 2025 10:59:55 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <R-3QlGXUoiVYAs0pB9mFV69btIOdMoJRGV9unYwCBZI=.0d686d0b-82d7-40da-ba9d-00b1137a6ce5@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <Eea49uyVwF368HDpvdFACpnLb6LDOUl412l4cGaxpUM=.465c6bae-19a4-422c-848a-3f63c706da84@github.com>
 <APTJ1xmxtC3sPBSuDTdcD6aYduD72_4itf6v3LLwD1E=.48f0a7e5-eb97-425f-bb57-3280b2d8cfcb@github.com>
 <R-3QlGXUoiVYAs0pB9mFV69btIOdMoJRGV9unYwCBZI=.0d686d0b-82d7-40da-ba9d-00b1137a6ce5@github.com>
Message-ID: <3KAsrKOGuC7XInNaIEmocMu2vX8RTL5dOJhwsnFnSPs=.6c5dc374-6807-416d-9c78-cd664cd04f6f@github.com>

On Tue, 29 Jul 2025 21:59:41 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Okay, I'll remove the Holder class.  I copied it from another method in the file.  yeah, sorry for the additional shared secret but I didn't want to make the java.lang.Class method public.
>> 
>> I didn't add a field to SharedSecrets, and the field in Class is transient which I think supersedes @Stable - at least that's what I remember from our discussion of the modifiers field in Class.
>
> I?mean the?existing private?fields of?`SharedSecrets`[^1] so?that the?JIT is?able to?constant?fold calls?to?`SharedSecrets?::getJava*Access()` so?that it?becomes equally?as?performant as?using a?`Holder`?class.
> 
> Modifiers are?transient, as?those are?sourced?from the?`InnerClasses`?attribute, which?can?be?changed when?classes are?redefined by?a?**JVMTI**?agent, but?access?flags can?t?be?changed through?redefinition.
> 
> [^1]: https://github.com/openjdk/jdk/blob/330ee871315348594171c43aa75b58f6027001af/src/java.base/share/classes/jdk/internal/access/SharedSecrets.java#L62-L92

I don't think inner class attributes can be changed via JVMTI RedefineClasses either.  I'm pretty sure we check and that's considered a change of schema.  File an RFE to make SharedSecrets fields @Stable though for a different change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2242267576

From coleenp at openjdk.org  Wed Jul 30 11:05:34 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 30 Jul 2025 11:05:34 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v4]
In-Reply-To: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
Message-ID: <aIi03VimwLejWVSdgsEApkb-raD-KfRH8NKLHEHhmGo=.2b6f1d8e-9c67-4dce-a595-5d94408184e3@github.com>

> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26517/files
  - new: https://git.openjdk.org/jdk/pull/26517/files/a4974473..45b92c5c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26517&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26517&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26517/head:pull/26517

PR: https://git.openjdk.org/jdk/pull/26517

From rgiulietti at openjdk.org  Wed Jul 30 12:09:55 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 30 Jul 2025 12:09:55 GMT
Subject: RFR: 8364317: Explicitly document some assumptions of StringUTF16
In-Reply-To: <vTct6VRmglYJEqYaS3A4oeMBvXEYDRXGtJ_iD1YC2lM=.efc00627-2856-4c45-8dcf-55b1a9907680@github.com>
References: <vTct6VRmglYJEqYaS3A4oeMBvXEYDRXGtJ_iD1YC2lM=.efc00627-2856-4c45-8dcf-55b1a9907680@github.com>
Message-ID: <Mw4qgm9pMKYpC4OEmkrDkX93AX_9DxZkQ0UKrJ6TJKo=.adf38d97-7442-4c93-8f2d-482eb97fabf0@github.com>

On Tue, 29 Jul 2025 21:09:59 GMT, Chen Liang <liach at openjdk.org> wrote:

> In #24773, people were concerned that the layout of a UTF16 byte array and a char array may be incompatible. In fact, they are - they are asserted in a corner in `LibraryCallKit::inline_string_char_access` in `library_call.cpp`.
> 
> In addition, another frequent error I see is that contributors have confused the meaning of indices in StringUTF16 - the indices are always in char array indices. I think we should make these explicit to help future maintenance.

A good initiative, thanks @liach.
Maybe some words about endianness would be useful as well.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26541#pullrequestreview-3071115533

From thartmann at openjdk.org  Wed Jul 30 12:23:55 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 30 Jul 2025 12:23:55 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v4]
In-Reply-To: <aIi03VimwLejWVSdgsEApkb-raD-KfRH8NKLHEHhmGo=.2b6f1d8e-9c67-4dce-a595-5d94408184e3@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <aIi03VimwLejWVSdgsEApkb-raD-KfRH8NKLHEHhmGo=.2b6f1d8e-9c67-4dce-a595-5d94408184e3@github.com>
Message-ID: <RW85vjuDstNZuhzlit7pY9R8ULLh0x5DiZcJiQd-Usc=.43d5b101-3ba7-4f23-942b-09e97ee03f9a@github.com>

On Wed, 30 Jul 2025 11:05:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

src/hotspot/share/opto/memnode.cpp line 1986:

> 1984:     // (Folds up the 2nd indirection in Reflection.getClassAccessFlags(aClassConstant).)
> 1985:     assert(Opcode() == Op_LoadUS, "must load an unsigned short from _access_flags");
> 1986:     return TypeInt::make(klass->access_flags());

I think this optimization should stay because the `_getSuperclass` intrinsic still emits a load from `Klass::access_flags_offset()` that could potentially be optimized here, see:
https://github.com/openjdk/jdk/blob/ed70910b0f3e1b19d915ec13ac3434407d01bc5d/src/hotspot/share/opto/library_call.cpp#L4081-L4088
->
https://github.com/openjdk/jdk/blob/ed70910b0f3e1b19d915ec13ac3434407d01bc5d/src/hotspot/share/opto/library_call.cpp#L3970-L3973

You can still remove the lines referencing `Reflection.getClassAccessFlags`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2242464835

From swen at openjdk.org  Wed Jul 30 13:19:04 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 30 Jul 2025 13:19:04 GMT
Subject: Integrated: 8355177: Speed up StringBuilder::append(char[]) via
 Unsafe::copyMemory
In-Reply-To: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
References: <OuBB0wK_DbxFp6LhvxrRqNYhjSDxxgimKQu02AehiIk=.5f7fd264-e6a5-4996-b534-c32b1a7c7583@github.com>
Message-ID: <y016KMeOAuOK1qZalMSkRc9Td-Kmc1iLx_8eMLbog0I=.fabbce97-bc1e-4271-b79c-7ec117c93f3b@github.com>

On Mon, 21 Apr 2025 07:00:36 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> In BufferedReader.readLine and other similar scenarios, we need to use StringBuilder.append(char[]) to build the string.
> 
> For these scenarios, we can Unsafe.copyMemory instead of the character copy of the char-by-char loop to improve the speed.
> 
> @RogerRiggs completed the optimization when the encoder is LATIN1 in PR #24967. This PR continues to complete the optimization when the encoder is UTF16.

This pull request has now been integrated.

Changeset: e2feff85
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e2feff85995cf2d0b8ecc2262cf4e74b74de3e31
Stats:     40 lines in 2 files changed: 32 ins; 6 del; 2 mod

8355177: Speed up StringBuilder::append(char[]) via Unsafe::copyMemory

Reviewed-by: rriggs, rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/24773

From rgiulietti at openjdk.org  Wed Jul 30 13:43:00 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 30 Jul 2025 13:43:00 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v3]
In-Reply-To: <vEAT8VpjJFBMyG87cz0gBcu2zwzPDOXuZWKksj_UPiw=.d2b9f24e-9411-4969-a261-e5415aa18498@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <-6TYWikmLNBtyQt6_xeJ8KoziHxA8Ijr067NIc740X0=.2f9e4cae-7f39-46b8-b3a9-f381fb2e0518@github.com>
 <JNEKtkhrEYnS1SvaSz7GhcS4FQGkQXma4nY_Wo0T18A=.3dce72d9-7250-4672-adad-13db79e3150c@github.com>
 <tCE4NXNXnwQro2lXxzJbDuJzrcTt3k2bNrR8wk54jX8=.6a749f99-e70b-426b-ad9d-e077c115f42d@github.com>
 <Tv8HMWAw2YxNwcjL3_8ZoELHZZHCI-RSeMNbN-NBU5g=.dac7959c-1d74-47c3-a283-fe212dcd3705@github.com>
 <hzCwNHUbtMWh_V3rtnMipAOj2_bB1UF-Sewy2kttvH4=.d29dac97-b7df-4a17-94ff-36c4ce8cbed1@github.com>
 <vEAT8VpjJFBMyG87cz0gBcu2zwzPDOXuZWKksj_UPiw=.d2b9f24e-9411-4969-a261-e5415aa18498@github.com>
Message-ID: <SsyIJVW_ESjynb6OetI4nnbq4_tORH5CHuaCG055zAU=.9b29a35f-3eb3-45ec-a6d2-e44a895ff386@github.com>

On Mon, 16 Jun 2025 18:19:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> I don't have a specific example, so I've reverted to my original check. I'm a bit unsettled by the check for an extreme value later in `doubleValue()` comparing against `MIN_DECIMAL_EXPONENT - 1`
>
> IMO, the original check you had is easier to understand what is happening without further context, so I prefer your switch back. 
> 
> I think we are fine from (negative) "extreme values" in `doubleValue()` because of the check you have implemented in the first place. i.e. we avoid any potential underflow from `int exp = decExponent - kDigits;`. I think we do need a comment to accompany the check. (Why do we check? why not check the max exponent value?)
> 
> Also, should the check be against `MIN_DECIMAL_EXPONENT - 1` for consistency with `doubleValue()`? (Functionally, I don't think it matters.)

Suggestion:

        if (decExp <= MIN_DECIMAL_EXPONENT) {

This is just a note for future enhancements. No need for a new commit, as the current version is correct and avoids the underflow in `doubleValue()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2242727180

From rgiulietti at openjdk.org  Wed Jul 30 13:42:59 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 30 Jul 2025 13:42:59 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v6]
In-Reply-To: <JdxWpCBHtTssvz1lu08gRSrJr3So7vxoi5hiopLlxLo=.3931a767-c13c-455a-b631-616cbbd250ff@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <JdxWpCBHtTssvz1lu08gRSrJr3So7vxoi5hiopLlxLo=.3931a767-c13c-455a-b631-616cbbd250ff@github.com>
Message-ID: <Cf3Y5Dg_EdG0y5QFVoG4PHL42e2aycbT-UolpugoERc=.c19e2a38-e52c-44b1-8019-ce63b83d843b@github.com>

On Mon, 16 Jun 2025 21:19:45 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>> 
>> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
>> 
>> Testing:
>> - GHA
>> - Local run of tier 2 and jtreg:jdk/java/text
>> - New benchmark: DecimalFormatParseBench
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

Thanks @j3graham for your contribution.

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25644#pullrequestreview-3071606450

From rriggs at openjdk.org  Wed Jul 30 13:43:54 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Jul 2025 13:43:54 GMT
Subject: RFR: 8364317: Explicitly document some assumptions of StringUTF16
In-Reply-To: <vTct6VRmglYJEqYaS3A4oeMBvXEYDRXGtJ_iD1YC2lM=.efc00627-2856-4c45-8dcf-55b1a9907680@github.com>
References: <vTct6VRmglYJEqYaS3A4oeMBvXEYDRXGtJ_iD1YC2lM=.efc00627-2856-4c45-8dcf-55b1a9907680@github.com>
Message-ID: <hmKAKs-R3MxfePVljPrGhPod_R2zLpI4-lKzqjjMnPk=.94f0a547-5589-42ec-aebf-2b871d07174b@github.com>

On Tue, 29 Jul 2025 21:09:59 GMT, Chen Liang <liach at openjdk.org> wrote:

> In #24773, people were concerned that the layout of a UTF16 byte array and a char array may be incompatible. In fact, they are - they are asserted in a corner in `LibraryCallKit::inline_string_char_access` in `library_call.cpp`.
> 
> In addition, another frequent error I see is that contributors have confused the meaning of indices in StringUTF16 - the indices are always in char array indices. I think we should make these explicit to help future maintenance.

looks good

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26541#pullrequestreview-3071613931

From liach at openjdk.org  Wed Jul 30 14:18:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Jul 2025 14:18:49 GMT
Subject: RFR: 8364317: Explicitly document some assumptions of StringUTF16
 [v2]
In-Reply-To: <vTct6VRmglYJEqYaS3A4oeMBvXEYDRXGtJ_iD1YC2lM=.efc00627-2856-4c45-8dcf-55b1a9907680@github.com>
References: <vTct6VRmglYJEqYaS3A4oeMBvXEYDRXGtJ_iD1YC2lM=.efc00627-2856-4c45-8dcf-55b1a9907680@github.com>
Message-ID: <GgfVca9RnmKpTO201qkiJmRZ5w-5PcD9e6DDSLH5juI=.4ce8e98d-6f1b-4768-9f7d-318b3848985e@github.com>

> In #24773, people were concerned that the layout of a UTF16 byte array and a char array may be incompatible. In fact, they are - they are asserted in a corner in `LibraryCallKit::inline_string_char_access` in `library_call.cpp`.
> 
> In addition, another frequent error I see is that contributors have confused the meaning of indices in StringUTF16 - the indices are always in char array indices. I think we should make these explicit to help future maintenance.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Add paragraph for endianness and layout

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26541/files
  - new: https://git.openjdk.org/jdk/pull/26541/files/933557ef..1b052e9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26541&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26541&range=00-01

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26541.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26541/head:pull/26541

PR: https://git.openjdk.org/jdk/pull/26541

From liach at openjdk.org  Wed Jul 30 14:18:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Jul 2025 14:18:50 GMT
Subject: RFR: 8364317: Explicitly document some assumptions of StringUTF16
 [v2]
In-Reply-To: <Mw4qgm9pMKYpC4OEmkrDkX93AX_9DxZkQ0UKrJ6TJKo=.adf38d97-7442-4c93-8f2d-482eb97fabf0@github.com>
References: <vTct6VRmglYJEqYaS3A4oeMBvXEYDRXGtJ_iD1YC2lM=.efc00627-2856-4c45-8dcf-55b1a9907680@github.com>
 <Mw4qgm9pMKYpC4OEmkrDkX93AX_9DxZkQ0UKrJ6TJKo=.adf38d97-7442-4c93-8f2d-482eb97fabf0@github.com>
Message-ID: <PJ5zCV7cZtpQBOtW4pzc9yaJaxwTJblpT3kihl7m3rw=.ec2f3d89-2cb3-4da7-952a-bc8965ed50a1@github.com>

On Wed, 30 Jul 2025 12:07:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add paragraph for endianness and layout
>
> A good initiative, thanks @liach.
> Maybe some words about endianness would be useful as well.

@rgiulietti: I have added a paragraph describing the layout constraints of UTF16 byte arrays. Please check it out.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26541#issuecomment-3136556023

From shaojin.wensj at alibaba-inc.com  Wed Jul 30 14:18:56 2025
From: shaojin.wensj at alibaba-inc.com (wenshao)
Date: Wed, 30 Jul 2025 22:18:56 +0800
Subject: =?UTF-8?B?UmV1c2UgdGhlIFN0cmluZ1VURjE2OjpwdXRDaGFyc1NCIG1ldGhvZCBpbnN0ZWFkIG9mIHRo?=
 =?UTF-8?B?ZSBJbnRyaW5zaWMgaW4gdGhlIFN0cmluZ1VURjE2Ojp0b0J5dGVz?=
Message-ID: <086fd3c9-30e0-4294-b674-ece0bd91051c.shaojin.wensj@alibaba-inc.com>

In the discussion of `8355177: Speed up StringBuilder::append(char[]) via Unsafe::copyMemory` (https://github.com/openjdk/jdk/pull/24773 <https://github.com/openjdk/jdk/pull/24773 >), @liach (Chen Liang) suggested reusing the StringUTF16::putCharsSB method introduced in PR #24773 instead of the Intrinsic implementation in the StringUTF16::toBytes method.
Original:
```java
 @IntrinsicCandidate
 public static byte[] toBytes(char[] value, int off, int len) {
 byte[] val = newBytesFor(len);
 for (int i = 0; i < len; i++) {
 putChar(val, i, value[off]);
 off++;
 }
 return val;
 }
```
After:
```java
 public static byte[] toBytes(char[] value, int off, int len) {
 byte[] val = (byte[]) Unsafe.getUnsafe().allocateUninitializedArray(byte.class, newBytesLength(len));
 putCharsSB(val, 0, value, off, off + len);
 return val;
 }
```
This replacement does not degrade performance. Running StringConstructor.newStringFromCharsMixedBegin verified that performance is consistent with the original on x64 and slightly improved on aarch64.
The implementation after replacing the Intrinsic implementation removed 100 lines of C++ code, leaving only Java and Unsafe code, no Intrinsic or C++ code, which makes the code more maintainable.
I've submitted a draft PR https://github.com/openjdk/jdk/pull/26553 <https://github.com/openjdk/jdk/pull/26553 > , please give me some feedback.
-
Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250730/8a7a6854/attachment.htm>

From rgiulietti at openjdk.org  Wed Jul 30 14:30:55 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 30 Jul 2025 14:30:55 GMT
Subject: RFR: 8364317: Explicitly document some assumptions of StringUTF16
 [v2]
In-Reply-To: <GgfVca9RnmKpTO201qkiJmRZ5w-5PcD9e6DDSLH5juI=.4ce8e98d-6f1b-4768-9f7d-318b3848985e@github.com>
References: <vTct6VRmglYJEqYaS3A4oeMBvXEYDRXGtJ_iD1YC2lM=.efc00627-2856-4c45-8dcf-55b1a9907680@github.com>
 <GgfVca9RnmKpTO201qkiJmRZ5w-5PcD9e6DDSLH5juI=.4ce8e98d-6f1b-4768-9f7d-318b3848985e@github.com>
Message-ID: <O_T5NDO8jGcoNxNTc_qIpb6B1joxGLCsz8pJPBCczG0=.2db066be-d969-4799-9006-7508dea069f8@github.com>

On Wed, 30 Jul 2025 14:18:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In #24773, people were concerned that the layout of a UTF16 byte array and a char array may be incompatible. In fact, they are - they are asserted in a corner in `LibraryCallKit::inline_string_char_access` in `library_call.cpp`.
>> 
>> In addition, another frequent error I see is that contributors have confused the meaning of indices in StringUTF16 - the indices are always in char array indices. I think we should make these explicit to help future maintenance.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add paragraph for endianness and layout

Looks fine

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26541#pullrequestreview-3071880444

From rriggs at openjdk.org  Wed Jul 30 15:22:57 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Jul 2025 15:22:57 GMT
Subject: RFR: 8364317: Explicitly document some assumptions of StringUTF16
 [v2]
In-Reply-To: <GgfVca9RnmKpTO201qkiJmRZ5w-5PcD9e6DDSLH5juI=.4ce8e98d-6f1b-4768-9f7d-318b3848985e@github.com>
References: <vTct6VRmglYJEqYaS3A4oeMBvXEYDRXGtJ_iD1YC2lM=.efc00627-2856-4c45-8dcf-55b1a9907680@github.com>
 <GgfVca9RnmKpTO201qkiJmRZ5w-5PcD9e6DDSLH5juI=.4ce8e98d-6f1b-4768-9f7d-318b3848985e@github.com>
Message-ID: <296jM4sHj3qgH2ym2cCSHowm-u3LDjt6TKQz9u7q_Ug=.bea9ec3c-8932-4429-aae3-4965564ecca7@github.com>

On Wed, 30 Jul 2025 14:18:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In #24773, people were concerned that the layout of a UTF16 byte array and a char array may be incompatible. In fact, they are - they are asserted in a corner in `LibraryCallKit::inline_string_char_access` in `library_call.cpp`.
>> 
>> In addition, another frequent error I see is that contributors have confused the meaning of indices in StringUTF16 - the indices are always in char array indices. I think we should make these explicit to help future maintenance.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add paragraph for endianness and layout

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26541#pullrequestreview-3072147635

From jaikiran.pai at oracle.com  Wed Jul 30 15:40:32 2025
From: jaikiran.pai at oracle.com (jaikiran.pai at oracle.com)
Date: Wed, 30 Jul 2025 21:10:32 +0530
Subject: Reuse the StringUTF16::putCharsSB method instead of the Intrinsic
 in the StringUTF16::toBytes
In-Reply-To: <086fd3c9-30e0-4294-b674-ece0bd91051c.shaojin.wensj@alibaba-inc.com>
References: <086fd3c9-30e0-4294-b674-ece0bd91051c.shaojin.wensj@alibaba-inc.com>
Message-ID: <c8e344e8-f63a-49b1-b5d2-3fb19977e74a@oracle.com>

I'll let others knowledgeable in this area to comment and provide inputs 
to this proposal. I just want to say thank you for bringing up this 
discussion to the mailing list first, providing the necessary context 
and explanation and seeking feedback, before creating a JBS issue or a 
RFR PR.

-Jaikiran

On 30/07/25 7:48 pm, wenshao wrote:
> In the discussion of `8355177: Speed up StringBuilder::append(char[]) 
> via Unsafe::copyMemory` (https://github.com/openjdk/jdk/pull/24773), 
> @liach (Chen Liang) suggested reusing the StringUTF16::putCharsSB 
> method introduced in PR #24773 instead of the Intrinsic implementation 
> in the StringUTF16::toBytes method.
>
> Original:
> ```java
> ? ? @IntrinsicCandidate
> ? ? public static byte[] toBytes(char[] value, int off, int len) {
> ? ? ? ? byte[] val = newBytesFor(len);
> ? ? ? ? for (int i = 0; i < len; i++) {
> ? ? ? ? ? ? putChar(val, i, value[off]);
> ? ? ? ? ? ? off++;
> ? ? ? ? }
> ? ? ? ? return val;
> ? ? }
> ```
>
> After:
> ```java
> ? ? public static byte[] toBytes(char[] value, int off, int len) {
> ? ? ? ? byte[] val = (byte[]) 
> Unsafe.getUnsafe().allocateUninitializedArray(byte.class, 
> newBytesLength(len));
> ? ? ? ? putCharsSB(val, 0, value, off, off + len);
> ? ? ? ? return val;
> ? ? }
> ```
>
> This replacement does not degrade performance. Running 
> StringConstructor.newStringFromCharsMixedBegin verified that 
> performance is consistent with the original on x64 and slightly 
> improved on aarch64.
>
> The implementation after replacing the Intrinsic implementation 
> removed 100 lines of C++ code, leaving only Java and Unsafe code, no 
> Intrinsic or C++ code, which makes the code more maintainable.
>
> I've submitted a draft PR https://github.com/openjdk/jdk/pull/26553 , 
> please give me some feedback.
> -
> Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250730/7d81297b/attachment.htm>

From jpai at openjdk.org  Wed Jul 30 16:29:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Jul 2025 16:29:54 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <q2sYANTiDxR1R_UP_6R21fzUeWoB1D0rYVZE0k1HSOA=.d6778ae4-878d-48df-84ea-0fa1f05dfb1d@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

Hello Hao,

> Hi, I encountered two jtreg failures with this new version `8` on both AArch64 and x86_64 platforms.
> Note that these two jtreg cases can pass with jtreg `7.5.2+1` version.

Thank you for bringing this up. I'm able to reproduce this issue with this newer version of jtreg. I'll take a look to see what's going on.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3137036826

From jlu at openjdk.org  Wed Jul 30 16:40:55 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 30 Jul 2025 16:40:55 GMT
Subject: [jdk25] RFR: 8364089: JDK 25 RDP2 L10n resource files update
In-Reply-To: <PIPIWgdCQBNP85HGvDyTg2VDsebvTiXhA9nGg_5O6P0=.b850540b-0994-48d1-af28-e68d00c01c5d@github.com>
References: <PIPIWgdCQBNP85HGvDyTg2VDsebvTiXhA9nGg_5O6P0=.b850540b-0994-48d1-af28-e68d00c01c5d@github.com>
Message-ID: <xkhUaFN8y_xbnUnDkDFSqVxm7fODAoEdtDXUscBaC8M=.d2699526-2397-4477-889a-ebf18486b1b8@github.com>

On Wed, 30 Jul 2025 02:12:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

> 8364089: JDK 25 RDP2 L10n resource files update

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_de.properties line 139:

> 137: doclet.Preview_Label=Vorschau
> 138: doclet.Preview_Mark=PREVIEW
> 139: doclet.Preview_Notes=Hinweise zur Vorschau-API

The changes in this group of localized files should not be making it into JDK25 as the associated change to the original file made it into 26 and was not backported to 25.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26543#discussion_r2243282750

From coleenp at openjdk.org  Wed Jul 30 16:57:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 30 Jul 2025 16:57:56 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v4]
In-Reply-To: <RW85vjuDstNZuhzlit7pY9R8ULLh0x5DiZcJiQd-Usc=.43d5b101-3ba7-4f23-942b-09e97ee03f9a@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <aIi03VimwLejWVSdgsEApkb-raD-KfRH8NKLHEHhmGo=.2b6f1d8e-9c67-4dce-a595-5d94408184e3@github.com>
 <RW85vjuDstNZuhzlit7pY9R8ULLh0x5DiZcJiQd-Usc=.43d5b101-3ba7-4f23-942b-09e97ee03f9a@github.com>
Message-ID: <rBLPujmr3-v-Q7wsXltMiQYVvequ6HozaHYVEppXE8o=.36c1331f-2592-4c18-a33b-14e307848f91@github.com>

On Wed, 30 Jul 2025 12:21:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
>>   
>>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>
> src/hotspot/share/opto/memnode.cpp line 1986:
> 
>> 1984:     // (Folds up the 2nd indirection in Reflection.getClassAccessFlags(aClassConstant).)
>> 1985:     assert(Opcode() == Op_LoadUS, "must load an unsigned short from _access_flags");
>> 1986:     return TypeInt::make(klass->access_flags());
> 
> I think this optimization should stay because the `_getSuperclass` intrinsic still emits a load from `Klass::access_flags_offset()` that could potentially be optimized here, see:
> https://github.com/openjdk/jdk/blob/ed70910b0f3e1b19d915ec13ac3434407d01bc5d/src/hotspot/share/opto/library_call.cpp#L4081-L4088
> ->
> https://github.com/openjdk/jdk/blob/ed70910b0f3e1b19d915ec13ac3434407d01bc5d/src/hotspot/share/opto/library_call.cpp#L3970-L3973
> 
> You can still remove the lines referencing `Reflection.getClassAccessFlags`.

Thank you, right, the code still references Klass::_access_flags.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2243330614

From jrose at openjdk.org  Wed Jul 30 17:38:57 2025
From: jrose at openjdk.org (John R Rose)
Date: Wed, 30 Jul 2025 17:38:57 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: <GYn-_oE8pt748YCLrumWctK97Yxjru2FXHlSc2CO7xQ=.6c329f3d-e76e-4d23-a407-c6a9916e54ef@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

Changes requested by jrose (Reviewer).

src/hotspot/share/prims/unsafe.cpp line 496:

> 494:     Symbol *name = fs.name();
> 495:     if (name->equals(utf_name)) {
> 496:       offset = fs.offset();

While you are here, if you keep this check, rename this particular function `find_field_offset` to `find_nonstatic_field_offset` (not the other one that takes the "must be static" flag).

The logic, as written, is difficult to understand because of the behavioral difference between the two overloading.

(I note that "instance field" is also a term of art in our code base, but "nonstatic_field" is more common.)

Alternatively, and probably better, take out this particular check (restoring equal access to static and non-static) and just rely on the checks in Java code.  Such checks are almost always better (easier to reason about by humans and JITs) than checks in C++ code.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25945#pullrequestreview-3072687621
PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2243419037

From jrose at openjdk.org  Wed Jul 30 17:49:59 2025
From: jrose at openjdk.org (John R Rose)
Date: Wed, 30 Jul 2025 17:49:59 GMT
Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v4]
In-Reply-To: <3txKdBpCETHPOp_Dd2IH29b_muPVacABqp5Yw8pX9pk=.ea4e0012-c545-4ed0-9867-e533bf6d93d5@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>
 <3txKdBpCETHPOp_Dd2IH29b_muPVacABqp5Yw8pX9pk=.ea4e0012-c545-4ed0-9867-e533bf6d93d5@github.com>
Message-ID: <af1cGP0twD5nTKCd6nbHMYG4X_AVhjql3glyk9-44DY=.06cbe55e-d7bf-4e17-b88d-8e74517311fb@github.com>

On Tue, 24 Jun 2025 18:40:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 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.

As I commented on the C++ change, I think it's better to put the check in Java rather than C++.

The behavioral results are equivalent, right?  It is fine to upgrade the InternalError to IAE; InternalError is by definition a poorly-defined state, and IAE is a less poorly defined way to report it.  Changing that path to throw IAE is better, since it aligns with other field-query APIs.  Because we control use of Unsafe (in this package) we can make small changes like this and just adjust our own code if something breaks.

Error checks and validations in Java code will be 10x clearer (more maintainable, scrutable to JITs) than logic in the C++ code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2243456096

From jrose at openjdk.org  Wed Jul 30 18:00:57 2025
From: jrose at openjdk.org (John R Rose)
Date: Wed, 30 Jul 2025 18:00:57 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: <AZFNXLcev_CrFZPKzeBVTgLXn3gnb3qxX93PDtPFGbE=.056611bd-d7cf-438c-ad15-d30da886362b@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/jdk/internal/misc/Unsafe.java line 3861:

> 3859:     private native void copySwapMemory0(Object srcBase, long srcOffset, Object destBase, long destOffset, long bytes, long elemSize);
> 3860:     private native long objectFieldOffset0(Field f); // throws IAE
> 3861:     private native long objectFieldOffset1(Class<?> c, String name); // throws InternalError

Ugh; this IE is part of the problem.  You could push an IAE into the C++ code for symmetry, or start pushing more IAE logic into the Java code (my preference, but a bigger change perhaps).

I can tell you that the original intention of choosing InternalError is to mark places where the caller has a responsibility to make InternalError impossible.  InternalError is not intended to trigger further processing; it denotes system failure.

test/jdk/jdk/internal/misc/Unsafe/AddressComputationContractTest.java line 69:

> 67:         assertThrows(NullPointerException.class, () -> getUnsafe().objectFieldOffset(null, "instanceField"));
> 68:         assertThrows(NullPointerException.class, () -> getUnsafe().objectFieldOffset(AddressComputationContractTest.class, null));
> 69:         assertThrows(InternalError.class, () -> getUnsafe().objectFieldOffset(AddressComputationContractTest.class, "doesNotExist"));

This is a malformed test on a malformed API.  VirtualMachineError exceptions signal system failure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2243472376
PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2243477795

From vyazici at openjdk.org  Wed Jul 30 18:16:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 30 Jul 2025 18:16:55 GMT
Subject: RFR: 8364317: Explicitly document some assumptions of StringUTF16
 [v2]
In-Reply-To: <GgfVca9RnmKpTO201qkiJmRZ5w-5PcD9e6DDSLH5juI=.4ce8e98d-6f1b-4768-9f7d-318b3848985e@github.com>
References: <vTct6VRmglYJEqYaS3A4oeMBvXEYDRXGtJ_iD1YC2lM=.efc00627-2856-4c45-8dcf-55b1a9907680@github.com>
 <GgfVca9RnmKpTO201qkiJmRZ5w-5PcD9e6DDSLH5juI=.4ce8e98d-6f1b-4768-9f7d-318b3848985e@github.com>
Message-ID: <hnKNOiXnVxlGplBmRIaptRMuPVMc_gXh_vX3SV3Mz8E=.236d73c8-6aa8-4c3c-b456-1b27f66ae5a7@github.com>

On Wed, 30 Jul 2025 14:18:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In #24773, people were concerned that the layout of a UTF16 byte array and a char array may be incompatible. In fact, they are - they are asserted in a corner in `LibraryCallKit::inline_string_char_access` in `library_call.cpp`.
>> 
>> In addition, another frequent error I see is that contributors have confused the meaning of indices in StringUTF16 - the indices are always in char array indices. I think we should make these explicit to help future maintenance.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add paragraph for endianness and layout

> All indices and sizes for byte arrays carrying UTF-16 data are in number of
> `char`s instead of number of bytes.

@liach, given the relatively big API surface of `j.l.StringUTF16`, are we certain about this?

src/java.base/share/classes/java/lang/StringUTF16.java line 51:

> 49: ///
> 50: /// All indices and sizes for byte arrays carrying UTF16 data are in number of
> 51: /// chars instead of  number of bytes.

Nit on cosmetics:

Suggestion:

/// UTF-16 `String` operations.
///
/// UTF-16 byte arrays have the identical layout as `char` arrays. They share the
/// same base offset and scale, and for each two-byte unit interpreted as a `char`,
/// it has the same endianness as a `char`, which is the platform endianness.
/// This is ensured in the static initializer of [StringUTF16].
///
/// All indices and sizes for byte arrays carrying UTF-16 data are in number of
/// `char`s instead of number of bytes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26541#issuecomment-3137375297
PR Review Comment: https://git.openjdk.org/jdk/pull/26541#discussion_r2243513617

From roger.riggs at oracle.com  Wed Jul 30 19:17:16 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 30 Jul 2025 15:17:16 -0400
Subject: Reuse the StringUTF16::putCharsSB method instead of the Intrinsic
 in the StringUTF16::toBytes
In-Reply-To: <c8e344e8-f63a-49b1-b5d2-3fb19977e74a@oracle.com>
References: <086fd3c9-30e0-4294-b674-ece0bd91051c.shaojin.wensj@alibaba-inc.com>
 <c8e344e8-f63a-49b1-b5d2-3fb19977e74a@oracle.com>
Message-ID: <9b1f2b83-2e0e-443f-a1af-307bcf871974@oracle.com>

Hi,

Unsafe.uninitializedArray and StringConcatHelper.newArray was created 
for the exclusive use of StringConcatHelper and by? HotSpot 
optimizations. Unsafe.uninitializedArray and StringConcatHelper.newArray 
area very sensitive APIs and should NOT be used anywhere except in 
StringConcatHelper and HotSpot.

Regards, Roger


On 7/30/25 11:40 AM, jaikiran.pai at oracle.com wrote:
>
> I'll let others knowledgeable in this area to comment and provide 
> inputs to this proposal. I just want to say thank you for bringing up 
> this discussion to the mailing list first, providing the necessary 
> context and explanation and seeking feedback, before creating a JBS 
> issue or a RFR PR.
>
> -Jaikiran
>
> On 30/07/25 7:48 pm, wenshao wrote:
>> In the discussion of `8355177: Speed up StringBuilder::append(char[]) 
>> via Unsafe::copyMemory` (https://github.com/openjdk/jdk/pull/24773), 
>> @liach (Chen Liang) suggested reusing the StringUTF16::putCharsSB 
>> method introduced in PR #24773 instead of the Intrinsic 
>> implementation in the StringUTF16::toBytes method.
>>
>> Original:
>> ```java
>> ? ? @IntrinsicCandidate
>> ? ? public static byte[] toBytes(char[] value, int off, int len) {
>> ? ? ? ? byte[] val = newBytesFor(len);
>> ? ? ? ? for (int i = 0; i < len; i++) {
>> ? ? ? ? ? ? putChar(val, i, value[off]);
>> ? ? ? ? ? ? off++;
>> ? ? ? ? }
>> ? ? ? ? return val;
>> ? ? }
>> ```
>>
>> After:
>> ```java
>> ? ? public static byte[] toBytes(char[] value, int off, int len) {
>> ? ? ? ? byte[] val = (byte[]) 
>> Unsafe.getUnsafe().allocateUninitializedArray(byte.class, 
>> newBytesLength(len));
>> ? ? ? ? putCharsSB(val, 0, value, off, off + len);
>> ? ? ? ? return val;
>> ? ? }
>> ```
>>
>> This replacement does not degrade performance. Running 
>> StringConstructor.newStringFromCharsMixedBegin verified that 
>> performance is consistent with the original on x64 and slightly 
>> improved on aarch64.
>>
>> The implementation after replacing the Intrinsic implementation 
>> removed 100 lines of C++ code, leaving only Java and Unsafe code, no 
>> Intrinsic or C++ code, which makes the code more maintainable.
>>
>> I've submitted a draft PR https://github.com/openjdk/jdk/pull/26553 , 
>> please give me some feedback.
>> -
>> Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250730/8e9f1e76/attachment-0001.htm>

From coleenp at openjdk.org  Wed Jul 30 19:25:34 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 30 Jul 2025 19:25:34 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5]
In-Reply-To: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
Message-ID: <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>

> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Restore c2 optimization.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26517/files
  - new: https://git.openjdk.org/jdk/pull/26517/files/45b92c5c..fb6c15e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26517&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26517&range=03-04

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26517/head:pull/26517

PR: https://git.openjdk.org/jdk/pull/26517

From achung at openjdk.org  Wed Jul 30 19:34:17 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 30 Jul 2025 19:34:17 GMT
Subject: [jdk25] RFR: 8364089: JDK 25 RDP2 L10n resource files update [v2]
In-Reply-To: <PIPIWgdCQBNP85HGvDyTg2VDsebvTiXhA9nGg_5O6P0=.b850540b-0994-48d1-af28-e68d00c01c5d@github.com>
References: <PIPIWgdCQBNP85HGvDyTg2VDsebvTiXhA9nGg_5O6P0=.b850540b-0994-48d1-af28-e68d00c01c5d@github.com>
Message-ID: <v0nqg3Z3nBeIQ_S-Q2flU-e-oV1J-_vOyoRf-Dbel9k=.268b6637-b992-4368-a138-2c4ae19d4a44@github.com>

> 8364089: JDK 25 RDP2 L10n resource files update

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  revert files with changes that didn't get backported

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26543/files
  - new: https://git.openjdk.org/jdk/pull/26543/files/40ddea4d..b9c25798

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26543&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26543&range=00-01

  Stats: 12 lines in 3 files changed: 3 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26543.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26543/head:pull/26543

PR: https://git.openjdk.org/jdk/pull/26543

From rriggs at openjdk.org  Wed Jul 30 20:27:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Jul 2025 20:27:55 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <5gvsQ413EdL2Lvs-rmusDgTPMiT7lVag5H4fF5Fk4P4=.1416ddb9-6161-419e-8fc2-653e073dd399@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <ZMUB7AU3sYZp_6eERmc8K7rkiaEMi5XGqbF0GKfVgYc=.772ca1c9-e101-4d4d-9c27-22622ca0a584@github.com>
 <5gvsQ413EdL2Lvs-rmusDgTPMiT7lVag5H4fF5Fk4P4=.1416ddb9-6161-419e-8fc2-653e073dd399@github.com>
Message-ID: <Kl4A5I4J-FT_bk4sf7CSrn8gYwKFda1I2m22Rud2exs=.27b271f9-c7d4-4c9e-8860-0e6ab5c38b23@github.com>

On Tue, 29 Jul 2025 19:42:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Fields are initialized by injection in javaClasses instead of through this constructor, so it's easy for us to accidentally forget to inject a field.
>
> For IDENTITY, I didn't have to inject that one because the Java code knew when to set it, not the JVM code reading the data out of the classfile.  And the logic belongs in the Java code, not the JVM. This one comes from the classfile, there isn't another way to get the information to the java.lang.Class.

The VM and Java use the same logic for the value of isIdentity(). 
It is computed from as many a 5 fields/flags. At present, it has to be computed on each call to Class.isIdentity().
It would be reasonable to compute the value once in the constructor, but the code in the constructor is not run.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2243785633

From jlu at openjdk.org  Wed Jul 30 20:42:59 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 30 Jul 2025 20:42:59 GMT
Subject: [jdk25] RFR: 8364089: JDK 25 RDP2 L10n resource files update [v2]
In-Reply-To: <v0nqg3Z3nBeIQ_S-Q2flU-e-oV1J-_vOyoRf-Dbel9k=.268b6637-b992-4368-a138-2c4ae19d4a44@github.com>
References: <PIPIWgdCQBNP85HGvDyTg2VDsebvTiXhA9nGg_5O6P0=.b850540b-0994-48d1-af28-e68d00c01c5d@github.com>
 <v0nqg3Z3nBeIQ_S-Q2flU-e-oV1J-_vOyoRf-Dbel9k=.268b6637-b992-4368-a138-2c4ae19d4a44@github.com>
Message-ID: <wRuz7ThyKzfYGvsVEpePVOHrbwJfN7_xfIJhvAR3dDo=.b11192bf-411c-4986-ba1b-3d4faeddfb57@github.com>

On Wed, 30 Jul 2025 19:34:17 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [c671089d](https://github.com/openjdk/jdk/commit/c671089d6e9aa147ffd056a83c84abf6aff444dc) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Alisen Chung on 30 Jul 2025 and was reviewed by Justin Lu, Naoto Sato, Damon Nguyen and Alexey Semenyuk.
>> 
>> Thanks!
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert files with changes that didn't get backported

Marked as reviewed by jlu (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26543#pullrequestreview-3073281940

From naoto at openjdk.org  Wed Jul 30 21:57:57 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 30 Jul 2025 21:57:57 GMT
Subject: [jdk25] RFR: 8364089: JDK 25 RDP2 L10n resource files update [v2]
In-Reply-To: <v0nqg3Z3nBeIQ_S-Q2flU-e-oV1J-_vOyoRf-Dbel9k=.268b6637-b992-4368-a138-2c4ae19d4a44@github.com>
References: <PIPIWgdCQBNP85HGvDyTg2VDsebvTiXhA9nGg_5O6P0=.b850540b-0994-48d1-af28-e68d00c01c5d@github.com>
 <v0nqg3Z3nBeIQ_S-Q2flU-e-oV1J-_vOyoRf-Dbel9k=.268b6637-b992-4368-a138-2c4ae19d4a44@github.com>
Message-ID: <EsCNsZwCZSiVF06M0mhsDC0dovp2YHOo2W4MvT-M_m8=.0ba284f8-a0f3-46dc-9c31-1243ce6a0827@github.com>

On Wed, 30 Jul 2025 19:34:17 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [c671089d](https://github.com/openjdk/jdk/commit/c671089d6e9aa147ffd056a83c84abf6aff444dc) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Alisen Chung on 30 Jul 2025 and was reviewed by Justin Lu, Naoto Sato, Damon Nguyen and Alexey Semenyuk.
>> 
>> Thanks!
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert files with changes that didn't get backported

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26543#pullrequestreview-3073437019

From achung at openjdk.org  Wed Jul 30 22:55:02 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 30 Jul 2025 22:55:02 GMT
Subject: [jdk25] Integrated: 8364089: JDK 25 RDP2 L10n resource files update
In-Reply-To: <PIPIWgdCQBNP85HGvDyTg2VDsebvTiXhA9nGg_5O6P0=.b850540b-0994-48d1-af28-e68d00c01c5d@github.com>
References: <PIPIWgdCQBNP85HGvDyTg2VDsebvTiXhA9nGg_5O6P0=.b850540b-0994-48d1-af28-e68d00c01c5d@github.com>
Message-ID: <LGiHCy9E61ZKaey8M3fWSKAZGqtheCIZSsXvLVea8tQ=.e89ade9a-b054-4e01-8f45-970e9085e511@github.com>

On Wed, 30 Jul 2025 02:12:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [c671089d](https://github.com/openjdk/jdk/commit/c671089d6e9aa147ffd056a83c84abf6aff444dc) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Alisen Chung on 30 Jul 2025 and was reviewed by Justin Lu, Naoto Sato, Damon Nguyen and Alexey Semenyuk.
> 
> Thanks!

This pull request has now been integrated.

Changeset: bf31e507
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bf31e507541a8e4a352da09d0a13a8356f78a1eb
Stats:     78 lines in 11 files changed: 68 ins; 6 del; 4 mod

8364089: JDK 25 RDP2 L10n resource files update

Reviewed-by: jlu, naoto
Backport-of: c671089d6e9aa147ffd056a83c84abf6aff444dc

-------------

PR: https://git.openjdk.org/jdk/pull/26543

From duke at openjdk.org  Wed Jul 30 22:57:24 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 30 Jul 2025 22:57:24 GMT
Subject: RFR: 8077587: BigInteger Roots [v62]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <QWScffmMYh9VMeCctFbP5R_tx2dgG4rQHwCkKBJdxwY=.92f6579d-9892-45eb-80ae-4cfcc8305ada@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Optimization for large degree's values

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/a724dc8b..2ffeedef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=61
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=60-61

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From duke at openjdk.org  Wed Jul 30 23:00:23 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 30 Jul 2025 23:00:23 GMT
Subject: RFR: 8077587: BigInteger Roots [v63]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <WuEmYI_nlVj_-4_Z8TsXGHbiz1olZgpNxmxYGvWj9tM=.e843efa0-7a96-496b-ba24-cb24c79e90b0@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Optimization for large degree values

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/2ffeedef..d67f9ff7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=62
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=61-62

  Stats: 118 lines in 1 file changed: 41 ins; 26 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From duke at openjdk.org  Wed Jul 30 23:04:51 2025
From: duke at openjdk.org (fabioromano1)
Date: Wed, 30 Jul 2025 23:04:51 GMT
Subject: RFR: 8077587: BigInteger Roots [v64]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <OYGnVYmW3FZte7JztmZW1dUcBIaGeWh1ayL6iD0fRxc=.0bb10687-593d-44c3-b4ab-f1b27d0b7c61@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Useless instruction

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24898/files
  - new: https://git.openjdk.org/jdk/pull/24898/files/d67f9ff7..61c01d34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=63
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=62-63

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From sviswanathan at openjdk.org  Wed Jul 30 23:51:54 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 30 Jul 2025 23:51:54 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v2]
In-Reply-To: <9pe9LuUrBnk6A2TQ2emhgonljAvnJLcmSV_lEbrYIlo=.fec9b081-d6ae-4d85-8826-489828d9f442@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <9pe9LuUrBnk6A2TQ2emhgonljAvnJLcmSV_lEbrYIlo=.fec9b081-d6ae-4d85-8826-489828d9f442@github.com>
Message-ID: <JZZ83ZL8aCcuAHnXqQqPhdVeOHWOysm_vNKUE87jLgY=.92273cdc-bfca-4897-963c-382341c5b226@github.com>

On Thu, 17 Jul 2025 18:46:06 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.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move error bound to separate section in comment header

src/hotspot/cpu/x86/stubGenerator_x86_64_sinh.cpp line 325:

> 323:   __ jcc(Assembler::aboveEqual, L_2TAG_PACKET_0_0_2); // Branch only if |x| is not in [23/64, 3*2^8)
> 324:   __ movsd(xmm3, ExternalAddress(HALFMASK), r11 /*rscratch*/);
> 325:   __ movsd(xmm1, ExternalAddress(L2E), r11 /*rscratch*/);

xmm1 is used at L_2TAG_PACKET_0_0_2 -> L_2TAG_PACKET_3_0_2 line 507 below so should be loaded prior to L_2TAG_PACKET_0_0_2.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26152#discussion_r2243550202

From shaojin.wensj at alibaba-inc.com  Thu Jul 31 02:45:55 2025
From: shaojin.wensj at alibaba-inc.com (wenshao)
Date: Thu, 31 Jul 2025 10:45:55 +0800
Subject: =?UTF-8?B?5Zue5aSN77yaUmV1c2UgdGhlIFN0cmluZ1VURjE2OjpwdXRDaGFyc1NCIG1ldGhvZCBpbnN0?=
 =?UTF-8?B?ZWFkIG9mIHRoZSBJbnRyaW5zaWMgaW4gdGhlIFN0cmluZ1VURjE2Ojp0b0J5dGVz?=
In-Reply-To: <9b1f2b83-2e0e-443f-a1af-307bcf871974@oracle.com>
References: <086fd3c9-30e0-4294-b674-ece0bd91051c.shaojin.wensj@alibaba-inc.com>
 <c8e344e8-f63a-49b1-b5d2-3fb19977e74a@oracle.com>,
 <9b1f2b83-2e0e-443f-a1af-307bcf871974@oracle.com>
Message-ID: <a7120887-02d3-475f-806a-efcf186f70c3.shaojin.wensj@alibaba-inc.com>

Thanks to Roger Riggs for suggesting that the code should not be called with Unsafe.uninitializedArray.
After replacing it with `new byte[]` and running `StringConstructor.newStringFromCharsMixedBegin`, I verified that performance remained consistent on x64. On aarch64, performance improved by 8% for size = 7, but decreased by 7% for size = 64.
For detailed performance data, see the Markdown data in the draft pull request I submitted.https://github.com/openjdk/jdk/pull/26553#issuecomment-3138357748 <https://github.com/openjdk/jdk/pull/26553#issuecomment-3138357748 >
-
Shaojin Wen
------------------------------------------------------------------
????Roger Riggs <roger.riggs at oracle.com>
?????2025?7?31?(??) 03:17
????"core-libs-dev"<core-libs-dev at openjdk.org>
????Re: Reuse the StringUTF16::putCharsSB method instead of the Intrinsic in the StringUTF16::toBytes
Hi,
 Unsafe.uninitializedArray and StringConcatHelper.newArray was created for the exclusive use of StringConcatHelper and by HotSpot optimizations. Unsafe.uninitializedArray and StringConcatHelper.newArray area very sensitive APIs and should NOT be used anywhere except in StringConcatHelper and HotSpot.
 Regards, Roger
On 7/30/25 11:40 AM, jaikiran.pai at oracle.com <mailto:jaikiran.pai at oracle.com > wrote:
I'll let others knowledgeable in this area to comment and provide inputs to this proposal. I just want to say thank you for bringing up this discussion to the mailing list first, providing the necessary context and explanation and seeking feedback, before creating a JBS issue or a RFR PR.
-Jaikiran
On 30/07/25 7:48 pm, wenshao wrote:
In the discussion of `8355177: Speed up StringBuilder::append(char[]) via Unsafe::copyMemory` (https://github.com/openjdk/jdk/pull/24773 <https://github.com/openjdk/jdk/pull/24773 >), @liach (Chen Liang) suggested reusing the StringUTF16::putCharsSB method introduced in PR #24773 instead of the Intrinsic implementation in the StringUTF16::toBytes method. 
Original: 
```java
 @IntrinsicCandidate
 public static byte[] toBytes(char[] value, int off, int len) {
 byte[] val = newBytesFor(len);
 for (int i = 0; i < len; i++) {
 putChar(val, i, value[off]);
 off++;
 }
 return val;
 }
```
After:
```java
 public static byte[] toBytes(char[] value, int off, int len) {
 byte[] val = (byte[]) Unsafe.getUnsafe().allocateUninitializedArray(byte.class, newBytesLength(len));
 putCharsSB(val, 0, value, off, off + len);
 return val;
 }
```
This replacement does not degrade performance. Running StringConstructor.newStringFromCharsMixedBegin verified that performance is consistent with the original on x64 and slightly improved on aarch64.
The implementation after replacing the Intrinsic implementation removed 100 lines of C++ code, leaving only Java and Unsafe code, no Intrinsic or C++ code, which makes the code more maintainable.
I've submitted a draft PR https://github.com/openjdk/jdk/pull/26553 <https://github.com/openjdk/jdk/pull/26553 > , please give me some feedback.
-
Shaojin Wen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250731/bfbc7faf/attachment-0001.htm>

From duke at openjdk.org  Thu Jul 31 08:40:40 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 31 Jul 2025 08:40:40 GMT
Subject: RFR: 8077587: BigInteger Roots [v65]
In-Reply-To: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
Message-ID: <p9czGdddIQSzTEdkkzSXuCfUkR36LTK5rB1SRif2quY=.797e82f7-c702-4856-9b34-faf18a2e34a5@github.com>

> This PR implements nth root computation for BigIntegers using Newton method.

fabioromano1 has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 111 commits:

 - Merge branch 'openjdk:master' into nth-root-branch
 - Update MutableBigInteger.java
 - Useless instruction
 - Optimization for large degree values
 - Optimization for large degree's values
 - Update javadoc
 - Refine comments
 - Refine the comment
 - Comment
 - More comments
 - ... and 101 more: https://git.openjdk.org/jdk/compare/b9f7caed...dbf7b522

-------------

Changes: https://git.openjdk.org/jdk/pull/24898/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=64
  Stats: 481 lines in 3 files changed: 478 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898

PR: https://git.openjdk.org/jdk/pull/24898

From mcimadamore at openjdk.org  Thu Jul 31 09:53:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 31 Jul 2025 09:53:58 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: <Ff05ao90-5o4GMTnLclSrFfBY8y3WTKWROAccW_Gw1s=.58507938-39d3-46e2-ae9f-e641c87acb57@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 51:

> 49:     public static final AddressLayout C_POINTER = ValueLayout.ADDRESS
> 50:             .withTargetLayout(MemoryLayout.sequenceLayout(Long.MAX_VALUE, JAVA_BYTE));
> 51:     public static final ValueLayout.OfLong C_LONG = (ValueLayout.OfLong) Linker.nativeLinker().canonicalLayouts().get("long");

This seems problematic. On Windows, the C type `long` has a `JAVA_INT` layout, because it only uses 32 bits. The reason jextract re-generates all these constants is that they can, in general, vary by platform, so my general feeling is that we can't just have a shared set of layout constants at these level -- the constants will need to be added in the platform-specific directories. If you want to make this layer more portable, then the `C_LONG` constant should be dropped, and clients should use either `C_INT` or `C_LONG_LONG` (which is what most portable C APIs end up doing anyway).

Another possible way to have a more robust shared layer is to use definitions in stdint.h -- e.g. not `C_INT`, but `C_INT32_T` (but then you might have issues, as the jextract-generated files you are importing depend on names like `C_INT`).

src/java.base/share/classes/jdk/internal/ffi/util/FFMUtils.java line 99:

> 97:             .or(Linker.nativeLinker().defaultLookup());
> 98: 
> 99:     public static void traceDowncall(String name, Object... args) {

The tracing downcal support is also something that might be moved directly to the Linker -- either as a Linker option, or as a global flag, similar to `Xcheck:jni` (not in this PR)

src/java.base/share/classes/jdk/internal/ffi/util/FFMUtils.java line 106:

> 104:     }
> 105: 
> 106:     public static MemorySegment findOrThrow(String symbol) {

Hopefully this can go away once we update jextract to a new version that doesn't require this (not in this PR):
https://github.com/openjdk/jextract/pull/280

src/java.base/share/classes/jdk/internal/ffi/util/FFMUtils.java line 118:

> 116:     }
> 117: 
> 118:     public static MemoryLayout align(MemoryLayout layout, long align) {

As observed in the past, this `align` method could probably just be added on `MemoryLayout` (not as part of this PR, this is just a general observation).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2244889620
PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2244899130
PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2244904140
PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2244897270

From mcimadamore at openjdk.org  Thu Jul 31 09:53:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 31 Jul 2025 09:53:58 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use
 FFM APIs
In-Reply-To: <Ff05ao90-5o4GMTnLclSrFfBY8y3WTKWROAccW_Gw1s=.58507938-39d3-46e2-ae9f-e641c87acb57@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
 <Ff05ao90-5o4GMTnLclSrFfBY8y3WTKWROAccW_Gw1s=.58507938-39d3-46e2-ae9f-e641c87acb57@github.com>
Message-ID: <O_8NkCWn3ufZSs51ProN7S6rwiNBqKJ8bgK6gFy28Vo=.6faf6e80-3674-4095-a886-5a69a07aeda7@github.com>

On Thu, 31 Jul 2025 09:45:10 GMT, Maurizio Cimadamore <mcimadamore 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 51:
> 
>> 49:     public static final AddressLayout C_POINTER = ValueLayout.ADDRESS
>> 50:             .withTargetLayout(MemoryLayout.sequenceLayout(Long.MAX_VALUE, JAVA_BYTE));
>> 51:     public static final ValueLayout.OfLong C_LONG = (ValueLayout.OfLong) Linker.nativeLinker().canonicalLayouts().get("long");
> 
> This seems problematic. On Windows, the C type `long` has a `JAVA_INT` layout, because it only uses 32 bits. The reason jextract re-generates all these constants is that they can, in general, vary by platform, so my general feeling is that we can't just have a shared set of layout constants at these level -- the constants will need to be added in the platform-specific directories. If you want to make this layer more portable, then the `C_LONG` constant should be dropped, and clients should use either `C_INT` or `C_LONG_LONG` (which is what most portable C APIs end up doing anyway).
> 
> Another possible way to have a more robust shared layer is to use definitions in stdint.h -- e.g. not `C_INT`, but `C_INT32_T` (but then you might have issues, as the jextract-generated files you are importing depend on names like `C_INT`).

IMHO the more honest approach is to move these constants closer to the _h generated files that use them, as that's the way jextract intends them to be used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2244894284

From coleenp at openjdk.org  Thu Jul 31 11:47:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 31 Jul 2025 11:47:59 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <Kl4A5I4J-FT_bk4sf7CSrn8gYwKFda1I2m22Rud2exs=.27b271f9-c7d4-4c9e-8860-0e6ab5c38b23@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <ZMUB7AU3sYZp_6eERmc8K7rkiaEMi5XGqbF0GKfVgYc=.772ca1c9-e101-4d4d-9c27-22622ca0a584@github.com>
 <5gvsQ413EdL2Lvs-rmusDgTPMiT7lVag5H4fF5Fk4P4=.1416ddb9-6161-419e-8fc2-653e073dd399@github.com>
 <Kl4A5I4J-FT_bk4sf7CSrn8gYwKFda1I2m22Rud2exs=.27b271f9-c7d4-4c9e-8860-0e6ab5c38b23@github.com>
Message-ID: <nPqmtpGaWUvmWPEwRGBAljLM3sFoFDQFA7wXPxmKiLo=.da262ba4-2dff-4fe8-b5d8-4fbb25a3bff1@github.com>

On Wed, 30 Jul 2025 20:25:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> For IDENTITY, I didn't have to inject that one because the Java code knew when to set it, not the JVM code reading the data out of the classfile.  And the logic belongs in the Java code, not the JVM. This one comes from the classfile, there isn't another way to get the information to the java.lang.Class.
>
> The VM and Java use the same logic for the value of isIdentity(). 
> It is computed from as many a 5 fields/flags. At present, it has to be computed on each call to Class.isIdentity().
> It would be reasonable to compute the value once in the constructor, but the code in the constructor is not run.

Roger, can you file another RFE for this for repo-valhalla and I can try to figure out how to best to do this?  Or I can.  I didn't think the valhalla isIdentityClass() code was expensive to call.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2245151689

From mcimadamore at openjdk.org  Thu Jul 31 12:17:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 31 Jul 2025 12:17:57 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use
 FFM APIs
In-Reply-To: <O_8NkCWn3ufZSs51ProN7S6rwiNBqKJ8bgK6gFy28Vo=.6faf6e80-3674-4095-a886-5a69a07aeda7@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
 <Ff05ao90-5o4GMTnLclSrFfBY8y3WTKWROAccW_Gw1s=.58507938-39d3-46e2-ae9f-e641c87acb57@github.com>
 <O_8NkCWn3ufZSs51ProN7S6rwiNBqKJ8bgK6gFy28Vo=.6faf6e80-3674-4095-a886-5a69a07aeda7@github.com>
Message-ID: <g5myrFBNeMK9tEw7IwwXeC1Ut2UblEPY10I1jQgDCpE=.32a118f3-49d7-4793-a279-4981ce72bbf6@github.com>

On Thu, 31 Jul 2025 09:46:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/ffi/util/FFMUtils.java line 51:
>> 
>>> 49:     public static final AddressLayout C_POINTER = ValueLayout.ADDRESS
>>> 50:             .withTargetLayout(MemoryLayout.sequenceLayout(Long.MAX_VALUE, JAVA_BYTE));
>>> 51:     public static final ValueLayout.OfLong C_LONG = (ValueLayout.OfLong) Linker.nativeLinker().canonicalLayouts().get("long");
>> 
>> This seems problematic. On Windows, the C type `long` has a `JAVA_INT` layout, because it only uses 32 bits. The reason jextract re-generates all these constants is that they can, in general, vary by platform, so my general feeling is that we can't just have a shared set of layout constants at these level -- the constants will need to be added in the platform-specific directories. If you want to make this layer more portable, then the `C_LONG` constant should be dropped, and clients should use either `C_INT` or `C_LONG_LONG` (which is what most portable C APIs end up doing anyway).
>> 
>> Another possible way to have a more robust shared layer is to use definitions in stdint.h -- e.g. not `C_INT`, but `C_INT32_T` (but then you might have issues, as the jextract-generated files you are importing depend on names like `C_INT`).
>
> IMHO the more honest approach is to move these constants closer to the _h generated files that use them, as that's the way jextract intends them to be used.

(Also, the latest version of jextract uses `Linker.canonicalLayouts` to derive these constants, which might be more robust longer term)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2245216232

From asotona at openjdk.org  Thu Jul 31 12:22:56 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 31 Jul 2025 12:22:56 GMT
Subject: RFR: 8361638: java.lang.classfile.CodeBuilder.CatchBuilder should
 not throw IllegalArgumentException for representable exception
 handlers [v3]
In-Reply-To: <xYg9aPaPJ8m-VVywcsyvq5Yj6lzPFbyE6NnvArsAPk4=.47e19c03-ee26-45eb-b090-275a3a200248@github.com>
References: <EsgujIABpxOwwcDzA9fsWpfB9YMY0XIzlmJIFwipVXY=.8f40bdea-49b4-468b-83df-b22951a23d41@github.com>
 <xYg9aPaPJ8m-VVywcsyvq5Yj6lzPFbyE6NnvArsAPk4=.47e19c03-ee26-45eb-b090-275a3a200248@github.com>
Message-ID: <MIGA3op2QKu5JzJZn5gXaDIVLShQ2xBxaBYrOxYELjo=.6ee20a01-c640-48d7-b355-ea53763a8f7b@github.com>

On Tue, 29 Jul 2025 17:06:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> CatchBuilder has a simple check for duplicate catch types. However, this check is never comprehensive as it still allows subtypes covered by supertypes, and covering that would be too costly; in addition, the "illegal" duplicate catch types are still valid `class` files. We should remove this duplicate catch type check, and compensate with documentation on the effects of duplicate types.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wrong ref

Looks good to me.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26372#pullrequestreview-3075170838

From jpai at openjdk.org  Thu Jul 31 12:44:04 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 31 Jul 2025 12:44:04 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v16]
In-Reply-To: <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
Message-ID: <yQEkeD2-U6mJaKA2vmTvYxbHk0RTwVKrOwYBJK7VrsU=.41ab750e-cfe7-49dc-b1e0-a1d8dba1ee5f@github.com>

On Wed, 30 Jul 2025 10:39:22 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:
> 
>   Convert non-visible markdown comments to JavaDoc for consistency.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 70:

> 68:  *
> 69:  * <p>While similar to {@code BasicImageReader}, this class is not a conceptual
> 70:  * subtype of, it and deliberately hides types such as {@code ImageLocation} to

Hello David, is the comma here after "of" intentional? It reads a bit odd in the current form.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2245273975

From thartmann at openjdk.org  Thu Jul 31 12:49:56 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 31 Jul 2025 12:49:56 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5]
In-Reply-To: <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
Message-ID: <XjFvCf3zhleAiFz_vuSgthTOsc6Kq3h-nOoaw3R-7O4=.06c7bfdf-3297-4f63-9822-ee4559f2c0cc@github.com>

On Wed, 30 Jul 2025 19:25:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore c2 optimization.

Compiler changes look good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26517#pullrequestreview-3075269461

From epeter at openjdk.org  Thu Jul 31 12:52:59 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 31 Jul 2025 12:52:59 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F
In-Reply-To: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
Message-ID: <8Yc5bUUeWRBGV2XrdVi9uPVfXlMGaZ_fj-H6IjdWO_4=.c3bd36cf-86be-4926-a14d-9046d6bc862d@github.com>

On Thu, 24 Jul 2025 10:29:15 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations.
> 
> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows:
> 
> 
> Benchmark                                (seed)  (size)   Mode  Cnt      Base      Patch   Units   Diff
> VectorBitConversion.doubleToLongBits          0    2048  thrpt    8  1168.782   1157.717  ops/ms    -1%
> VectorBitConversion.doubleToRawLongBits       0    2048  thrpt    8  3999.387   7353.936  ops/ms   +83%
> VectorBitConversion.floatToIntBits            0    2048  thrpt    8  1200.338   1188.206  ops/ms    -1%
> VectorBitConversion.floatToRawIntBits         0    2048  thrpt    8  4058.248  14792.474  ops/ms  +264%
> VectorBitConversion.intBitsToFloat            0    2048  thrpt    8  3050.313  14984.246  ops/ms  +391%
> VectorBitConversion.longBitsToDouble          0    2048  thrpt    8  3022.691   7379.360  ops/ms  +144%
> 
> 
> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control.
> 
> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions.

Thanks for working on this, it looks really good :)

I'll need to do some testing later though.

test/micro/org/openjdk/bench/java/lang/VectorBitConversion.java line 1:

> 1: package org.openjdk.bench.java.lang;

I think this benchmark belongs with the other vectorization benchmarks under
`test/micro/org/openjdk/bench/vm/compiler/Vector*`

-------------

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26457#pullrequestreview-3075276901
PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2245295082

From epeter at openjdk.org  Thu Jul 31 12:53:00 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 31 Jul 2025 12:53:00 GMT
Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F
In-Reply-To: <8Yc5bUUeWRBGV2XrdVi9uPVfXlMGaZ_fj-H6IjdWO_4=.c3bd36cf-86be-4926-a14d-9046d6bc862d@github.com>
References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com>
 <8Yc5bUUeWRBGV2XrdVi9uPVfXlMGaZ_fj-H6IjdWO_4=.c3bd36cf-86be-4926-a14d-9046d6bc862d@github.com>
Message-ID: <0by7e3QZ36BPsVlRJMxdgHKX-IbsbumQrFg-iBaSZBY=.ddfa469e-8718-4c62-aaaf-766c5d7f6473@github.com>

On Thu, 31 Jul 2025 12:49:16 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations.
>> 
>> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows:
>> 
>> 
>> Benchmark                                (seed)  (size)   Mode  Cnt      Base      Patch   Units   Diff
>> VectorBitConversion.doubleToLongBits          0    2048  thrpt    8  1168.782   1157.717  ops/ms    -1%
>> VectorBitConversion.doubleToRawLongBits       0    2048  thrpt    8  3999.387   7353.936  ops/ms   +83%
>> VectorBitConversion.floatToIntBits            0    2048  thrpt    8  1200.338   1188.206  ops/ms    -1%
>> VectorBitConversion.floatToRawIntBits         0    2048  thrpt    8  4058.248  14792.474  ops/ms  +264%
>> VectorBitConversion.intBitsToFloat            0    2048  thrpt    8  3050.313  14984.246  ops/ms  +391%
>> VectorBitConversion.longBitsToDouble          0    2048  thrpt    8  3022.691   7379.360  ops/ms  +144%
>> 
>> 
>> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control.
>> 
>> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions.
>
> test/micro/org/openjdk/bench/java/lang/VectorBitConversion.java line 1:
> 
>> 1: package org.openjdk.bench.java.lang;
> 
> I think this benchmark belongs with the other vectorization benchmarks under
> `test/micro/org/openjdk/bench/vm/compiler/Vector*`

It's not really a language feature, more for vm/compiler

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2245296534

From jpai at openjdk.org  Thu Jul 31 12:54:04 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 31 Jul 2025 12:54:04 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v16]
In-Reply-To: <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
Message-ID: <hHYZ1I88slhXjmwsSJQeQlP_naxUk2yGHrepyzOmDhQ=.c93b9706-3745-4793-9490-27fc7f92f1d1@github.com>

On Wed, 30 Jul 2025 10:39:22 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:
> 
>   Convert non-visible markdown comments to JavaDoc for consistency.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 172:

> 170:         requireOpen();
> 171:         if (!node.isResource()) {
> 172:             throw new IllegalStateException("Not a resource node: " + node);

Should this "public ByteBuffer getResourceBuffer(Node node)" throw `IllegalArgumentException` instead of `IllegalStateException` if the passed `node` isn't a resource node?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2245298436

From mdonovan at openjdk.org  Thu Jul 31 12:58:21 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 31 Jul 2025 12:58:21 GMT
Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show
 enabled TLS groups and signature algorithms [v2]
In-Reply-To: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
Message-ID: <fk9s1qutYkqMhVFglPOdbPBtugBO5V1-rz_R5OWsNqw=.78ee1089-ca57-48a3-8827-6db0145e6250@github.com>

> 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.

Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - removed unused import, updated tools/launcher/Settings.java test
 - Merge branch 'master' into secsettings
 - 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24424/files
  - new: https://git.openjdk.org/jdk/pull/24424/files/2e8aee5f..b695a812

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24424&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24424&range=00-01

  Stats: 573270 lines in 7287 files changed: 254953 ins; 271904 del; 46413 mod
  Patch: https://git.openjdk.org/jdk/pull/24424.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24424/head:pull/24424

PR: https://git.openjdk.org/jdk/pull/24424

From jpai at openjdk.org  Thu Jul 31 12:59:03 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 31 Jul 2025 12:59:03 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v16]
In-Reply-To: <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
Message-ID: <-Gv1xfEfIQDSvxUygAS1M093O4MFXTqnFoo2OwJyK-8=.08e51cc2-bea1-41b0-a420-00510e2e92cb@github.com>

On Wed, 30 Jul 2025 10:39:22 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:
> 
>   Convert non-visible markdown comments to JavaDoc for consistency.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 195:

> 193: 
> 194:         // Cache of all user visible nodes, guarded by synchronizing 'this' instance.
> 195:         private final HashMap<String, Node> nodes;

Pre-existing, but since we are cleaning up some of this code, perhaps we can make this declaration a `Map` instead of a `HashMap`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2245312721

From jpai at openjdk.org  Thu Jul 31 13:03:06 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 31 Jul 2025 13:03:06 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v16]
In-Reply-To: <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
Message-ID: <aXecPyepqfd4Xml5uIFdKy5g4oyO6VCvV5556H9yNpc=.184fc18e-d774-45be-b2ad-2bd950c4c1e0@github.com>

On Wed, 30 Jul 2025 10:39:22 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:
> 
>   Convert non-visible markdown comments to JavaDoc for consistency.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 203:

> 201:             super(imagePath, byteOrder);
> 202:             this.imageFileAttributes = Files.readAttributes(imagePath, BasicFileAttributes.class);
> 203:             this.nodes = new HashMap<>(INITIAL_NODE_CACHE_CAPACITY);

The comment above the `INITIAL_NODE_CACHE_CAPACITY` suggests that we are talking about the number of `nodes` that this map would typically hold - ie. the number of entries in the map. If that's the case, then it would be better to use the newly introduced (in Java 19) `HashMap.newHashMap(int numMappings)` method here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2245325121

From rgiulietti at openjdk.org  Thu Jul 31 13:05:08 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 31 Jul 2025 13:05:08 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <NAgYZ-UqgcNwUTjo7AKhIE-sb6omORrqalQYxMQgefc=.46e0e0b3-01af-49c4-b948-44fdcb7ff937@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <NAgYZ-UqgcNwUTjo7AKhIE-sb6omORrqalQYxMQgefc=.46e0e0b3-01af-49c4-b948-44fdcb7ff937@github.com>
Message-ID: <si0NS3yWvy6bVHXcWJofgjrk7fUoHGg_DQ0U-7Iy3Yo=.c84b0680-a1c5-4465-8d81-d513735851fe@github.com>

On Mon, 14 Jul 2025 16:52:31 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed useless instruction
>
> The integers are closed under positive powers, and not under positive nthRoots, this is true. However, the problem remains, as if the root degree `n` is negative, then for radicands that are not 1, -1 or 0 we should return 0, and zero raised to a negative exponent is undefined in real numbers, and so the remainder is.

@fabioromano1 Let me know when your changes settle down and the code is ready for another review round. I'd prefer to aim at a fixed rather than a quickly moving target ;-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3139894107

From duke at openjdk.org  Thu Jul 31 13:16:01 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 31 Jul 2025 13:16:01 GMT
Subject: RFR: 8077587: BigInteger Roots [v61]
In-Reply-To: <XLAo4JQw8iftv_K0tctm0JMdZDACeW_-13kZkiA3ciE=.7b40d8cf-117b-4b42-9fcd-dcd7adb82bb5@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <WpqJmiAhF8P0g0hvuKmcdX-Q__IkDyNSII0gYEqlLZY=.e510826b-a17c-49e4-b593-8c1e6aeb226e@github.com>
 <XLAo4JQw8iftv_K0tctm0JMdZDACeW_-13kZkiA3ciE=.7b40d8cf-117b-4b42-9fcd-dcd7adb82bb5@github.com>
Message-ID: <ETpEQmyLAhbEO60ExOcZNBXio4XMbbhT2CjJ7Ft-oxk=.6445f4c3-dccd-4df3-9ba6-f610a489d8b9@github.com>

On Wed, 30 Jul 2025 10:30:15 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update javadoc
>
> src/java.base/share/classes/java/math/MutableBigInteger.java line 1921:
> 
>> 1919:      * The contents of {@code this} are <em>not</em> changed. The value of {@code this}
>> 1920:      * is assumed to be non-negative and the root degree {@code n >= 3}.
>> 1921:      * Assumes {@code bitLength() <= Integer.MAX_VALUE}.
> 
> @rgiulietti This assumption could be dropped, if the shift methods of `MutableBigInteger` would accept `long` shift values too.

@rgiulietti Could make sense to enhance `MBI.leftShift(int)` and  `MBI.rightShift(int)` to `MBI.leftShift(long)` and  `MBI.rightShift(long)`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2245366998

From rgiulietti at openjdk.org  Thu Jul 31 13:35:02 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 31 Jul 2025 13:35:02 GMT
Subject: RFR: 8077587: BigInteger Roots [v61]
In-Reply-To: <ETpEQmyLAhbEO60ExOcZNBXio4XMbbhT2CjJ7Ft-oxk=.6445f4c3-dccd-4df3-9ba6-f610a489d8b9@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <WpqJmiAhF8P0g0hvuKmcdX-Q__IkDyNSII0gYEqlLZY=.e510826b-a17c-49e4-b593-8c1e6aeb226e@github.com>
 <XLAo4JQw8iftv_K0tctm0JMdZDACeW_-13kZkiA3ciE=.7b40d8cf-117b-4b42-9fcd-dcd7adb82bb5@github.com>
 <ETpEQmyLAhbEO60ExOcZNBXio4XMbbhT2CjJ7Ft-oxk=.6445f4c3-dccd-4df3-9ba6-f610a489d8b9@github.com>
Message-ID: <eER9xawZWg03umAgiMEobH8Tt_6cZOg3xG94ZtojDBg=.f25eb2d7-63d8-44cd-a73c-bf29eef32c08@github.com>

On Thu, 31 Jul 2025 13:13:39 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1921:
>> 
>>> 1919:      * The contents of {@code this} are <em>not</em> changed. The value of {@code this}
>>> 1920:      * is assumed to be non-negative and the root degree {@code n >= 3}.
>>> 1921:      * Assumes {@code bitLength() <= Integer.MAX_VALUE}.
>> 
>> @rgiulietti This assumption could be dropped, if the shift methods of `MutableBigInteger` would accept `long` shift values too.
>
> @rgiulietti Could make sense to enhance `MBI.leftShift(int)` and  `MBI.rightShift(int)` to `MBI.leftShift(long)` and  `MBI.rightShift(long)`?

I think there are currently no use cases indirectly needing this by the publicly facing APIs. These are `nthRoot()` in `BigInteger` and, in the future, in `BigDecimal`: both assume a maximal bit length around 2^31, if I'm not mistaken.

The assumption in `MBI.nthRootRem()` is quite safe, as the only (current) usage is from `BI`.
We usually don't validate too much in internal classes (except when there are risks that could undermine the platform integrity), and assume they are used correctly and documented accordingly.
But if you feel uncomfortable, then I suggest to validate the input of `MBI.nthRootRem()` at method entry (maybe including the other assumptions). These checks are quite inexpensive compared to the rest of the computation.

Anyway, enhancing `MBI.[left|right]Shift(int)` would be better done in a separate PR, but only if there's some really compelling need.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2245415234

From duke at openjdk.org  Thu Jul 31 13:43:04 2025
From: duke at openjdk.org (fabioromano1)
Date: Thu, 31 Jul 2025 13:43:04 GMT
Subject: RFR: 8077587: BigInteger Roots [v23]
In-Reply-To: <si0NS3yWvy6bVHXcWJofgjrk7fUoHGg_DQ0U-7Iy3Yo=.c84b0680-a1c5-4465-8d81-d513735851fe@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <-kwoJNpaYu0MzUv7ntf9mv4GFJmZh5KLdBKyMcwmTbQ=.a2cae00b-8cad-490f-a68d-c7d6f46ed628@github.com>
 <NAgYZ-UqgcNwUTjo7AKhIE-sb6omORrqalQYxMQgefc=.46e0e0b3-01af-49c4-b948-44fdcb7ff937@github.com>
 <si0NS3yWvy6bVHXcWJofgjrk7fUoHGg_DQ0U-7Iy3Yo=.c84b0680-a1c5-4465-8d81-d513735851fe@github.com>
Message-ID: <PQ_ipNuDUImBQ4j7rd0IMAnRUHZE96zNaavQzYOIM38=.c6daa27c-fe01-4459-a367-5f4616ae900f@github.com>

On Thu, 31 Jul 2025 13:02:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> The integers are closed under positive powers, and not under positive nthRoots, this is true. However, the problem remains, as if the root degree `n` is negative, then for radicands that are not 1, -1 or 0 we should return 0, and zero raised to a negative exponent is undefined in real numbers, and so the remainder is.
>
> @fabioromano1 Let me know when your changes settle down and the code is ready for another review round. I'd prefer to aim at a fixed rather than a quickly moving target ;-)

@rgiulietti I think I'm not going to do other changes for now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3140021363

From jpai at openjdk.org  Thu Jul 31 13:45:11 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 31 Jul 2025 13:45:11 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v16]
In-Reply-To: <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
Message-ID: <ozQQw711FChfevZp5IRUYKc1n1yAV6CQAtymTxhfDf4=.fcf26d23-139d-43f1-b20c-c7b69760242f@github.com>

On Wed, 30 Jul 2025 10:39:22 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:
> 
>   Convert non-visible markdown comments to JavaDoc for consistency.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 189:

> 187:         private final Set<ImageReader> openers = new HashSet<>();
> 188: 
> 189:         // Attributes of the .jimage file. The jimage file does not contain

Nit - (pre-existing) calling it a `.jimage` file makes it look like `jimage` is a (well known) extension for jimage files. As far as I know, it isn't (the default jimage file that we ship in the JDK is just named `modules`). Perhaps we should change this to "Attributes of the jimage file."?

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 283:

> 281:          *
> 282:          * <p>Note also that there is no reentrant calling back to this method from within
> 283:          * the node handling code.

This paragraph and the previous one feels like too much detail and I'm not sure they are necessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2245335120
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2245442999

From alanb at openjdk.org  Thu Jul 31 13:45:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Jul 2025 13:45:13 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v16]
In-Reply-To: <aXecPyepqfd4Xml5uIFdKy5g4oyO6VCvV5556H9yNpc=.184fc18e-d774-45be-b2ad-2bd950c4c1e0@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
 <aXecPyepqfd4Xml5uIFdKy5g4oyO6VCvV5556H9yNpc=.184fc18e-d774-45be-b2ad-2bd950c4c1e0@github.com>
Message-ID: <_xPn6xfqMlqwWGeGvLZNn2TcJqXqdbYUg6cUN9rPT7E=.865533c4-ded1-4a16-95ef-8975c1da3a5a@github.com>

On Thu, 31 Jul 2025 13:00:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Convert non-visible markdown comments to JavaDoc for consistency.
>
> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 203:
> 
>> 201:             super(imagePath, byteOrder);
>> 202:             this.imageFileAttributes = Files.readAttributes(imagePath, BasicFileAttributes.class);
>> 203:             this.nodes = new HashMap<>(INITIAL_NODE_CACHE_CAPACITY);
> 
> The comment above the `INITIAL_NODE_CACHE_CAPACITY` suggests that we are talking about the number of `nodes` that this map would typically hold - ie. the number of entries in the map. If that's the case, then it would be better to use the newly introduced (in Java 19) `HashMap.newHashMap(int numMappings)` method here.

The jimage code is still compiled --release 8 to allow jrt-fs.jar to loaded by IDEs/tools that run on older JDK releases but target other releases. But yes, a reminder that the initial capability parameter doesn't do exactly what people expect.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2245333819

From rgiulietti at openjdk.org  Thu Jul 31 13:48:05 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 31 Jul 2025 13:48:05 GMT
Subject: RFR: 8077587: BigInteger Roots [v65]
In-Reply-To: <p9czGdddIQSzTEdkkzSXuCfUkR36LTK5rB1SRif2quY=.797e82f7-c702-4856-9b34-faf18a2e34a5@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <p9czGdddIQSzTEdkkzSXuCfUkR36LTK5rB1SRif2quY=.797e82f7-c702-4856-9b34-faf18a2e34a5@github.com>
Message-ID: <MSrTQuJhfm4WC1ZCmVHaIBYuCGavgawlAwE3O_t_098=.10b75942-f7ae-4d08-9410-b1345d0b9906@github.com>

On Thu, 31 Jul 2025 08:40:40 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This PR implements nth root computation for BigIntegers using Newton method.
>
> fabioromano1 has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 111 commits:
> 
>  - Merge branch 'openjdk:master' into nth-root-branch
>  - Update MutableBigInteger.java
>  - Useless instruction
>  - Optimization for large degree values
>  - Optimization for large degree's values
>  - Update javadoc
>  - Refine comments
>  - Refine the comment
>  - Comment
>  - More comments
>  - ... and 101 more: https://git.openjdk.org/jdk/compare/b9f7caed...dbf7b522

I'll come back to this PR starting around Wednesday next week. In the meantime, you have free reign.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3140038700

From jpai at openjdk.org  Thu Jul 31 13:52:06 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 31 Jul 2025 13:52:06 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v16]
In-Reply-To: <_xPn6xfqMlqwWGeGvLZNn2TcJqXqdbYUg6cUN9rPT7E=.865533c4-ded1-4a16-95ef-8975c1da3a5a@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
 <aXecPyepqfd4Xml5uIFdKy5g4oyO6VCvV5556H9yNpc=.184fc18e-d774-45be-b2ad-2bd950c4c1e0@github.com>
 <_xPn6xfqMlqwWGeGvLZNn2TcJqXqdbYUg6cUN9rPT7E=.865533c4-ded1-4a16-95ef-8975c1da3a5a@github.com>
Message-ID: <iDxM4msV6LuJQKCmUOs8jPpKlOe54bQ2vLvKBbAkIYE=.b6b81f9b-bb46-4203-84f0-3d4543401c52@github.com>

On Thu, 31 Jul 2025 13:03:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The jimage code is still compiled --release 8

Good point, Alan. I keep forgetting that, even when it's noted in the very file that I commented on.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2245460912

From jpai at openjdk.org  Thu Jul 31 14:02:03 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 31 Jul 2025 14:02:03 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v15]
In-Reply-To: <rKnKLZeDI3kGz7YPIfNBsZmtMKt4EgmyiuYsFcSFUWM=.8c2760c2-0785-4dad-b002-563c73d7f6cf@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <tF6q4wlxpAnHevpHtKkRK_slLbUSI7f4mvUZUnrEv9o=.362472f5-a976-4a2a-9412-c0c444c7287b@github.com>
 <rnTrM1C_f2-DgXtPaInMsZkdJoQYcH9IsXQUD5twyAE=.b66d6278-c4fc-4675-860b-786c6f8003f8@github.com>
 <rKnKLZeDI3kGz7YPIfNBsZmtMKt4EgmyiuYsFcSFUWM=.8c2760c2-0785-4dad-b002-563c73d7f6cf@github.com>
Message-ID: <PeFJ7ADhkpVqSWbybg5K8pu-Lvv4LJNgOr1e-VzcARc=.5b836d65-b2b0-411b-b660-ab7b9f4d1f23@github.com>

On Tue, 29 Jul 2025 17:56:00 GMT, David Beaumont <duke at openjdk.org> wrote:

>> test/jdk/jdk/internal/jimage/JImageReadTest.java line 350:
>> 
>>> 348:         try (ImageReader badReader = ImageReader.open(imageFile, otherOrder)) {
>>> 349:             Assert.fail("Reader should not be openable with the wrong byte order.");
>>> 350:         } catch (IOException expected) {
>> 
>> In passing, you can use `assertThrows(IOException.class(), () -> ImageReader.open(..))` here if you want.
>
> I don't think I can, can I? That method takes a Runnable, not some sort of Callable that throws E.

The construct that Alan suggested works fine here. The fact that ImageReader.open() returns some value shouldn't matter here. I gave this a try locally and the use of `assertThrows(...)` with `ImageReader.open(...)` works as expected.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2245485105

From jpai at openjdk.org  Thu Jul 31 14:15:06 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 31 Jul 2025 14:15:06 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support [v16]
In-Reply-To: <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <RYlc1B5cgAj6GKMifPRgAxlDIIO_ZR5zrnjoM6FPMbM=.ae362b54-4e32-4855-b3d5-a948337e32a1@github.com>
Message-ID: <K8Jqam-PK2L1o7hbkYNy3R15y33Twj289mobkfwMMkI=.02a1aa69-9fb4-4065-b5aa-4789dce8587c@github.com>

On Wed, 30 Jul 2025 10:39:22 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:
> 
>   Convert non-visible markdown comments to JavaDoc for consistency.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 316:

> 314:          * is not present in the cache.
> 315:          */
> 316:         Node buildModulesNode(String name) {

Should this be `private` method?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2245520316

From duke at openjdk.org  Thu Jul 31 15:02:57 2025
From: duke at openjdk.org (duke)
Date: Thu, 31 Jul 2025 15:02:57 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v6]
In-Reply-To: <JdxWpCBHtTssvz1lu08gRSrJr3So7vxoi5hiopLlxLo=.3931a767-c13c-455a-b631-616cbbd250ff@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <JdxWpCBHtTssvz1lu08gRSrJr3So7vxoi5hiopLlxLo=.3931a767-c13c-455a-b631-616cbbd250ff@github.com>
Message-ID: <LEacc0c1VJxZL6yh56jCydBBVKf8CIIvtj0362Lzb1U=.57beedc9-6cb8-4e6d-bb06-8d10bfe53395@github.com>

On Mon, 16 Jun 2025 21:19:45 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>> 
>> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
>> 
>> Testing:
>> - GHA
>> - Local run of tier 2 and jtreg:jdk/java/text
>> - New benchmark: DecimalFormatParseBench
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

@j3graham 
Your change (at version b7faa3b86c320aa979da5003002575011e278081) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25644#issuecomment-3140312350

From rriggs at openjdk.org  Thu Jul 31 15:20:59 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 31 Jul 2025 15:20:59 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5]
In-Reply-To: <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
Message-ID: <J4_n5YAZDvWgk118g06cLxZ4Cv-fQaIwdwgJznOlosg=.65adcafe-4595-4ca2-b400-8ee9400d21c7@github.com>

On Wed, 30 Jul 2025 19:25:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore c2 optimization.

Looks good, thanks

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26517#pullrequestreview-3075875144

From rriggs at openjdk.org  Thu Jul 31 15:21:00 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 31 Jul 2025 15:21:00 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v2]
In-Reply-To: <nPqmtpGaWUvmWPEwRGBAljLM3sFoFDQFA7wXPxmKiLo=.da262ba4-2dff-4fe8-b5d8-4fbb25a3bff1@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <cSuqsO8-9lnuCyMfQibpw3RxDV_DePZWJNMUQwGIMaY=.5d3a1b8e-4bb1-4677-a073-28d0b011eb63@github.com>
 <5rPWGuXUbiRbQ7TlwHJnQDjRYSuWRITbbo0OUtMfhrY=.cfe52d81-3450-477f-b5d8-02b3590971d0@github.com>
 <ZMUB7AU3sYZp_6eERmc8K7rkiaEMi5XGqbF0GKfVgYc=.772ca1c9-e101-4d4d-9c27-22622ca0a584@github.com>
 <5gvsQ413EdL2Lvs-rmusDgTPMiT7lVag5H4fF5Fk4P4=.1416ddb9-6161-419e-8fc2-653e073dd399@github.com>
 <Kl4A5I4J-FT_bk4sf7CSrn8gYwKFda1I2m22Rud2exs=.27b271f9-c7d4-4c9e-8860-0e6ab5c38b23@github.com>
 <nPqmtpGaWUvmWPEwRGBAljLM3sFoFDQFA7wXPxmKiLo=.da262ba4-2dff-4fe8-b5d8-4fbb25a3bff1@github.com>
Message-ID: <LF1Zpw4ZBjW7WqKhol_OOCweJHs1aTL2527DVLDbGx4=.75c9d2a1-d5ea-46e3-8ca4-c4b3b888d322@github.com>

On Thu, 31 Jul 2025 11:45:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The VM and Java use the same logic for the value of isIdentity(). 
>> It is computed from as many a 5 fields/flags. At present, it has to be computed on each call to Class.isIdentity().
>> It would be reasonable to compute the value once in the constructor, but the code in the constructor is not run.
>
> Roger, can you file another RFE for this for repo-valhalla and I can try to figure out how to best to do this?  Or I can.  I didn't think the valhalla isIdentityClass() code was expensive to call.

Created [JDK-8364447](https://bugs.openjdk.org/browse/JDK-8364447)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26517#discussion_r2245695722

From liach at openjdk.org  Thu Jul 31 17:21:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 31 Jul 2025 17:21:52 GMT
Subject: RFR: 8364317: Explicitly document some assumptions of StringUTF16
 [v2]
In-Reply-To: <PJ5zCV7cZtpQBOtW4pzc9yaJaxwTJblpT3kihl7m3rw=.ec2f3d89-2cb3-4da7-952a-bc8965ed50a1@github.com>
References: <vTct6VRmglYJEqYaS3A4oeMBvXEYDRXGtJ_iD1YC2lM=.efc00627-2856-4c45-8dcf-55b1a9907680@github.com>
 <Mw4qgm9pMKYpC4OEmkrDkX93AX_9DxZkQ0UKrJ6TJKo=.adf38d97-7442-4c93-8f2d-482eb97fabf0@github.com>
 <PJ5zCV7cZtpQBOtW4pzc9yaJaxwTJblpT3kihl7m3rw=.ec2f3d89-2cb3-4da7-952a-bc8965ed50a1@github.com>
Message-ID: <Ri9SesOhrDIHJkxF_79VlI787G5a9kMreVt8Jw5sHHY=.70fbb67b-c1c5-445b-9c4f-49c56ae2ec3d@github.com>

On Wed, 30 Jul 2025 14:15:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A good initiative, thanks @liach.
>> Maybe some words about endianness would be useful as well.
>
> @rgiulietti: I have added a paragraph describing the layout constraints of UTF16 byte arrays. Please check it out.

> @liach, given the relatively big API surface of j.l.StringUTF16, are we certain about this?

I am. In fact, your update to use `char` made it less correct - there are a few APIs that take LATIN1 byte arrays, for which number of chars is equivalent to number of bytes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26541#issuecomment-3140762852

From liach at openjdk.org  Thu Jul 31 17:21:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 31 Jul 2025 17:21:54 GMT
Subject: RFR: 8364317: Explicitly document some assumptions of StringUTF16
 [v2]
In-Reply-To: <hnKNOiXnVxlGplBmRIaptRMuPVMc_gXh_vX3SV3Mz8E=.236d73c8-6aa8-4c3c-b456-1b27f66ae5a7@github.com>
References: <vTct6VRmglYJEqYaS3A4oeMBvXEYDRXGtJ_iD1YC2lM=.efc00627-2856-4c45-8dcf-55b1a9907680@github.com>
 <GgfVca9RnmKpTO201qkiJmRZ5w-5PcD9e6DDSLH5juI=.4ce8e98d-6f1b-4768-9f7d-318b3848985e@github.com>
 <hnKNOiXnVxlGplBmRIaptRMuPVMc_gXh_vX3SV3Mz8E=.236d73c8-6aa8-4c3c-b456-1b27f66ae5a7@github.com>
Message-ID: <5-rn3_J4tsvTJjZSr3SJUF2ZBI9X2xTI54tGn_uv5xM=.0ec3ee63-f4a6-42da-9852-ca3c890a4028@github.com>

On Wed, 30 Jul 2025 18:12:03 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add paragraph for endianness and layout
>
> src/java.base/share/classes/java/lang/StringUTF16.java line 51:
> 
>> 49: ///
>> 50: /// All indices and sizes for byte arrays carrying UTF16 data are in number of
>> 51: /// chars instead of  number of bytes.
> 
> Nit on cosmetics:
> 
> Suggestion:
> 
> /// UTF-16 `String` operations.
> ///
> /// UTF-16 byte arrays have the identical layout as `char` arrays. They share the
> /// same base offset and scale, and for each two-byte unit interpreted as a `char`,
> /// it has the same endianness as a `char`, which is the platform endianness.
> /// This is ensured in the static initializer of [StringUTF16].
> ///
> /// All indices and sizes for byte arrays carrying UTF-16 data are in number of
> /// `char`s instead of number of bytes.

Unforutnately I don't think I will use your suggestion maybe besides that whitespace fix.

1. UTF16 is derived from the `String.UTF16`, so I don't think I will stylize that.
2. The number of chars is the number of characters. I double checked and seems `length` is the only one that returns the byte array length instead of using character count as unit. There are some LATIN1 accepting APIs, and those APIs also use number of characters, except in LATIN1 case the number is identical to the number of chars.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26541#discussion_r2245962980

From liach at openjdk.org  Thu Jul 31 17:35:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 31 Jul 2025 17:35:57 GMT
Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v4]
In-Reply-To: <GYn-_oE8pt748YCLrumWctK97Yxjru2FXHlSc2CO7xQ=.6c329f3d-e76e-4d23-a407-c6a9916e54ef@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <ry3bOAIy2G3MTSidAx9GU7rllzdPjR8a9Dl4xuimirM=.bf9a1c65-b2ff-4c21-b4c0-c77ef49d7cb3@github.com>
 <GYn-_oE8pt748YCLrumWctK97Yxjru2FXHlSc2CO7xQ=.6c329f3d-e76e-4d23-a407-c6a9916e54ef@github.com>
Message-ID: <PDTWwmH8GG70cNmgcOqAxwu3MA_dWmfGga747FuNl7M=.d16cf5f6-7148-431f-bc02-939385f9b4b1@github.com>

On Wed, 30 Jul 2025 17:32:57 GMT, John R Rose <jrose 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/hotspot/share/prims/unsafe.cpp line 496:
> 
>> 494:     Symbol *name = fs.name();
>> 495:     if (name->equals(utf_name)) {
>> 496:       offset = fs.offset();
> 
> While you are here, if you keep this check, rename this particular function `find_field_offset` to `find_nonstatic_field_offset` (not the other one that takes the "must be static" flag).
> 
> The logic, as written, is difficult to understand because of the behavioral difference between the two overloading.
> 
> (I note that "instance field" is also a term of art in our code base, but "nonstatic_field" is more common.)
> 
> Alternatively, and probably better, take out this particular check (restoring equal access to static and non-static) and just rely on the checks in Java code.  Such checks are almost always better (easier to reason about by humans and JITs) than checks in C++ code.

This particular method intentionally avoids accessing Java reflective objects to reduce startup overhead. I think a better approach may be returning error code and have Java code report a failure. Thoughts?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2245996580

From vyazici at openjdk.org  Thu Jul 31 17:46:54 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 31 Jul 2025 17:46:54 GMT
Subject: RFR: 8364317: Explicitly document some assumptions of StringUTF16
 [v2]
In-Reply-To: <GgfVca9RnmKpTO201qkiJmRZ5w-5PcD9e6DDSLH5juI=.4ce8e98d-6f1b-4768-9f7d-318b3848985e@github.com>
References: <vTct6VRmglYJEqYaS3A4oeMBvXEYDRXGtJ_iD1YC2lM=.efc00627-2856-4c45-8dcf-55b1a9907680@github.com>
 <GgfVca9RnmKpTO201qkiJmRZ5w-5PcD9e6DDSLH5juI=.4ce8e98d-6f1b-4768-9f7d-318b3848985e@github.com>
Message-ID: <Xe1Y42TQ15qrHN_HDSf8NG3TfR92RuWgiOUQ7EwxEG0=.69ceb8b8-f8d6-4295-85b6-7e528894ab23@github.com>

On Wed, 30 Jul 2025 14:18:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In #24773, people were concerned that the layout of a UTF16 byte array and a char array may be incompatible. In fact, they are - they are asserted in a corner in `LibraryCallKit::inline_string_char_access` in `library_call.cpp`.
>> 
>> In addition, another frequent error I see is that contributors have confused the meaning of indices in StringUTF16 - the indices are always in char array indices. I think we should make these explicit to help future maintenance.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add paragraph for endianness and layout

> > @liach, given the relatively big API surface of j.l.StringUTF16, are we certain about this?
> 
> I am. In fact, your update to use `char` made it less correct - there are a few APIs that take LATIN1 byte arrays, for which number of chars is equivalent to number of bytes.

Thanks for taking care of these details Chen, much appreciated. Changes LGTM.

-------------

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26541#pullrequestreview-3076373698

From duke at openjdk.org  Thu Jul 31 17:53:04 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 31 Jul 2025 17:53:04 GMT
Subject: Integrated: 8358880: Performance of parsing with DecimalFormat can be
 improved
In-Reply-To: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
Message-ID: <KrwkgOLNp9WlD98iRxa2GegKJhmaKFJxoik9nEZwpMA=.555d3893-fd59-4b8d-9e09-6122e40d1284@github.com>

On Wed, 4 Jun 2025 18:18:39 GMT, Johannes Graham <duke at openjdk.org> wrote:

> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
> 
> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
> 
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench

This pull request has now been integrated.

Changeset: d1944239
Author:    Johannes Graham <j3graham at gmail.com>
Committer: Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d19442399c004c78bff8a5ccf7c6975c7e583a07
Stats:     184 lines in 4 files changed: 126 ins; 48 del; 10 mod

8358880: Performance of parsing with DecimalFormat can be improved

Reviewed-by: jlu, liach, rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/25644

From duke at openjdk.org  Thu Jul 31 18:18:04 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 31 Jul 2025 18:18:04 GMT
Subject: RFR: 8358880: Performance of parsing with DecimalFormat can be
 improved [v6]
In-Reply-To: <JdxWpCBHtTssvz1lu08gRSrJr3So7vxoi5hiopLlxLo=.3931a767-c13c-455a-b631-616cbbd250ff@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <JdxWpCBHtTssvz1lu08gRSrJr3So7vxoi5hiopLlxLo=.3931a767-c13c-455a-b631-616cbbd250ff@github.com>
Message-ID: <qEcBXnYfV7wxGMZ2iXwdl7ILU39yoIfD9ltxq4hHQ_c=.2f998277-5810-4dbe-b6cf-fc8e1fb96794@github.com>

On Mon, 16 Jun 2025 21:19:45 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>> 
>> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
>> 
>> Testing:
>> - GHA
>> - Local run of tier 2 and jtreg:jdk/java/text
>> - New benchmark: DecimalFormatParseBench
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

Thank you all for your attention.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25644#issuecomment-3140917372

From liach at openjdk.org  Thu Jul 31 18:28:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 31 Jul 2025 18:28:58 GMT
Subject: RFR: 8364317: Explicitly document some assumptions of StringUTF16
 [v2]
In-Reply-To: <GgfVca9RnmKpTO201qkiJmRZ5w-5PcD9e6DDSLH5juI=.4ce8e98d-6f1b-4768-9f7d-318b3848985e@github.com>
References: <vTct6VRmglYJEqYaS3A4oeMBvXEYDRXGtJ_iD1YC2lM=.efc00627-2856-4c45-8dcf-55b1a9907680@github.com>
 <GgfVca9RnmKpTO201qkiJmRZ5w-5PcD9e6DDSLH5juI=.4ce8e98d-6f1b-4768-9f7d-318b3848985e@github.com>
Message-ID: <q293CL9RKoAk_PUIomRLG-S5-Noi24vDOzYDP8i-rNE=.459ef579-4744-47f9-ae8b-485d57d5c142@github.com>

On Wed, 30 Jul 2025 14:18:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In #24773, people were concerned that the layout of a UTF16 byte array and a char array may be incompatible. In fact, they are - they are asserted in a corner in `LibraryCallKit::inline_string_char_access` in `library_call.cpp`.
>> 
>> In addition, another frequent error I see is that contributors have confused the meaning of indices in StringUTF16 - the indices are always in char array indices. I think we should make these explicit to help future maintenance.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add paragraph for endianness and layout

Thanks for the reviews! I hope a random future commit might pick up that extra space as a gratituity.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26541#issuecomment-3140943060

From liach at openjdk.org  Thu Jul 31 18:28:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 31 Jul 2025 18:28:59 GMT
Subject: Integrated: 8364317: Explicitly document some assumptions of
 StringUTF16
In-Reply-To: <vTct6VRmglYJEqYaS3A4oeMBvXEYDRXGtJ_iD1YC2lM=.efc00627-2856-4c45-8dcf-55b1a9907680@github.com>
References: <vTct6VRmglYJEqYaS3A4oeMBvXEYDRXGtJ_iD1YC2lM=.efc00627-2856-4c45-8dcf-55b1a9907680@github.com>
Message-ID: <xzOMq3Ij258aHc4cJa5tFOoJsWc4y0Cqmft1vKUy5io=.cb878d61-27cb-4e81-ab43-c460ee96424b@github.com>

On Tue, 29 Jul 2025 21:09:59 GMT, Chen Liang <liach at openjdk.org> wrote:

> In #24773, people were concerned that the layout of a UTF16 byte array and a char array may be incompatible. In fact, they are - they are asserted in a corner in `LibraryCallKit::inline_string_char_access` in `library_call.cpp`.
> 
> In addition, another frequent error I see is that contributors have confused the meaning of indices in StringUTF16 - the indices are always in char array indices. I think we should make these explicit to help future maintenance.

This pull request has now been integrated.

Changeset: fe09e93b
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fe09e93b8fc3081c944f3824fdaa55cc17e377a8
Stats:     12 lines in 1 file changed: 12 ins; 0 del; 0 mod

8364317: Explicitly document some assumptions of StringUTF16

Reviewed-by: rgiulietti, rriggs, vyazici

-------------

PR: https://git.openjdk.org/jdk/pull/26541

From liach at openjdk.org  Thu Jul 31 18:39:20 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 31 Jul 2025 18:39:20 GMT
Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v5]
In-Reply-To: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
Message-ID: <HOa_aFj1YUwHFZbNgS-Py-MofBBKB6xDu7usWQJC4AU=.bd4c2060-1b3e-4615-9527-2aa8edc2abe1@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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Move exception to Java code, stress the field must be known
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/unsafe-field-offset
 - Test to verify observed internal unsafe behaviors
 - Add tck coverage
 - Explicit static checks
 - Simplify
 - Add static check
 - Document IAE for Unsafe offset methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25945/files
  - new: https://git.openjdk.org/jdk/pull/25945/files/57f863b7..71584eb3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25945&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25945&range=03-04

  Stats: 67725 lines in 1877 files changed: 38128 ins; 19192 del; 10405 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 naoto at openjdk.org  Thu Jul 31 18:48:31 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 31 Jul 2025 18:48:31 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
Message-ID: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>

Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.

-------------

Commit messages:
 - Merge branch 'master' into JDK-8363972-Loose-matching-dash
 - tidying up
 - test location
 - spec update
 - readObject
 - Merge branch 'master' into JDK-8363972-Loose-matching-dash
 - lenientminus -> NumberElements
 - lenientMinusSign -> serial, moved to NumberElements
 - tentative
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/26580/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8363972
  Stats: 386 lines in 8 files changed: 351 ins; 20 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/26580.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26580/head:pull/26580

PR: https://git.openjdk.org/jdk/pull/26580

From liach at openjdk.org  Thu Jul 31 19:04:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 31 Jul 2025 19:04:34 GMT
Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v6]
In-Reply-To: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
Message-ID: <nB8C9HdNf8Sb4QJmdB_czsVwpwC6MMWswamNeb9Fh3g=.49bf352e-5561-41d0-887a-7ab95544b62e@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:

  Less specific reasons for IAE

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25945/files
  - new: https://git.openjdk.org/jdk/pull/25945/files/71584eb3..d920ec13

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25945&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25945&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 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 jrose at openjdk.org  Thu Jul 31 19:16:56 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 31 Jul 2025 19:16:56 GMT
Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v6]
In-Reply-To: <nB8C9HdNf8Sb4QJmdB_czsVwpwC6MMWswamNeb9Fh3g=.49bf352e-5561-41d0-887a-7ab95544b62e@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <nB8C9HdNf8Sb4QJmdB_czsVwpwC6MMWswamNeb9Fh3g=.49bf352e-5561-41d0-887a-7ab95544b62e@github.com>
Message-ID: <OmUOX5rg8idVBjunIP90FpQajlzBM42sNqnysNzVZcM=.84b4ee34-031b-4fa2-a597-98f0e02344cf@github.com>

On Thu, 31 Jul 2025 19:04:34 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:
> 
>   Less specific reasons for IAE

This works for me.

-------------

Marked as reviewed by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25945#pullrequestreview-3076625989

From duke at openjdk.org  Thu Jul 31 20:50:36 2025
From: duke at openjdk.org (Darragh Conway)
Date: Thu, 31 Jul 2025 20:50:36 GMT
Subject: RFR: 8363720: Follow up to JDK-8360411 with post review comments
 [v4]
In-Reply-To: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
References: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
Message-ID: <d7VW24vRY93DN_fWsU52HxRm4xf52Q8A_znZUm17HjI=.30dc1c44-0b1e-4513-999e-992407730273@github.com>

> There were a couple of post review comments after the /integrate command was submitted. This issue will address those comments. Also created constants for hardcoded values and tests. Fixed some typos.

Darragh Conway has updated the pull request incrementally with one additional commit since the last revision:

  Implemented Brian's suggestion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26445/files
  - new: https://git.openjdk.org/jdk/pull/26445/files/7468b4b1..0b55f244

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26445&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26445&range=02-03

  Stats: 14 lines in 1 file changed: 2 ins; 9 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26445.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26445/head:pull/26445

PR: https://git.openjdk.org/jdk/pull/26445

From duke at openjdk.org  Thu Jul 31 20:58:55 2025
From: duke at openjdk.org (Darragh Conway)
Date: Thu, 31 Jul 2025 20:58:55 GMT
Subject: RFR: 8363720: Follow up to JDK-8360411 with post review comments
 [v3]
In-Reply-To: <raOLWlnapE13NGdaDjraiok_GRt5zR7r3-_7ZdyibgA=.2b7a865f-0e02-4655-97e8-0ebabf21f2a9@github.com>
References: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
 <bxhUtcshp1dDVJgMzQtJAGz5C6u4ckZ3KGiBdpWLh20=.431191d5-0682-4983-9598-280763356282@github.com>
 <raOLWlnapE13NGdaDjraiok_GRt5zR7r3-_7ZdyibgA=.2b7a865f-0e02-4655-97e8-0ebabf21f2a9@github.com>
Message-ID: <U65q4bBvIsYSnE7xvziG6RIXxy-iEe5N7WU9qf_G5kk=.17a0103d-379f-4eee-ac63-e07db66ca9e9@github.com>

On Tue, 29 Jul 2025 18:48:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Darragh Conway has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix remaining indentation errors (From my first commit on this branch)
>
> test/jdk/java/io/File/MaxPathLength.java line 69:
> 
>> 67:     }
>> 68: 
>> 69:     private static void setIsWindows() {
> 
> Instead of `isWindows` and `setIsWindows`, perhaps you should consider using `jdk.test.lib.Platform.isWindows()`? See, for example, [GetXSpace.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/io/File/GetXSpace.java), lines 30-31, 46, and 109.

Is it better to keep the variable isWindows and call Platform.isWindows() upon creating the variable? For example:
`private static boolean isWindows = Platform.isWindows();`

and just leave it like this:

line 64

if (isWindows) {
            testLongPath();
        }


line 145

if (isWindows &&
                !fu.getCanonicalPath().equals(f.getCanonicalPath()))
                throw new RuntimeException ("getCanonicalPath() failed");



Or is the last commit sufficient?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26445#discussion_r2246363303

From duke at openjdk.org  Thu Jul 31 21:00:59 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Thu, 31 Jul 2025 21:00:59 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
In-Reply-To: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
Message-ID: <kkvOk-QQEqJ7Wk5E610EIQtemolyXErsu1y-ku1kRmw=.b7a066ef-9856-472f-9dda-0d31495eff9d@github.com>

On Thu, 31 Jul 2025 18:41:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.

make/jdk/src/classes/build/tools/cldrconverter/LDMLParseHandler.java line 851:

> 849:             {
> 850:                 String level = attributes.getValue("level");
> 851:                 if (level != null && level.equals("lenient")) {

This could be slightly simplified:
Suggestion:

                if ("lenient".equals(level)) {

src/java.base/share/classes/java/text/DecimalFormat.java line 3526:

> 3524:         }
> 3525: 
> 3526:         if (!parseStrict) {

Possible early return here: by inverting the `if` you could `return text.regionMatches(...)` immediately, and remove one level of indentation from the big block in L3527-3543

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 1002:

> 1000: 
> 1001:         if (loadNumberData(locale) instanceof Object[] d &&
> 1002:             d[0] instanceof String[] numberElements) {

Should the size be validated here, before accessing `d[0]`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2246351119
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2246365822
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2246361036

From rriggs at openjdk.org  Thu Jul 31 21:14:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 31 Jul 2025 21:14:53 GMT
Subject: RFR: 8363720: Follow up to JDK-8360411 with post review comments
 [v4]
In-Reply-To: <d7VW24vRY93DN_fWsU52HxRm4xf52Q8A_znZUm17HjI=.30dc1c44-0b1e-4513-999e-992407730273@github.com>
References: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
 <d7VW24vRY93DN_fWsU52HxRm4xf52Q8A_znZUm17HjI=.30dc1c44-0b1e-4513-999e-992407730273@github.com>
Message-ID: <PnMQAXeZdBITdOOVzUbduoNI5vsnNiGbZolYAv6Fobc=.78a806b9-db9c-45bc-aa11-431ad7f3f493@github.com>

On Thu, 31 Jul 2025 20:50:36 GMT, Darragh Conway <duke at openjdk.org> wrote:

>> There were a couple of post review comments after the /integrate command was submitted. This issue will address those comments. Also created constants for hardcoded values and tests. Fixed some typos.
>
> Darragh Conway has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented Brian's suggestion

I assume the post review comments referenced are in PR#26193.  (Should have been linked in the description).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26445#issuecomment-3141352451

From duke at openjdk.org  Thu Jul 31 21:24:55 2025
From: duke at openjdk.org (Darragh Conway)
Date: Thu, 31 Jul 2025 21:24:55 GMT
Subject: RFR: 8363720: Follow up to JDK-8360411 with post review comments
 [v4]
In-Reply-To: <d7VW24vRY93DN_fWsU52HxRm4xf52Q8A_znZUm17HjI=.30dc1c44-0b1e-4513-999e-992407730273@github.com>
References: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
 <d7VW24vRY93DN_fWsU52HxRm4xf52Q8A_znZUm17HjI=.30dc1c44-0b1e-4513-999e-992407730273@github.com>
Message-ID: <V4SHPNpKU65bDhM8_xotWV9SJeLDUuwqzutRbQxqD4M=.0e073fc5-c267-48ae-b3fc-f0c7fc73f5e2@github.com>

On Thu, 31 Jul 2025 20:50:36 GMT, Darragh Conway <duke at openjdk.org> wrote:

>> There were a couple of post review comments after the /integrate command was submitted. This issue will address those comments. Also created constants for hardcoded values and tests. Fixed some typos.
>
> Darragh Conway has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented Brian's suggestion

It was yeah, sorry about that... Can I edit the description to include the link to PR#26193?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26445#issuecomment-3141372880

From missa at openjdk.org  Thu Jul 31 21:27:55 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Thu, 31 Jul 2025 21:27:55 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v2]
In-Reply-To: <JZZ83ZL8aCcuAHnXqQqPhdVeOHWOysm_vNKUE87jLgY=.92273cdc-bfca-4897-963c-382341c5b226@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <9pe9LuUrBnk6A2TQ2emhgonljAvnJLcmSV_lEbrYIlo=.fec9b081-d6ae-4d85-8826-489828d9f442@github.com>
 <JZZ83ZL8aCcuAHnXqQqPhdVeOHWOysm_vNKUE87jLgY=.92273cdc-bfca-4897-963c-382341c5b226@github.com>
Message-ID: <bl5aVGE9cFkrH8gvKBj4g7FppqDY7Vbb2EeInE0aCFM=.a530da0d-af87-42dd-aaf4-f74c33506306@github.com>

On Wed, 30 Jul 2025 18:26:22 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move error bound to separate section in comment header
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_sinh.cpp line 325:
> 
>> 323:   __ jcc(Assembler::aboveEqual, L_2TAG_PACKET_0_0_2); // Branch only if |x| is not in [23/64, 3*2^8)
>> 324:   __ movsd(xmm3, ExternalAddress(HALFMASK), r11 /*rscratch*/);
>> 325:   __ movsd(xmm1, ExternalAddress(L2E), r11 /*rscratch*/);
> 
> xmm1 is used at L_2TAG_PACKET_0_0_2 -> L_2TAG_PACKET_3_0_2 line 507 below so should be loaded prior to L_2TAG_PACKET_0_0_2.

At the end of L_2TAG_PACKET_3_0_2, the goal is to generate +/- Infinity and set the overflow flag, so the L2E load into xmm1 actually doesn't matter in this case. I'll move the load to ensure xmm1 is initialized with a known value before it's used though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26152#discussion_r2246405871

From missa at openjdk.org  Thu Jul 31 21:32:16 2025
From: missa at openjdk.org (Mohamed Issa)
Date: Thu, 31 Jul 2025 21:32:16 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v3]
In-Reply-To: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
Message-ID: <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@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.

Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:

  Make sure xmm1 is initialized before potential use in L_2TAG_PACKET_3_0_2

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26152/files
  - new: https://git.openjdk.org/jdk/pull/26152/files/c0adc8b3..3ab7ab3e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26152&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26152&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 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 bpb at openjdk.org  Thu Jul 31 21:56:54 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 31 Jul 2025 21:56:54 GMT
Subject: RFR: 8363720: Follow up to JDK-8360411 with post review comments
 [v3]
In-Reply-To: <U65q4bBvIsYSnE7xvziG6RIXxy-iEe5N7WU9qf_G5kk=.17a0103d-379f-4eee-ac63-e07db66ca9e9@github.com>
References: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
 <bxhUtcshp1dDVJgMzQtJAGz5C6u4ckZ3KGiBdpWLh20=.431191d5-0682-4983-9598-280763356282@github.com>
 <raOLWlnapE13NGdaDjraiok_GRt5zR7r3-_7ZdyibgA=.2b7a865f-0e02-4655-97e8-0ebabf21f2a9@github.com>
 <U65q4bBvIsYSnE7xvziG6RIXxy-iEe5N7WU9qf_G5kk=.17a0103d-379f-4eee-ac63-e07db66ca9e9@github.com>
Message-ID: <tadGjrKZC2zF8ZBqa7N2hGETAH54MVnzBrroOTqlw9k=.5ed42707-3a47-4f9d-95c5-d319c1a35d73@github.com>

On Thu, 31 Jul 2025 20:56:22 GMT, Darragh Conway <duke at openjdk.org> wrote:

> Or is the last commit sufficient?

I don't think that there is any point in keeping the `isWindows` constant as it would be used in only one place, thus I think that the most recent commit is sufficient for this purpose.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26445#discussion_r2246458693

From naoto at openjdk.org  Thu Jul 31 22:04:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 31 Jul 2025 22:04:56 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v2]
In-Reply-To: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
Message-ID: <-jShvVkEpQ1sPrcEvsMOTj-91dL1vm_ZFhw7NSUJ8jE=.7368c6c6-6126-410e-9fa7-b694122c9bc9@github.com>

> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26580/files
  - new: https://git.openjdk.org/jdk/pull/26580/files/33e99461..235138d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=00-01

  Stats: 48 lines in 3 files changed: 18 ins; 19 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/26580.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26580/head:pull/26580

PR: https://git.openjdk.org/jdk/pull/26580

From bpb at openjdk.org  Thu Jul 31 22:10:54 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 31 Jul 2025 22:10:54 GMT
Subject: RFR: 8363720: Follow up to JDK-8360411 with post review comments
 [v4]
In-Reply-To: <d7VW24vRY93DN_fWsU52HxRm4xf52Q8A_znZUm17HjI=.30dc1c44-0b1e-4513-999e-992407730273@github.com>
References: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
 <d7VW24vRY93DN_fWsU52HxRm4xf52Q8A_znZUm17HjI=.30dc1c44-0b1e-4513-999e-992407730273@github.com>
Message-ID: <dNQWbdC-Axhq-j-MYbMsFfdTMnA7kXPsMobyZRqv9Xg=.e3190564-a606-47ec-8c60-4e7d460291bc@github.com>

On Thu, 31 Jul 2025 20:50:36 GMT, Darragh Conway <duke at openjdk.org> wrote:

>> There were a couple of post review comments for PR: https://github.com/openjdk/jdk/pull/26193 after the /integrate command was submitted. This issue will address those comments. Also created constants for hardcoded values and tests. Fixed some typos.
>
> Darragh Conway has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented Brian's suggestion

test/jdk/java/io/File/MaxPathLength.java line 208:

> 206:     }
> 207: }
> 208: 

Looks like there are a couple of blank lines at the end. I thought whitespace detection would flag it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26445#discussion_r2246478015

From naoto at openjdk.org  Thu Jul 31 22:11:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 31 Jul 2025 22:11:55 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v2]
In-Reply-To: <kkvOk-QQEqJ7Wk5E610EIQtemolyXErsu1y-ku1kRmw=.b7a066ef-9856-472f-9dda-0d31495eff9d@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
 <kkvOk-QQEqJ7Wk5E610EIQtemolyXErsu1y-ku1kRmw=.b7a066ef-9856-472f-9dda-0d31495eff9d@github.com>
Message-ID: <m6z0vmAes7aQk4QpJsPqS18dcLczUkQ-_52aCm7vIvg=.dd097645-37a0-4398-b725-9230efbe9c1b@github.com>

On Thu, 31 Jul 2025 20:55:01 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 1002:
> 
>> 1000: 
>> 1001:         if (loadNumberData(locale) instanceof Object[] d &&
>> 1002:             d[0] instanceof String[] numberElements) {
> 
> Should the size be validated here, before accessing `d[0]`?

This should be fine, as there would be no situation where empty array would be returned: https://github.com/openjdk/jdk/blob/724e8c076e1aed05de893ef9366af0e62cc2ac2b/src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java#L223
I modified the `else` case, where the field was not initialized, btw.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2246478764

From duke at openjdk.org  Thu Jul 31 22:16:55 2025
From: duke at openjdk.org (Darragh Conway)
Date: Thu, 31 Jul 2025 22:16:55 GMT
Subject: RFR: 8363720: Follow up to JDK-8360411 with post review comments
 [v5]
In-Reply-To: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
References: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
Message-ID: <kJJVhUhIjdv5bhF2UUoPNze4bBgBGula-2ps0QDR1hk=.0a3102d1-b4c3-4b96-b042-b3c16cab23bb@github.com>

> There were a couple of post review comments for PR: https://github.com/openjdk/jdk/pull/26193 after the /integrate command was submitted. This issue will address those comments. Also created constants for hardcoded values and tests. Fixed some typos.

Darragh Conway has updated the pull request incrementally with one additional commit since the last revision:

  removed blank lines at end of file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26445/files
  - new: https://git.openjdk.org/jdk/pull/26445/files/0b55f244..67c73d1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26445&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26445&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26445.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26445/head:pull/26445

PR: https://git.openjdk.org/jdk/pull/26445

From duke at openjdk.org  Thu Jul 31 22:16:56 2025
From: duke at openjdk.org (Darragh Conway)
Date: Thu, 31 Jul 2025 22:16:56 GMT
Subject: RFR: 8363720: Follow up to JDK-8360411 with post review comments
 [v4]
In-Reply-To: <dNQWbdC-Axhq-j-MYbMsFfdTMnA7kXPsMobyZRqv9Xg=.e3190564-a606-47ec-8c60-4e7d460291bc@github.com>
References: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
 <d7VW24vRY93DN_fWsU52HxRm4xf52Q8A_znZUm17HjI=.30dc1c44-0b1e-4513-999e-992407730273@github.com>
 <dNQWbdC-Axhq-j-MYbMsFfdTMnA7kXPsMobyZRqv9Xg=.e3190564-a606-47ec-8c60-4e7d460291bc@github.com>
Message-ID: <J5pznVNM_L52TYcYaxUbNa_O1eBYrEydgTwhpd1cyNE=.9f656749-ac08-4bcd-a3cd-ecfd276e04ce@github.com>

On Thu, 31 Jul 2025 22:08:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Darragh Conway has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented Brian's suggestion
>
> test/jdk/java/io/File/MaxPathLength.java line 208:
> 
>> 206:     }
>> 207: }
>> 208: 
> 
> Looks like there are a couple of blank lines at the end. I thought whitespace detection would flag it.

Missed that... Should be removed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26445#discussion_r2246486315

From naoto at openjdk.org  Thu Jul 31 22:23:36 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 31 Jul 2025 22:23:36 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v3]
In-Reply-To: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
Message-ID: <NhmPotjTZcDsLYSw15RRIIA60FHySlz53Pk6f3quaG0=.e138ec15-9d34-452e-895c-89a2d3ee1198@github.com>

> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  flipped the size check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26580/files
  - new: https://git.openjdk.org/jdk/pull/26580/files/235138d5..516403e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26580.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26580/head:pull/26580

PR: https://git.openjdk.org/jdk/pull/26580

From naoto at openjdk.org  Thu Jul 31 22:30:35 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 31 Jul 2025 22:30:35 GMT
Subject: RFR: 8363972: Loose matching of dash/minusSign in number parsing
 [v4]
In-Reply-To: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
References: <mv62kn0JNlIDF4xcLiWjwp1RaYGaWoOTqhvgFZE3zUs=.d229bc58-d0b3-405f-9a85-7510f91502d3@github.com>
Message-ID: <DtV-__lo4sL7akdq2buxSm7YkxFnN7jZzpFtFD7H2ug=.df4332a4-eb68-4d94-b8ab-273dc2b90c6e@github.com>

> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  flipped again, which was correct

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26580/files
  - new: https://git.openjdk.org/jdk/pull/26580/files/516403e8..38f3286f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26580&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26580.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26580/head:pull/26580

PR: https://git.openjdk.org/jdk/pull/26580

From bpb at openjdk.org  Thu Jul 31 22:48:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 31 Jul 2025 22:48:53 GMT
Subject: RFR: 8363720: Follow up to JDK-8360411 with post review comments
 [v3]
In-Reply-To: <tadGjrKZC2zF8ZBqa7N2hGETAH54MVnzBrroOTqlw9k=.5ed42707-3a47-4f9d-95c5-d319c1a35d73@github.com>
References: <w6Wmg_C0X__q6musc-VTvdqsqv9-M-VDg-hv_ReQ6vA=.dfab65d7-7279-4c92-8f47-41dae38b2708@github.com>
 <bxhUtcshp1dDVJgMzQtJAGz5C6u4ckZ3KGiBdpWLh20=.431191d5-0682-4983-9598-280763356282@github.com>
 <raOLWlnapE13NGdaDjraiok_GRt5zR7r3-_7ZdyibgA=.2b7a865f-0e02-4655-97e8-0ebabf21f2a9@github.com>
 <U65q4bBvIsYSnE7xvziG6RIXxy-iEe5N7WU9qf_G5kk=.17a0103d-379f-4eee-ac63-e07db66ca9e9@github.com>
 <tadGjrKZC2zF8ZBqa7N2hGETAH54MVnzBrroOTqlw9k=.5ed42707-3a47-4f9d-95c5-d319c1a35d73@github.com>
Message-ID: <QOGnDN4f1HM3UgFc0KdHw_Hj6SMsNqJ_Ej0Bo7J7GeA=.68f179ed-e7b9-4098-b6b9-efdeb36e331d@github.com>

On Thu, 31 Jul 2025 21:53:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> as it would be used in only one place

This comment was incorrect, sorry, but I still think the `isWindows` constant is not needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26445#discussion_r2246525449

From sviswanathan at openjdk.org  Thu Jul 31 23:03:55 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 31 Jul 2025 23:03:55 GMT
Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms [v3]
In-Reply-To: <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <_c3ITcxrb66Z6Bq4dJc5uHhPFawXXfhyOhscoGicO3k=.2214b54a-c875-41be-936c-550efd649b91@github.com>
Message-ID: <u1ilI1NjO_n5aSZvJErmPO3pvUr0tXFpg4722xlEPvo=.a962fa71-d6d8-4bbb-bbb0-3649058933ce@github.com>

On Thu, 31 Jul 2025 21:32:16 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.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make sure xmm1 is initialized before potential use in L_2TAG_PACKET_3_0_2

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26152#pullrequestreview-3077118616

From jlu at openjdk.org  Thu Jul 31 23:17:25 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 31 Jul 2025 23:17:25 GMT
Subject: RFR: 8364370: java.text.DecimalFormat specification indentation
 correction
Message-ID: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>

Please review this doc only PR.

java.text.DecimalFormat uses an implSpec tag in the middle of the class description. This location was on purpose as the contents related to the surrounding section. However, this has caused slight indentation in the rest of the class description below the tag (as pointed out by @naotoj) . Using the implSpec tag at the bottom of the class is preferable for formatting purposes.

There are no contract changes, simply a re-organization of existing contents, thus no CSR is filed.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/26585/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26585&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364370
  Stats: 13 lines in 1 file changed: 7 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26585.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26585/head:pull/26585

PR: https://git.openjdk.org/jdk/pull/26585

From liach at openjdk.org  Thu Jul 31 23:23:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 31 Jul 2025 23:23:58 GMT
Subject: RFR: 8364370: java.text.DecimalFormat specification indentation
 correction
In-Reply-To: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
References: <FfSMQZ8m9VpOPwaflxIbfEkTUZ5Hywot9q8OQ3VFTy4=.d01a34ec-9a79-41f7-8d83-ba33bd3ef5fb@github.com>
Message-ID: <cJD3ayzO-dHf5SY1_p1oFpGc9lEwC7XRmo2W12qkO8Q=.7e13b4b7-4769-4303-81ef-7b3873ccb750@github.com>

On Thu, 31 Jul 2025 23:12:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this doc only PR.
> 
> java.text.DecimalFormat uses an implSpec tag in the middle of the class description. This location was on purpose as the contents related to the surrounding section. However, this has caused slight indentation in the rest of the class description below the tag (as pointed out by @naotoj) . Using the implSpec tag at the bottom of the class is preferable for formatting purposes.
> 
> There are no contract changes, simply a re-organization of existing contents, thus no CSR is filed.

In fact, per the [specs](https://docs.oracle.com/en/java/javase/24/docs/specs/javadoc/doc-comment-spec.html#block-tags):

> The content of a block tag is any text following the tag up to, but not including, either the next block tag, or the end of the documentation comment.

It may be surprising that block tags have higher precedence over HTML headers. Just a note for the future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26585#issuecomment-3141617957

From chen.l.liang at oracle.com  Thu Jul 31 23:29:53 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Thu, 31 Jul 2025 23:29:53 +0000
Subject: =?gb2312?B?UmU6ILvYuLSjulJldXNlIHRoZSBTdHJpbmdVVEYxNjo6cHV0Q2hhcnNTQiBt?=
 =?gb2312?B?ZXRob2QgaW5zdGVhZCBvZiB0aGUgSW50cmluc2ljIGluIHRoZSBTdHJpbmdV?=
 =?gb2312?Q?TF16::toBytes?=
In-Reply-To: <a7120887-02d3-475f-806a-efcf186f70c3.shaojin.wensj@alibaba-inc.com>
References: <086fd3c9-30e0-4294-b674-ece0bd91051c.shaojin.wensj@alibaba-inc.com>
 <c8e344e8-f63a-49b1-b5d2-3fb19977e74a@oracle.com>,
 <9b1f2b83-2e0e-443f-a1af-307bcf871974@oracle.com>
 <a7120887-02d3-475f-806a-efcf186f70c3.shaojin.wensj@alibaba-inc.com>
Message-ID: <MW6PR10MB76875370E2864A94D340DF9AA227A@MW6PR10MB7687.namprd10.prod.outlook.com>

Hi all,
I think the key takeaway here is that we should reduce the number of intrinsics for easier maintenance. With the same number of unsafe Java methods, it is still feasible to reduce the number of distinct intrinsics simply for the reduced maintenance cost.
For example, the toBytes and getChars of StringUTF16 both have intrinsics. However, in essence, they are just two array copy functions - it would be more reasonable for hotspot to implement a generic array copy intrinsic that StringUTF16 can use instead. Such an intrinsic may take place on Unsafe.copyMemory itself, or may be somewhere else.

Chen
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of wenshao <shaojin.wensj at alibaba-inc.com>
Sent: Wednesday, July 30, 2025 9:45 PM
To: Roger Riggs <roger.riggs at oracle.com>; core-libs-dev <core-libs-dev at openjdk.org>
Subject: ???Reuse the StringUTF16::putCharsSB method instead of the Intrinsic in the StringUTF16::toBytes

Thanks to Roger Riggs for suggesting that the code should not be called with Unsafe.uninitializedArray.

After replacing it with `new byte[]` and running `StringConstructor.newStringFromCharsMixedBegin`, I verified that performance remained consistent on x64. On aarch64, performance improved by 8% for size = 7, but decreased by 7% for size = 64.

For detailed performance data, see the Markdown data in the draft pull request I submitted.https://github.com/openjdk/jdk/pull/26553#issuecomment-3138357748

-
Shaojin Wen

------------------------------------------------------------------
????Roger Riggs <roger.riggs at oracle.com>
?????2025?7?31?(??) 03:17
????"core-libs-dev"<core-libs-dev at openjdk.org>
????Re: Reuse the StringUTF16::putCharsSB method instead of the Intrinsic in the StringUTF16::toBytes

Hi,

Unsafe.uninitializedArray and StringConcatHelper.newArray was created for the exclusive use of StringConcatHelper and by  HotSpot optimizations. Unsafe.uninitializedArray and StringConcatHelper.newArray area very sensitive APIs and should NOT be used anywhere except in StringConcatHelper and HotSpot.

Regards, Roger


On 7/30/25 11:40 AM, jaikiran.pai at oracle.com<mailto:jaikiran.pai at oracle.com> wrote:

I'll let others knowledgeable in this area to comment and provide inputs to this proposal. I just want to say thank you for bringing up this discussion to the mailing list first, providing the necessary context and explanation and seeking feedback, before creating a JBS issue or a RFR PR.

-Jaikiran

On 30/07/25 7:48 pm, wenshao wrote:
In the discussion of `8355177: Speed up StringBuilder::append(char[]) via Unsafe::copyMemory` (https://github.com/openjdk/jdk/pull/24773), @liach (Chen Liang) suggested reusing the StringUTF16::putCharsSB method introduced in PR #24773 instead of the Intrinsic implementation in the StringUTF16::toBytes method.

Original:
```java
    @IntrinsicCandidate
    public static byte[] toBytes(char[] value, int off, int len) {
        byte[] val = newBytesFor(len);
        for (int i = 0; i < len; i++) {
            putChar(val, i, value[off]);
            off++;
        }
        return val;
    }
```

After:
```java
    public static byte[] toBytes(char[] value, int off, int len) {
        byte[] val = (byte[]) Unsafe.getUnsafe().allocateUninitializedArray(byte.class, newBytesLength(len));
        putCharsSB(val, 0, value, off, off + len);
        return val;
    }
```

This replacement does not degrade performance. Running StringConstructor.newStringFromCharsMixedBegin verified that performance is consistent with the original on x64 and slightly improved on aarch64.

The implementation after replacing the Intrinsic implementation removed 100 lines of C++ code, leaving only Java and Unsafe code, no Intrinsic or C++ code, which makes the code more maintainable.

I've submitted a draft PR https://github.com/openjdk/jdk/pull/26553 , please give me some feedback.
-
Shaojin Wen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250731/c3a3bcd3/attachment-0001.htm>

From liach at openjdk.org  Thu Jul 31 23:34:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 31 Jul 2025 23:34:55 GMT
Subject: RFR: 8364187: Make getClassAccessFlagsRaw non-native [v5]
In-Reply-To: <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
References: <84FVULnDO38-jO9EcshCFwsOx9PRZ920y8KwTt5z0xU=.6b4b8adb-b046-481f-b121-dd1ffa0d7a78@github.com>
 <OTesEAkdX96WVb301WvYlLnq4Nj2rHyFYFjZlEj-8aQ=.2fe5944e-af96-4e40-ab5b-0a619ae86f1f@github.com>
Message-ID: <-4Y7tMRv4npz0NHmvNpe4WCP1DSfZwQDMD2uxE36QNE=.8a72f648-6901-4556-9265-ae665992865b@github.com>

On Wed, 30 Jul 2025 19:25:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the intrinsic for getClassAccessFlagsRaw for reflection and initializes an rawAccessFlags field in java.lang.Class instead, that Java code can non-natively access.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore c2 optimization.

These changes look reasonable.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26517#pullrequestreview-3077160252