From syan at openjdk.org  Sun Feb  1 02:11:44 2026
From: syan at openjdk.org (SendaoYan)
Date: Sun, 1 Feb 2026 02:11:44 GMT
Subject: RFR: 8376760: VerifyJimage.java#compare intermittent failed with
 fastdebug [v2]
In-Reply-To: <j360mZjyQnFn5YnxFiE75b-6WEbzQh0AHBDFRTmo6Zk=.fc329853-99bc-4867-bc81-d9ffa46ba386@github.com>
References: <j360mZjyQnFn5YnxFiE75b-6WEbzQh0AHBDFRTmo6Zk=.fc329853-99bc-4867-bc81-d9ffa46ba386@github.com>
Message-ID: <uTnw1rDAncaE7aGXa8xuI5jcCOct1lRmiH6zI5ASxzQ=.ba0551ba-ed13-47d3-9b2a-5780cb75ad3f@github.com>

> Hi all,
> 
> Test tools/jimage/VerifyJimage.java#compare intermittent timed out with fastdebug build. I think it would be better to ajust the jtreg timeout factor(20*timeoutFactor) rather that set the fix timeout value(20) for awaitTermination.
> 
> The test run all passed 100 times simultaneously.

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

  Use ExecutorService.close() instead of ExecutorService.shutdown()/ExecutorService.awaitTermination()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29498/files
  - new: https://git.openjdk.org/jdk/pull/29498/files/e2dbe7c4..4a0d1301

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

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

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

From syan at openjdk.org  Sun Feb  1 02:11:45 2026
From: syan at openjdk.org (SendaoYan)
Date: Sun, 1 Feb 2026 02:11:45 GMT
Subject: RFR: 8376760: VerifyJimage.java#compare intermittent failed with
 fastdebug [v2]
In-Reply-To: <vifZP3w8tPaOa49RHY4eEhsaLaCJg1175JIeTkORh00=.46886a55-6714-43e7-82d5-dc92b3ef36d9@github.com>
References: <j360mZjyQnFn5YnxFiE75b-6WEbzQh0AHBDFRTmo6Zk=.fc329853-99bc-4867-bc81-d9ffa46ba386@github.com>
 <vifZP3w8tPaOa49RHY4eEhsaLaCJg1175JIeTkORh00=.46886a55-6714-43e7-82d5-dc92b3ef36d9@github.com>
Message-ID: <B970avPcmF4sVTazV18d4jLBdsI-5nwOApTdZjVxEAI=.eea41e7d-5e8d-405c-9ef9-deceafeac42d@github.com>

On Sat, 31 Jan 2026 17:15:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use ExecutorService.close() instead of ExecutorService.shutdown()/ExecutorService.awaitTermination()
>
> test/jdk/tools/jimage/VerifyJimage.java line 152:
> 
>> 150:                 long timeout = Utils.adjustTimeout(20);
>> 151:                 if (!pool.awaitTermination(timeout, TimeUnit.SECONDS)) {
>> 152:                     failed.add("Directory verification timed out in " + timeout + " seconds");
> 
> The alternative is to just replace the shutdown + awaitTermination with a call to `pool.close()`. This will wait indefinitely, which is useful for diagnosability if the verification hangs.

Thanks. The shutdown/awaitTermination has been replaced as ExecutorService.close(). The catch InterruptedException do not needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29498#discussion_r2750394856

From duke at openjdk.org  Sun Feb  1 06:28:49 2026
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 1 Feb 2026 06:28:49 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v20]
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <cmtXT31koW4hw4YZk51Jwi6ELCPrkGNIYnZAh1uwmg8=.96ea745b-b536-453e-9715-4fac3929e78f@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 two additional commits since the last revision:

 - Update JavaDoc
 - Fix broken test methods calls

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26461/files
  - new: https://git.openjdk.org/jdk/pull/26461/files/81245159..8b5db22c

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

  Stats: 7 lines in 2 files changed: 3 ins; 0 del; 4 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 jbhateja at openjdk.org  Sun Feb  1 07:41:59 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 1 Feb 2026 07:41:59 GMT
Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass
 them to intrinsic entries [v5]
In-Reply-To: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
References: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
Message-ID: <HDJ2eVePQDTb_IwIowCiEgYouhAbGZdRnyUkHIUWTKM=.4ee6f8f0-8305-4de2-adb4-74f3886b6aa5@github.com>

> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support.
> 
> Patch add new lane type constants and pass them to vector intrinsic entry points.
> 
> All existing Vector API jtreg test are passing with the patch.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

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

  Review comments resolution

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29481/files
  - new: https://git.openjdk.org/jdk/pull/29481/files/ff73dc3d..0c60016b

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

  Stats: 401 lines in 39 files changed: 28 ins; 62 del; 311 mod
  Patch: https://git.openjdk.org/jdk/pull/29481.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29481/head:pull/29481

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

From jbhateja at openjdk.org  Sun Feb  1 07:42:04 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 1 Feb 2026 07:42:04 GMT
Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass
 them to intrinsic entries [v4]
In-Reply-To: <-fsfUEvFpvmAsupQFgx1CBkH9vr_efE5-qYeUzy5VFQ=.4abb05e0-1f82-4d6c-8bc4-ca4bc6fc5e80@github.com>
References: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
 <jl3TdydD4GH391dpmUMMJ52pbk7E3FsIc7DoKAA4d_4=.9c4b0f59-6892-45f9-a7c4-bb6553a66ef0@github.com>
 <-fsfUEvFpvmAsupQFgx1CBkH9vr_efE5-qYeUzy5VFQ=.4abb05e0-1f82-4d6c-8bc4-ca4bc6fc5e80@github.com>
Message-ID: <GDwSxVuqx8MhrECnCnDKiUKNAjw8WiGhKqO4fj3zC_M=.8cf6b098-d621-43d4-8c70-7eacc140a2d4@github.com>

On Fri, 30 Jan 2026 23:31:29 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractSpecies.java line 152:
> 
>> 150:     int laneTypeOrdinal() {
>> 151:         return laneType.ordinal();
>> 152:     }
> 
> Is this needed? Won't all concrete sub types override this?

This interface provides access to lane type constant though species, its used for consistency, please have a look at following line and other places around it.
https://github.com/jatin-bhateja/jdk/blob/ff73dc3d48a9435c4395556c8325fbce7610cba9/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java#L3374

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 60:
> 
>> 58: 
>> 59:     static final int LANE_TYPE_ORDINAL = LT_BYTE;
>> 60: 
> 
> You can move this up to `ByteVector` and then reuse it to replace `byte.class`, so it is used consistently.

Done

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java line 821:
> 
>> 819:     convert(String name, char kind, Class<E> dom, Class<F> ran, int opCode, int flags) {
>> 820:         int domran = ((LaneType.of(dom).ordinal() << VO_DOM_SHIFT) +
>> 821:                       (LaneType.of(ran).ordinal() << VO_RAN_SHIFT));
> 
> As i understand this is still correct because the maximum ordinal value is less than 16 (as was already the case for the basic type).

Correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2750675259
PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2750675162
PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2750675209

From alanb at openjdk.org  Sun Feb  1 08:23:02 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 1 Feb 2026 08:23:02 GMT
Subject: RFR: 8376760: VerifyJimage.java#compare intermittent failed with
 fastdebug [v2]
In-Reply-To: <uTnw1rDAncaE7aGXa8xuI5jcCOct1lRmiH6zI5ASxzQ=.ba0551ba-ed13-47d3-9b2a-5780cb75ad3f@github.com>
References: <j360mZjyQnFn5YnxFiE75b-6WEbzQh0AHBDFRTmo6Zk=.fc329853-99bc-4867-bc81-d9ffa46ba386@github.com>
 <uTnw1rDAncaE7aGXa8xuI5jcCOct1lRmiH6zI5ASxzQ=.ba0551ba-ed13-47d3-9b2a-5780cb75ad3f@github.com>
Message-ID: <1EDm_uTHkAU_kmBo7cxFqsYmRqmVWdM8KZUyA1J9T2s=.68d6910e-ee7a-4d9c-94f0-d750d34a8d07@github.com>

On Sun, 1 Feb 2026 02:11:44 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test tools/jimage/VerifyJimage.java#compare intermittent timed out with fastdebug build. I think it would be better to ajust the jtreg timeout factor(20*timeoutFactor) rather that set the fix timeout value(20) for awaitTermination.
>> 
>> The test run all passed 100 times simultaneously.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use ExecutorService.close() instead of ExecutorService.shutdown()/ExecutorService.awaitTermination()

test/jdk/tools/jimage/VerifyJimage.java line 26:

> 24: import jdk.internal.jimage.BasicImageReader;
> 25: import jtreg.SkippedException;
> 26: import jdk.test.lib.Utils;

Using ExecutorService::close makes it simpler, good.

I assume this import is left over from one of the iterations where you were adjusting the timeout.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29498#discussion_r2750736340

From alanb at openjdk.org  Sun Feb  1 08:29:05 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 1 Feb 2026 08:29:05 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v11]
In-Reply-To: <MowNm_yWhmNzkZQcZL0JWI1faIFqkwONVQA0qOSnq28=.75bf51db-2a3b-4ed3-b128-1d7e372fd449@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <0Ix-aiMznxsuePv7iSAqOId1aV2zTFOsW96OeD2D5cg=.fbd08430-b244-4170-8736-517ce84e08d4@github.com>
 <MowNm_yWhmNzkZQcZL0JWI1faIFqkwONVQA0qOSnq28=.75bf51db-2a3b-4ed3-b128-1d7e372fd449@github.com>
Message-ID: <O3iuGgwFMGPK8WlS8gbejS2IiFX8e11kxUnyHi2pF0Q=.0079d6e5-5deb-4905-819d-30981669ebd5@github.com>

On Wed, 28 Jan 2026 23:55:50 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update year in copyright
>
> "Create sysroot" fails:
> 
> s390x:
> 
> 
> Run sudo debootstrap --no-merged-usr --arch=s390x --verbose --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype-dev,libpng-dev --resolve-deps --variant=minbase bullseye sysroot https://httpredir.debian.org/debian/
> W: Cannot check Release signature; keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg
> I: Retrieving InRelease 
> E: Invalid Release file, no entry for main/binary-s390x/Packages
> Error: Process completed with exit code 1.
> 
> 
> ppc64le:
> 
> 
> Run sudo debootstrap --no-merged-usr --arch=ppc64el --verbose --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype-dev,libpng-dev --resolve-deps --variant=minbase bullseye sysroot https://httpredir.debian.org/debian/
> W: Cannot check Release signature; keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg
> I: Retrieving InRelease 
> E: Invalid Release file, no entry for main/binary-ppc64el/Packages
> Error: Process completed with exit code 1.

@tats-u  The tests in test/jdk/java/nio/Buffer will need to be updated to add coverage for the new method. It's really important that the method is exercises with CharBuffer views that are backed by heap/direct buffers and char sequences.

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3830610479

From alanb at openjdk.org  Sun Feb  1 08:33:11 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 1 Feb 2026 08:33:11 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v20]
In-Reply-To: <cmtXT31koW4hw4YZk51Jwi6ELCPrkGNIYnZAh1uwmg8=.96ea745b-b536-453e-9715-4fac3929e78f@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <cmtXT31koW4hw4YZk51Jwi6ELCPrkGNIYnZAh1uwmg8=.96ea745b-b536-453e-9715-4fac3929e78f@github.com>
Message-ID: <HcRVi1NlmwvnUmBO4uFYAiptwtZlq33Xic2CKzV7LDQ=.a532f796-7724-462c-98bf-295406e484c0@github.com>

On Sun, 1 Feb 2026 06:28:49 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 two additional commits since the last revision:
> 
>  - Update JavaDoc
>  - Fix broken test methods calls

src/java.base/share/classes/java/nio/X-Buffer.java.template line 2062:

> 2060:     /**
> 2061:      * {@return the number of Unicode code points in this character buffer}
> 2062:      * <p>The number of Unicode code points in this character buffer is

Keep it consistent with the existing methods if you can, meaning put a blank after before the second paragraph, space after the `<p>` and drop the trailing `</p>`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2750747902

From syan at openjdk.org  Sun Feb  1 10:19:51 2026
From: syan at openjdk.org (SendaoYan)
Date: Sun, 1 Feb 2026 10:19:51 GMT
Subject: RFR: 8376760: VerifyJimage.java#compare intermittent failed with
 fastdebug [v3]
In-Reply-To: <j360mZjyQnFn5YnxFiE75b-6WEbzQh0AHBDFRTmo6Zk=.fc329853-99bc-4867-bc81-d9ffa46ba386@github.com>
References: <j360mZjyQnFn5YnxFiE75b-6WEbzQh0AHBDFRTmo6Zk=.fc329853-99bc-4867-bc81-d9ffa46ba386@github.com>
Message-ID: <GwOWYkJcdZDAhuNJUMV3UFtExG_tTCLE_rcxTz6fs98=.4be1697f-c896-4c49-b0b2-84fdb9773280@github.com>

> Hi all,
> 
> Test tools/jimage/VerifyJimage.java#compare intermittent timed out with fastdebug build. I think it would be better to ajust the jtreg timeout factor(20*timeoutFactor) rather that set the fix timeout value(20) for awaitTermination.
> 
> The test run all passed 100 times simultaneously.

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

  Remove unnecessary import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29498/files
  - new: https://git.openjdk.org/jdk/pull/29498/files/4a0d1301..d3898845

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

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

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

From syan at openjdk.org  Sun Feb  1 10:19:55 2026
From: syan at openjdk.org (SendaoYan)
Date: Sun, 1 Feb 2026 10:19:55 GMT
Subject: RFR: 8376760: VerifyJimage.java#compare intermittent failed with
 fastdebug [v2]
In-Reply-To: <1EDm_uTHkAU_kmBo7cxFqsYmRqmVWdM8KZUyA1J9T2s=.68d6910e-ee7a-4d9c-94f0-d750d34a8d07@github.com>
References: <j360mZjyQnFn5YnxFiE75b-6WEbzQh0AHBDFRTmo6Zk=.fc329853-99bc-4867-bc81-d9ffa46ba386@github.com>
 <uTnw1rDAncaE7aGXa8xuI5jcCOct1lRmiH6zI5ASxzQ=.ba0551ba-ed13-47d3-9b2a-5780cb75ad3f@github.com>
 <1EDm_uTHkAU_kmBo7cxFqsYmRqmVWdM8KZUyA1J9T2s=.68d6910e-ee7a-4d9c-94f0-d750d34a8d07@github.com>
Message-ID: <2XdmcBGqEZr_qSLgevAt2K7gkYKUgBO_KYP41O5mnhs=.9e64fc94-f49d-4eae-b84d-41970cd01c55@github.com>

On Sun, 1 Feb 2026 08:20:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use ExecutorService.close() instead of ExecutorService.shutdown()/ExecutorService.awaitTermination()
>
> test/jdk/tools/jimage/VerifyJimage.java line 26:
> 
>> 24: import jdk.internal.jimage.BasicImageReader;
>> 25: import jtreg.SkippedException;
>> 26: import jdk.test.lib.Utils;
> 
> Using ExecutorService::close makes it simpler, good.
> 
> I assume this import is left over from one of the iterations where you were adjusting the timeout.

Sorry forgot to check it... Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29498#discussion_r2750987519

From duke at openjdk.org  Sun Feb  1 10:20:46 2026
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 1 Feb 2026 10:20:46 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v21]
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <GcKt_75EpsyvoCMr19QP31KVAsCbtU1Y8WhJB0dPJm8=.4a3c6b89-5c41-4efa-87d8-854c42f5efc3@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 one additional commit since the last revision:

  Reformat JavaDoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26461/files
  - new: https://git.openjdk.org/jdk/pull/26461/files/8b5db22c..43eb577a

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

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 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  Sun Feb  1 10:20:46 2026
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 1 Feb 2026 10:20:46 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v11]
In-Reply-To: <O3iuGgwFMGPK8WlS8gbejS2IiFX8e11kxUnyHi2pF0Q=.0079d6e5-5deb-4905-819d-30981669ebd5@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <0Ix-aiMznxsuePv7iSAqOId1aV2zTFOsW96OeD2D5cg=.fbd08430-b244-4170-8736-517ce84e08d4@github.com>
 <MowNm_yWhmNzkZQcZL0JWI1faIFqkwONVQA0qOSnq28=.75bf51db-2a3b-4ed3-b128-1d7e372fd449@github.com>
 <O3iuGgwFMGPK8WlS8gbejS2IiFX8e11kxUnyHi2pF0Q=.0079d6e5-5deb-4905-819d-30981669ebd5@github.com>
Message-ID: <uPi_MmsLlYv6nebfLTf6-UrpORqivbI_DQCIFbvjAe4=.2dc3dd56-13c5-4a79-85db-386d6bbf0d17@github.com>

On Sun, 1 Feb 2026 08:26:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> "Create sysroot" fails:
>> 
>> s390x:
>> 
>> 
>> Run sudo debootstrap --no-merged-usr --arch=s390x --verbose --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype-dev,libpng-dev --resolve-deps --variant=minbase bullseye sysroot https://httpredir.debian.org/debian/
>> W: Cannot check Release signature; keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg
>> I: Retrieving InRelease 
>> E: Invalid Release file, no entry for main/binary-s390x/Packages
>> Error: Process completed with exit code 1.
>> 
>> 
>> ppc64le:
>> 
>> 
>> Run sudo debootstrap --no-merged-usr --arch=ppc64el --verbose --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype-dev,libpng-dev --resolve-deps --variant=minbase bullseye sysroot https://httpredir.debian.org/debian/
>> W: Cannot check Release signature; keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg
>> I: Retrieving InRelease 
>> E: Invalid Release file, no entry for main/binary-ppc64el/Packages
>> Error: Process completed with exit code 1.
>
> @tats-u  The tests in test/jdk/java/nio/Buffer will need to be updated to add coverage for the new method. It's really important that the method is exercises with CharBuffer views that are backed by heap/direct buffers and char sequences.

@AlanBateman Fixed, but you might want to use from next time:

<img width="783" height="180" alt="image" src="https://github.com/user-attachments/assets/1c0c1498-93b2-44cb-a9f7-1356e573141f" />

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3830816082

From duke at openjdk.org  Sun Feb  1 10:31:07 2026
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 1 Feb 2026 10:31:07 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v11]
In-Reply-To: <O3iuGgwFMGPK8WlS8gbejS2IiFX8e11kxUnyHi2pF0Q=.0079d6e5-5deb-4905-819d-30981669ebd5@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <0Ix-aiMznxsuePv7iSAqOId1aV2zTFOsW96OeD2D5cg=.fbd08430-b244-4170-8736-517ce84e08d4@github.com>
 <MowNm_yWhmNzkZQcZL0JWI1faIFqkwONVQA0qOSnq28=.75bf51db-2a3b-4ed3-b128-1d7e372fd449@github.com>
 <O3iuGgwFMGPK8WlS8gbejS2IiFX8e11kxUnyHi2pF0Q=.0079d6e5-5deb-4905-819d-30981669ebd5@github.com>
Message-ID: <7DMT6Cy1trgRJjQCRCbQ0BfDdoatf6l1kLl8ph30onA=.04c311dd-08b8-4765-8181-8b567d878a2d@github.com>

On Sun, 1 Feb 2026 08:26:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> "Create sysroot" fails:
>> 
>> s390x:
>> 
>> 
>> Run sudo debootstrap --no-merged-usr --arch=s390x --verbose --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype-dev,libpng-dev --resolve-deps --variant=minbase bullseye sysroot https://httpredir.debian.org/debian/
>> W: Cannot check Release signature; keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg
>> I: Retrieving InRelease 
>> E: Invalid Release file, no entry for main/binary-s390x/Packages
>> Error: Process completed with exit code 1.
>> 
>> 
>> ppc64le:
>> 
>> 
>> Run sudo debootstrap --no-merged-usr --arch=ppc64el --verbose --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype-dev,libpng-dev --resolve-deps --variant=minbase bullseye sysroot https://httpredir.debian.org/debian/
>> W: Cannot check Release signature; keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg
>> I: Retrieving InRelease 
>> E: Invalid Release file, no entry for main/binary-ppc64el/Packages
>> Error: Process completed with exit code 1.
>
> @tats-u  The tests in test/jdk/java/nio/Buffer will need to be updated to add coverage for the new method. It's really important that the method is exercises with CharBuffer views that are backed by heap/direct buffers and char sequences.

@AlanBateman 

> The tests in test/jdk/java/nio/Buffer will need to be updated to add coverage for the new method. 

Do you know which files new tests should be added to? test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java?

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3830829293

From duke at openjdk.org  Sun Feb  1 11:00:41 2026
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 1 Feb 2026 11:00:41 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v22]
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <ZBnGNuyXuKhfV2ALBAIfRlOY2kOetTiPPjsJ6omxcj4=.d0095f7f-c96d-4a96-bf56-ab59e547263f@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 one additional commit since the last revision:

  Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26461/files
  - new: https://git.openjdk.org/jdk/pull/26461/files/43eb577a..b640e68d

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

  Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 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 alanb at openjdk.org  Sun Feb  1 11:06:03 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 1 Feb 2026 11:06:03 GMT
Subject: RFR: 8376760: VerifyJimage.java#compare intermittent failed with
 fastdebug [v3]
In-Reply-To: <GwOWYkJcdZDAhuNJUMV3UFtExG_tTCLE_rcxTz6fs98=.4be1697f-c896-4c49-b0b2-84fdb9773280@github.com>
References: <j360mZjyQnFn5YnxFiE75b-6WEbzQh0AHBDFRTmo6Zk=.fc329853-99bc-4867-bc81-d9ffa46ba386@github.com>
 <GwOWYkJcdZDAhuNJUMV3UFtExG_tTCLE_rcxTz6fs98=.4be1697f-c896-4c49-b0b2-84fdb9773280@github.com>
Message-ID: <n5eMSo6BGVCwEIwUyHthaXsrP4Mjji7VFf6VxN-oa2E=.a056766d-84fc-472c-ab3b-5132a45ea92b@github.com>

On Sun, 1 Feb 2026 10:19:51 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test tools/jimage/VerifyJimage.java#compare intermittent timed out with fastdebug build. I think it would be better to ajust the jtreg timeout factor(20*timeoutFactor) rather that set the fix timeout value(20) for awaitTermination.
>> 
>> The test run all passed 100 times simultaneously.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary import

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29498#pullrequestreview-3735546451

From jpai at openjdk.org  Sun Feb  1 11:40:05 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 1 Feb 2026 11:40:05 GMT
Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays [v6]
In-Reply-To: <1pITviq8ZBtVZGMpfBdyBMmnkLiBak5FrYaLLmKCWqE=.191c3dd6-66d5-48d9-a3cb-e0aa956504bb@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
 <1pITviq8ZBtVZGMpfBdyBMmnkLiBak5FrYaLLmKCWqE=.191c3dd6-66d5-48d9-a3cb-e0aa956504bb@github.com>
Message-ID: <Lrt29v6yRNN9tukPiiy1bpxRs3LMKpE4P0l6Exj6TXM=.e91fac99-95d1-4956-8f46-b8d916ff2627@github.com>

On Thu, 22 Jan 2026 21:54:35 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this.
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8370688: Updated the documentation to describe the behavior using @implSpec

Hello Koushik, although the changes are trivial and doc-only I'll let Sean sponsor this. In the meantime, please run a `make docs-image` with this change, if you haven't already. That should catch any unforeseen issues with the updated javadoc.

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

PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3830924862

From duke at openjdk.org  Sun Feb  1 12:32:59 2026
From: duke at openjdk.org (ExE Boss)
Date: Sun, 1 Feb 2026 12:32:59 GMT
Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API
In-Reply-To: <AhcxwqniFLpQJGXxkKW-FOgcTF_LnFA2b8n1uFuWd6M=.983c597e-f1f9-46c7-961f-e7a965a80829@github.com>
References: <AhcxwqniFLpQJGXxkKW-FOgcTF_LnFA2b8n1uFuWd6M=.983c597e-f1f9-46c7-961f-e7a965a80829@github.com>
Message-ID: <bw8vkaZDeLFkH8ePv-S0VQFnj4mDPjqoE2BT-8Hm4ek=.6f7884d9-84bd-4d9e-bd4d-f731588db87a@github.com>

On Fri, 30 Jan 2026 22:41:35 GMT, Chen Liang <liach at openjdk.org> wrote:

> Replace the legacy sun reflect generics tree API with the classfile signature model API. This allows us to maintain just one set of API for future signature changes like null restricted types. This should be less invasive than #19281.

As?I?said about?[GH?19281]:

> Since?[JDK?8368331] has?been fixed?now, this?PR should?probably be?linked to?[JDK?8351103] as?well.

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

@liach Simply?type the?following in?a?**GitHub**?comment to?do?so:



[GH?19281]: https://github.com/openjdk/jdk/pull/19281#issuecomment-3438779549
[JDK?8351103]: https://bugs.openjdk.org/browse/JDK-8351103 "[JDK?8351103] JVMS class?signature specification disagrees with?implementation"
[JDK?8368331]: https://bugs.openjdk.org/browse/JDK-8368331 "[JDK?8368331] ClassFile Signature parsing?fails for?type?parameter with?no?supertype"

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

PR Comment: https://git.openjdk.org/jdk/pull/29510#issuecomment-3830981716

From duke at openjdk.org  Sun Feb  1 12:55:29 2026
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 1 Feb 2026 12:55:29 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v23]
In-Reply-To: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@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 two additional commits since the last revision:

 - Add comment
 - Fix logic error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26461/files
  - new: https://git.openjdk.org/jdk/pull/26461/files/b640e68d..e7d33b94

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

  Stats: 8 lines in 2 files changed: 5 ins; 0 del; 3 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 liach at openjdk.org  Sun Feb  1 15:04:01 2026
From: liach at openjdk.org (Chen Liang)
Date: Sun, 1 Feb 2026 15:04:01 GMT
Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API
In-Reply-To: <AhcxwqniFLpQJGXxkKW-FOgcTF_LnFA2b8n1uFuWd6M=.983c597e-f1f9-46c7-961f-e7a965a80829@github.com>
References: <AhcxwqniFLpQJGXxkKW-FOgcTF_LnFA2b8n1uFuWd6M=.983c597e-f1f9-46c7-961f-e7a965a80829@github.com>
Message-ID: <PXnKBzbEufSapD2CID1VqMUK6EZSJc4AOjlu9SQvIvg=.738f6c7e-9901-4d1d-bb99-67cb534fcb67@github.com>

On Fri, 30 Jan 2026 22:41:35 GMT, Chen Liang <liach at openjdk.org> wrote:

> Replace the legacy sun reflect generics tree API with the classfile signature model API. This allows us to maintain just one set of API for future signature changes like null restricted types. This should be less invasive than #19281.

I think I will have a separate patch to add a test case for 8351103 instead of adding a test for that bug in this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/29510#issuecomment-3831165770

From duke at openjdk.org  Sun Feb  1 15:10:12 2026
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 1 Feb 2026 15:10:12 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v23]
In-Reply-To: <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
Message-ID: <p2xgMq8mjf89XqMk5tNeRIkbnqu1AFmN6VOosMaIfmM=.f47cf995-dfbd-42ad-876f-5f1eac53e7a5@github.com>

On Sun, 1 Feb 2026 12:55:29 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 two additional commits since the last revision:
> 
>  - Add comment
>  - Fix logic error

I don't know how to fix the offending "tools/javac/patterns/Exhaustiveness" error.

https://github.com/tats-u/jdk/actions/runs/21563196651#summary-62131220808

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3831173111

From liach at openjdk.org  Sun Feb  1 15:16:08 2026
From: liach at openjdk.org (Chen Liang)
Date: Sun, 1 Feb 2026 15:16:08 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v23]
In-Reply-To: <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
Message-ID: <axZRMryjC5iwd4j8uHC4gZZWZSg2e2ggtqxC7TetO1U=.d3df8bac-f11c-4d1b-a0c8-64b4139905c1@github.com>

On Sun, 1 Feb 2026 12:55:29 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 two additional commits since the last revision:
> 
>  - Add comment
>  - Fix logic error

Oh, it's just a timeout on some special build configuration. It is sometimes due to GitHub Actions machines being not powerful enough. You can safely ignore that.

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3831183326

From alanb at openjdk.org  Sun Feb  1 16:58:09 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 1 Feb 2026 16:58:09 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v11]
In-Reply-To: <7DMT6Cy1trgRJjQCRCbQ0BfDdoatf6l1kLl8ph30onA=.04c311dd-08b8-4765-8181-8b567d878a2d@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <0Ix-aiMznxsuePv7iSAqOId1aV2zTFOsW96OeD2D5cg=.fbd08430-b244-4170-8736-517ce84e08d4@github.com>
 <MowNm_yWhmNzkZQcZL0JWI1faIFqkwONVQA0qOSnq28=.75bf51db-2a3b-4ed3-b128-1d7e372fd449@github.com>
 <O3iuGgwFMGPK8WlS8gbejS2IiFX8e11kxUnyHi2pF0Q=.0079d6e5-5deb-4905-819d-30981669ebd5@github.com>
 <7DMT6Cy1trgRJjQCRCbQ0BfDdoatf6l1kLl8ph30onA=.04c311dd-08b8-4765-8181-8b567d878a2d@github.com>
Message-ID: <fPsUMUPoF_CPIpZ0HjsvJHgQH4brq8XUB_XwV69P9f8=.9b4e1108-92be-433d-a13a-575519522479@github.com>

On Sun, 1 Feb 2026 10:28:12 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> Do you know which files new tests should be added to? 

Look at Basic-X.java.template (need to run genBasic.sh to generate the tests when you change it).

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3831388783

From alanb at openjdk.org  Sun Feb  1 17:09:03 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 1 Feb 2026 17:09:03 GMT
Subject: RFR: 8376703: Some coding in libjimage seems to be not called at
 all or not called from PRODUCT code [v2]
In-Reply-To: <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
References: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
 <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
Message-ID: <CaVahBj2woLuZFlAPre6emeKWBnaBg6DNXl4UfQ8QDk=.026461ea-948b-4800-8ef1-03ae24ccd8f3@github.com>

On Fri, 30 Jan 2026 12:41:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> libjimage has a few unused functions/methods; those are listed when logging elimination with  -Wl,--gc-sections -Wl,--print-gc-sections .
>> We could remove them (or with if are still needed for completeness  put them into  #if 0 ) to reduce lib size on Linux and AIX.
>> On Windows and macOS it seems the compiler/linker default settings are good enough to eliminate the code.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust COPYRIGHT headers

@david-beaumont Can you verify that your upcoming changes to jimage do no depend on the functions that are removed here?

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

PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3831436860

From psandoz at openjdk.org  Sun Feb  1 17:11:11 2026
From: psandoz at openjdk.org (Paul Sandoz)
Date: Sun, 1 Feb 2026 17:11:11 GMT
Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass
 them to intrinsic entries [v4]
In-Reply-To: <GDwSxVuqx8MhrECnCnDKiUKNAjw8WiGhKqO4fj3zC_M=.8cf6b098-d621-43d4-8c70-7eacc140a2d4@github.com>
References: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
 <jl3TdydD4GH391dpmUMMJ52pbk7E3FsIc7DoKAA4d_4=.9c4b0f59-6892-45f9-a7c4-bb6553a66ef0@github.com>
 <-fsfUEvFpvmAsupQFgx1CBkH9vr_efE5-qYeUzy5VFQ=.4abb05e0-1f82-4d6c-8bc4-ca4bc6fc5e80@github.com>
 <GDwSxVuqx8MhrECnCnDKiUKNAjw8WiGhKqO4fj3zC_M=.8cf6b098-d621-43d4-8c70-7eacc140a2d4@github.com>
Message-ID: <G2It6uw3539yoWvyIgPYSXvpCZOw5ZKpKyPuWA9AIQI=.b1a58a0d-9995-4f3e-8b67-73f1d087e706@github.com>

On Sun, 1 Feb 2026 07:36:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractSpecies.java line 152:
>> 
>>> 150:     int laneTypeOrdinal() {
>>> 151:         return laneType.ordinal();
>>> 152:     }
>> 
>> Is this needed? Won't all concrete sub types override this?
>
> This interface provides access to lane type constant though species, its used for consistency, please have a look at following line and other places around it.
> https://github.com/jatin-bhateja/jdk/blob/ff73dc3d48a9435c4395556c8325fbce7610cba9/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java#L3374

Agreed that this method is required, but i was wondering why `AbstractSpecies` need to implement it. Ok, i see now you are copying the same pattern as some other methods such as `elementType`, so this is a more general issue we should not resolve in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2751614740

From psandoz at openjdk.org  Sun Feb  1 17:15:09 2026
From: psandoz at openjdk.org (Paul Sandoz)
Date: Sun, 1 Feb 2026 17:15:09 GMT
Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass
 them to intrinsic entries [v5]
In-Reply-To: <HDJ2eVePQDTb_IwIowCiEgYouhAbGZdRnyUkHIUWTKM=.4ee6f8f0-8305-4de2-adb4-74f3886b6aa5@github.com>
References: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
 <HDJ2eVePQDTb_IwIowCiEgYouhAbGZdRnyUkHIUWTKM=.4ee6f8f0-8305-4de2-adb4-74f3886b6aa5@github.com>
Message-ID: <UWVjPfyP-1pho_uiUoLORRpTJna5X3FOM3Z0JSqR0Q4=.cac7cd2f-3dba-476b-a377-a45615ab05a7@github.com>

On Sun, 1 Feb 2026 07:41:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support.
>> 
>> Patch add new lane type constants and pass them to vector intrinsic entry points.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolution

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 580:

> 578:     public static ByteVector zero(VectorSpecies<Byte> species) {
> 579:         ByteSpecies vsp = (ByteSpecies) species;
> 580:         return VectorSupport.fromBitsCoerced(vsp.vectorType(), vsp.laneTypeOrdinal(), species.length(),

You can now use `LANE_TYPE_ORDINAL` rather than `vsp.laneTypeOrdinal()`, which better fits the prior pattern.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2751629721

From shade at openjdk.org  Mon Feb  2 07:45:03 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Feb 2026 07:45:03 GMT
Subject: RFR: 8376355: Update to use jtreg 8.2.1
In-Reply-To: <dyYpHQfiCIDTwVouMHgEd7tIH2ZODtzHHmbkvi0gNF8=.1471e4d3-d4b0-4117-9257-c929480a59e0@github.com>
References: <dyYpHQfiCIDTwVouMHgEd7tIH2ZODtzHHmbkvi0gNF8=.1471e4d3-d4b0-4117-9257-c929480a59e0@github.com>
Message-ID: <EVYNFQU-7ISvX5Pq3Z-s772BaYmiW6W02_eW3y4B_dk=.36312348-2e66-4ff2-9bb1-4b71ed37ee31@github.com>

On Tue, 27 Jan 2026 15:26:20 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.2.1.
> 
> 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.

Nice to see no actual test changes are required for compatibility.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29452#pullrequestreview-3737777336

From xgong at openjdk.org  Mon Feb  2 08:24:31 2026
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 2 Feb 2026 08:24:31 GMT
Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in
 specific patterns [v9]
In-Reply-To: <aGK8--tkPgEyCGoZqg_IPeWle3AAJJ2bmu5l-lKWjOo=.4ad97f35-ec82-48ed-894e-4a6b3b0e8de3@github.com>
References: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
 <aGK8--tkPgEyCGoZqg_IPeWle3AAJJ2bmu5l-lKWjOo=.4ad97f35-ec82-48ed-894e-4a6b3b0e8de3@github.com>
Message-ID: <5wyJTVhxYseRXupCPZgKZc5d41SzaKs02yaaj35dK64=.9c435acd-5606-4ed1-b3ff-36026d6578d5@github.com>

On Wed, 28 Jan 2026 01:49:52 GMT, Eric Fang <erfang at openjdk.org> wrote:

>> `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common.
>> 
>> If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example:
>> 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)`
>> 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`.
>> 
>> In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast.
>> 
>> The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`.
>> 
>> The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain.
>> 
>> Current optimizations related to `VectorMaskCastNode` include:
>> 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760.
>> 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242.
>> 
>> This PR does the following optimizations:
>> 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct.
>> 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vect...
>
> Eric Fang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add clearer comments to VectorMaskCastIdentityTest.java

test/hotspot/jtreg/compiler/vectorapi/VectorStoreMaskIdentityTest.java line 288:

> 286:     @IR(counts = { IRNode.VECTOR_LOAD_MASK, "= 0",
> 287:                    IRNode.VECTOR_STORE_MASK, "= 0",
> 288:                    IRNode.VECTOR_MASK_CAST, "= 0" },

Can we also check `IRNode.LOAD_VECTOR` to make sure these APIs are intrinsified successfully, and the nodes are eliminated by `VectorStoreMask::Identity()` ? Because if these APIs are not intrinsified due to some reasons, above IRs do not exist as well.

test/hotspot/jtreg/compiler/vectorapi/VectorStoreMaskIdentityTest.java line 289:

> 287:                    IRNode.VECTOR_STORE_MASK, "= 0",
> 288:                    IRNode.VECTOR_MASK_CAST, "= 0" },
> 289:         applyIfCPUFeatureOr = { "asimd", "true", "avx2", "true" },

This might not affect the result because it has `applyIf = { "MaxVectorSize", "> 16" }` check additionally. But it will more accurate if:
Suggestion:

        applyIfCPUFeatureOr = { "sve", "true", "avx2", "true" },

because the max vector size for neon is 16-byte.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2753114650
PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2753117731

From erfang at openjdk.org  Mon Feb  2 08:48:27 2026
From: erfang at openjdk.org (Eric Fang)
Date: Mon, 2 Feb 2026 08:48:27 GMT
Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in
 specific patterns [v9]
In-Reply-To: <5wyJTVhxYseRXupCPZgKZc5d41SzaKs02yaaj35dK64=.9c435acd-5606-4ed1-b3ff-36026d6578d5@github.com>
References: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
 <aGK8--tkPgEyCGoZqg_IPeWle3AAJJ2bmu5l-lKWjOo=.4ad97f35-ec82-48ed-894e-4a6b3b0e8de3@github.com>
 <5wyJTVhxYseRXupCPZgKZc5d41SzaKs02yaaj35dK64=.9c435acd-5606-4ed1-b3ff-36026d6578d5@github.com>
Message-ID: <eLGcFm9-YdhqmCj2mvgg682rftMSy-UMtwK2JHktWcI=.8a915b49-40cc-4d4f-b848-f2474525106c@github.com>

On Mon, 2 Feb 2026 08:17:51 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Eric Fang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add clearer comments to VectorMaskCastIdentityTest.java
>
> test/hotspot/jtreg/compiler/vectorapi/VectorStoreMaskIdentityTest.java line 288:
> 
>> 286:     @IR(counts = { IRNode.VECTOR_LOAD_MASK, "= 0",
>> 287:                    IRNode.VECTOR_STORE_MASK, "= 0",
>> 288:                    IRNode.VECTOR_MASK_CAST, "= 0" },
> 
> Can we also check `IRNode.LOAD_VECTOR` to make sure these APIs are intrinsified successfully, and the nodes are eliminated by `VectorStoreMask::Identity()` ? Because if these APIs are not intrinsified due to some reasons, above IRs do not exist as well.

Yeah I agree that if this api is not intrinsified, the expected IRs will not be generated either. I can add this IR check; it's trival, but:

The reason I didn't check this IR before was because I thought it was a separate issue. We should write separate tests to check under what circumstances the relevant APIs are or aren't intrinsified.

A large portion of the Vector API involves the `LoadVector` IR. If we need to check whether the called Vector API is successfully intrinsified for these kinds of optimizations, then our IR check chain will become longer and longer.

WDYT?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2753221382

From xgong at openjdk.org  Mon Feb  2 09:00:23 2026
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 2 Feb 2026 09:00:23 GMT
Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for
 unsigned min/max reduction operations [v3]
In-Reply-To: <0Sb85mfgAvhtvGsNtdZvcwvaaOYvfDyTS-2TmnRW95Q=.6a523d10-6f54-4af0-b7f9-bef49e995fa3@github.com>
References: <Q2wrStWVzJWL-6b6lxC3eCQv465aVRUdX5Kr95rT5bE=.38082a7b-70c9-4731-8d80-a8927b87f435@github.com>
 <J6FZPXNCUK89hPl0uA37LR6_p9MiZd3uIDyB9doxUNY=.752a8545-19a7-4e09-a694-612a27b7605d@github.com>
 <0Sb85mfgAvhtvGsNtdZvcwvaaOYvfDyTS-2TmnRW95Q=.6a523d10-6f54-4af0-b7f9-bef49e995fa3@github.com>
Message-ID: <tw3LC8sFxaw9dbUENSwrORv-1CtpRkeSUkAI66wqUXo=.9784c30c-824a-4ead-8b77-4ef0845d114e@github.com>

On Thu, 22 Jan 2026 17:27:58 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Eric Fang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Extract some helper functions for better readability
>
> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp line 50:
> 
>> 48:   void sve_maxv(bool is_unsigned, FloatRegister dst, SIMD_RegVariant size,
>> 49:                 PRegister pg, FloatRegister src);
>> 50: 
> 
> Using separate definitions here is adding unnecessary complexity.
> 
> I'd do something like this in the header file:
> 
> 
>   // Typedefs used to disambiguate overloaded member functions.
>   typedef void (Assembler::*neon_reduction2)
>     (FloatRegister, Assembler::SIMD_Arrangement, FloatRegister);
>   typedef void (Assembler::*sve_reduction3)
>     (FloatRegister, Assembler::SIMD_RegVariant, PRegister, FloatRegister);
> 
>   // Helper functions for min/max reduction operations
>   void neon_minp(bool is_unsigned, FloatRegister dst, SIMD_Arrangement size,
>                  FloatRegister src1, FloatRegister src2) {
>     auto m = is_unsigned ? &Assembler::uminp : &Assembler::sminp;
>     (this->*m)(dst, size, src1, src2);
>   }
>   void neon_maxp(bool is_unsigned, FloatRegister dst, SIMD_Arrangement size,
>                    FloatRegister src1, FloatRegister src2) {
>     auto m = is_unsigned ? &Assembler::umaxp : &Assembler::smaxp;
>     (this->*m)(dst, size, src1, src2);
>   }
>   void neon_minv(bool is_unsigned, FloatRegister dst, SIMD_Arrangement size,
>                  FloatRegister src) {
>     auto m = is_unsigned ? (neon_reduction2)&Assembler::uminv : &Assembler::sminv;
>     (this->*m)(dst, size, src);
>   }
>   void neon_maxv(bool is_unsigned, FloatRegister dst, SIMD_Arrangement size,
>                  FloatRegister src) {
>     auto m = is_unsigned ? (neon_reduction2)&Assembler::umaxv : &Assembler::smaxv;
>     (this->*m)(dst, size, src);
>   }
>   void sve_minv(bool is_unsigned, FloatRegister dst, SIMD_RegVariant size,
>                 PRegister pg, FloatRegister src) {
>     auto m = is_unsigned ? (sve_reduction3)&Assembler::sve_uminv : &Assembler::sve_sminv;
>     (this->*m)(dst, size, pg, src);
>   }
>   void sve_maxv(bool is_unsigned, FloatRegister dst, SIMD_RegVariant size,
>                 PRegister pg, FloatRegister src) {
>     auto m = is_unsigned ? (sve_reduction3)&Assembler::sve_umaxv : &Assembler::sve_smaxv;
>     (this->*m)(dst, size, pg, src);
>   }
> 
> 
> 
> To some extent it's a matter of taste, but please try not to use much more repetitive and boilerplate code than you need to.

I?m not sure, but would the code below be better? It might make the macro assembler a bit tidier.

  void neon_minmaxp(bool is_unsigned, bool is_max, FloatRegister dst,
                    SIMD_Arrangement size, FloatRegister src1, FloatRegister src2) {
    auto m = is_unsigned ? (is_max ? &Assembler::umaxp : &Assembler::uminp)
                         : (is_max ? &Assembler::smaxp : &Assembler::sminp);
    (this->*m)(dst, size, src1, src2);
  }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28693#discussion_r2753257260

From xgong at openjdk.org  Mon Feb  2 09:04:32 2026
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 2 Feb 2026 09:04:32 GMT
Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in
 specific patterns [v9]
In-Reply-To: <eLGcFm9-YdhqmCj2mvgg682rftMSy-UMtwK2JHktWcI=.8a915b49-40cc-4d4f-b848-f2474525106c@github.com>
References: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
 <aGK8--tkPgEyCGoZqg_IPeWle3AAJJ2bmu5l-lKWjOo=.4ad97f35-ec82-48ed-894e-4a6b3b0e8de3@github.com>
 <5wyJTVhxYseRXupCPZgKZc5d41SzaKs02yaaj35dK64=.9c435acd-5606-4ed1-b3ff-36026d6578d5@github.com>
 <eLGcFm9-YdhqmCj2mvgg682rftMSy-UMtwK2JHktWcI=.8a915b49-40cc-4d4f-b848-f2474525106c@github.com>
Message-ID: <Frc_HNVme9c_slkh-9i5pDc_efC1EqkB4BB24nyGJjA=.5da92890-5bae-4edf-8557-e0a5143569e5@github.com>

On Mon, 2 Feb 2026 08:45:53 GMT, Eric Fang <erfang at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/vectorapi/VectorStoreMaskIdentityTest.java line 288:
>> 
>>> 286:     @IR(counts = { IRNode.VECTOR_LOAD_MASK, "= 0",
>>> 287:                    IRNode.VECTOR_STORE_MASK, "= 0",
>>> 288:                    IRNode.VECTOR_MASK_CAST, "= 0" },
>> 
>> Can we also check `IRNode.LOAD_VECTOR` to make sure these APIs are intrinsified successfully, and the nodes are eliminated by `VectorStoreMask::Identity()` ? Because if these APIs are not intrinsified due to some reasons, above IRs do not exist as well.
>
> Yeah I agree that if this api is not intrinsified, the expected IRs will not be generated either. I can add this IR check; it's trival, but:
> 
> The reason I didn't check this IR before was because I thought it was a separate issue. We should write separate tests to check under what circumstances the relevant APIs are or aren't intrinsified.
> 
> A large portion of the Vector API involves the `LoadVector` IR. If we need to check whether the called Vector API is successfully intrinsified for these kinds of optimizations, then our IR check chain will become longer and longer.
> 
> WDYT?

The main concern/difference is that all the vector IRs are zero count here. I'd like to guarantee that the optimizations do take effects without any regressions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2753284295

From jbhateja at openjdk.org  Mon Feb  2 09:07:21 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 2 Feb 2026 09:07:21 GMT
Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass
 them to intrinsic entries [v6]
In-Reply-To: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
References: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
Message-ID: <k118UMK3mVVIMcluzGrC-ZpVT0sYBhSKtgFhQlzGCjE=.2d61f6e0-e2d0-4906-8331-d27dc312a865@github.com>

> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support.
> 
> Patch add new lane type constants and pass them to vector intrinsic entry points.
> 
> All existing Vector API jtreg test are passing with the patch.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

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

  Review comment resolution

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29481/files
  - new: https://git.openjdk.org/jdk/pull/29481/files/0c60016b..23022d42

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

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

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

From jbhateja at openjdk.org  Mon Feb  2 09:07:23 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 2 Feb 2026 09:07:23 GMT
Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass
 them to intrinsic entries [v5]
In-Reply-To: <UWVjPfyP-1pho_uiUoLORRpTJna5X3FOM3Z0JSqR0Q4=.cac7cd2f-3dba-476b-a377-a45615ab05a7@github.com>
References: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
 <HDJ2eVePQDTb_IwIowCiEgYouhAbGZdRnyUkHIUWTKM=.4ee6f8f0-8305-4de2-adb4-74f3886b6aa5@github.com>
 <UWVjPfyP-1pho_uiUoLORRpTJna5X3FOM3Z0JSqR0Q4=.cac7cd2f-3dba-476b-a377-a45615ab05a7@github.com>
Message-ID: <JwKSh-dHG6o6GUgHVpZRrmhhyWp_ON_0Dips728--iw=.e9b98223-ae12-40e3-9704-a318fd8a7ac9@github.com>

On Sun, 1 Feb 2026 17:12:49 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolution
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 580:
> 
>> 578:     public static ByteVector zero(VectorSpecies<Byte> species) {
>> 579:         ByteSpecies vsp = (ByteSpecies) species;
>> 580:         return VectorSupport.fromBitsCoerced(vsp.vectorType(), vsp.laneTypeOrdinal(), species.length(),
> 
> You can now use `LANE_TYPE_ORDINAL` rather than `vsp.laneTypeOrdinal()`, which better fits the prior pattern.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2753281411

From aph at openjdk.org  Mon Feb  2 09:11:58 2026
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 2 Feb 2026 09:11:58 GMT
Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for
 unsigned min/max reduction operations [v3]
In-Reply-To: <tw3LC8sFxaw9dbUENSwrORv-1CtpRkeSUkAI66wqUXo=.9784c30c-824a-4ead-8b77-4ef0845d114e@github.com>
References: <Q2wrStWVzJWL-6b6lxC3eCQv465aVRUdX5Kr95rT5bE=.38082a7b-70c9-4731-8d80-a8927b87f435@github.com>
 <J6FZPXNCUK89hPl0uA37LR6_p9MiZd3uIDyB9doxUNY=.752a8545-19a7-4e09-a694-612a27b7605d@github.com>
 <0Sb85mfgAvhtvGsNtdZvcwvaaOYvfDyTS-2TmnRW95Q=.6a523d10-6f54-4af0-b7f9-bef49e995fa3@github.com>
 <tw3LC8sFxaw9dbUENSwrORv-1CtpRkeSUkAI66wqUXo=.9784c30c-824a-4ead-8b77-4ef0845d114e@github.com>
Message-ID: <IqSiCpOXZDLUzX9D7ek52jdNE5wXT3sU95fv12MfVJ4=.e2797c55-0bd0-4c8d-8635-47819dc669b7@github.com>

On Mon, 2 Feb 2026 08:55:45 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp line 50:
>> 
>>> 48:   void sve_maxv(bool is_unsigned, FloatRegister dst, SIMD_RegVariant size,
>>> 49:                 PRegister pg, FloatRegister src);
>>> 50: 
>> 
>> Using separate definitions here is adding unnecessary complexity.
>> 
>> I'd do something like this in the header file:
>> 
>> 
>>   // Typedefs used to disambiguate overloaded member functions.
>>   typedef void (Assembler::*neon_reduction2)
>>     (FloatRegister, Assembler::SIMD_Arrangement, FloatRegister);
>>   typedef void (Assembler::*sve_reduction3)
>>     (FloatRegister, Assembler::SIMD_RegVariant, PRegister, FloatRegister);
>> 
>>   // Helper functions for min/max reduction operations
>>   void neon_minp(bool is_unsigned, FloatRegister dst, SIMD_Arrangement size,
>>                  FloatRegister src1, FloatRegister src2) {
>>     auto m = is_unsigned ? &Assembler::uminp : &Assembler::sminp;
>>     (this->*m)(dst, size, src1, src2);
>>   }
>>   void neon_maxp(bool is_unsigned, FloatRegister dst, SIMD_Arrangement size,
>>                    FloatRegister src1, FloatRegister src2) {
>>     auto m = is_unsigned ? &Assembler::umaxp : &Assembler::smaxp;
>>     (this->*m)(dst, size, src1, src2);
>>   }
>>   void neon_minv(bool is_unsigned, FloatRegister dst, SIMD_Arrangement size,
>>                  FloatRegister src) {
>>     auto m = is_unsigned ? (neon_reduction2)&Assembler::uminv : &Assembler::sminv;
>>     (this->*m)(dst, size, src);
>>   }
>>   void neon_maxv(bool is_unsigned, FloatRegister dst, SIMD_Arrangement size,
>>                  FloatRegister src) {
>>     auto m = is_unsigned ? (neon_reduction2)&Assembler::umaxv : &Assembler::smaxv;
>>     (this->*m)(dst, size, src);
>>   }
>>   void sve_minv(bool is_unsigned, FloatRegister dst, SIMD_RegVariant size,
>>                 PRegister pg, FloatRegister src) {
>>     auto m = is_unsigned ? (sve_reduction3)&Assembler::sve_uminv : &Assembler::sve_sminv;
>>     (this->*m)(dst, size, pg, src);
>>   }
>>   void sve_maxv(bool is_unsigned, FloatRegister dst, SIMD_RegVariant size,
>>                 PRegister pg, FloatRegister src) {
>>     auto m = is_unsigned ? (sve_reduction3)&Assembler::sve_umaxv : &Assembler::sve_smaxv;
>>     (this->*m)(dst, size, pg, src);
>>   }
>> 
>> 
>> 
>> To some extent it's a matter of taste, but please try not to use much more repetitive and boilerplate code than you need to.
>
> I?m not sure, but would the code below be better? It might make the macro assembler a bit tidier.
> 
>   void neon_minmaxp(bool is_unsigned, bool is_max, FloatRegister dst,
>                     SIMD_Arrangement size, FloatRegister src1, FloatRegister src2) {
>     auto m = is_unsigned ? (is_max ? &Assembler::umaxp : &Assembler::uminp)
>                          : (is_max ? &Assembler::smaxp : &Assembler::sminp);
>     (this->*m)(dst, size, src1, src2);
>   }

Sure, that's good.

This is exactly the kind of thing we need to keep the code as small and simple as possible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28693#discussion_r2753309806

From dfenacci at openjdk.org  Mon Feb  2 09:31:40 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 2 Feb 2026 09:31:40 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v9]
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <XHY_1jA3Lkfoi7PviI7qzCeyKzvU_YYiEZWcAdiaROc=.cb8b57b6-9ebc-4cb6-9aca-418531b4fc58@github.com>

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8374582' of https://github.com/dafedafe/jdk into JDK-8374582
 - JDK-8374582: add assert in opaque constructor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29164/files
  - new: https://git.openjdk.org/jdk/pull/29164/files/c5390e4a..5e7df6f4

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

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

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

From dfenacci at openjdk.org  Mon Feb  2 09:55:37 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 2 Feb 2026 09:55:37 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v10]
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <iZvhI3BfgpXasgO7gcp4JDKeu2orh2L7EOHioaQkdcM=.3f1d5178-0492-4eff-83f3-7cb7516954bb@github.com>

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

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

  JDK-8374582: revert wrong copyright change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29164/files
  - new: https://git.openjdk.org/jdk/pull/29164/files/5e7df6f4..5ac3e6e3

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

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

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

From duke at openjdk.org  Mon Feb  2 10:56:50 2026
From: duke at openjdk.org (David Beaumont)
Date: Mon, 2 Feb 2026 10:56:50 GMT
Subject: RFR: 8376703: Some coding in libjimage seems to be not called at
 all or not called from PRODUCT code [v2]
In-Reply-To: <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
References: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
 <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
Message-ID: <1Cq67E6TRRmlrAgIqTbKoOSzHB2owQSMMFzzqThcGPY=.c2a078ad-fd02-4a49-a389-e4df07ed5681@github.com>

On Fri, 30 Jan 2026 12:41:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> libjimage has a few unused functions/methods; those are listed when logging elimination with  -Wl,--gc-sections -Wl,--print-gc-sections .
>> We could remove them (or with if are still needed for completeness  put them into  #if 0 ) to reduce lib size on Linux and AIX.
>> On Windows and macOS it seems the compiler/linker default settings are good enough to eliminate the code.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust COPYRIGHT headers

Hi Matthias,
  As luck would have it I'm also about to make some substantive changes to this code (based on Valhalla work).
These changes also remove most of the same dead-code you've identified, but I'd need to check that your work doesn't muddle my integration (see draft PR at):

https://github.com/openjdk/jdk/pull/29414/changes#diff-aa601f760164d2f192a65e314d0c29224d4e812f492094aeb4fbc8be95d0b853

I'm happy to roll in any additional dead code you've identified into my PR if that makes things easier.

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

PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3834397108

From mbaesken at openjdk.org  Mon Feb  2 11:14:47 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 2 Feb 2026 11:14:47 GMT
Subject: RFR: 8376703: Some coding in libjimage seems to be not called at
 all or not called from PRODUCT code [v2]
In-Reply-To: <1Cq67E6TRRmlrAgIqTbKoOSzHB2owQSMMFzzqThcGPY=.c2a078ad-fd02-4a49-a389-e4df07ed5681@github.com>
References: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
 <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
 <1Cq67E6TRRmlrAgIqTbKoOSzHB2owQSMMFzzqThcGPY=.c2a078ad-fd02-4a49-a389-e4df07ed5681@github.com>
Message-ID: <OYVb7w89TqAoFeP4VhDAtRQLhmqFLTdXuBgBCavqDdo=.3e3d9f0f-18c6-4b2a-9158-a57524b46125@github.com>

On Mon, 2 Feb 2026 10:53:40 GMT, David Beaumont <duke at openjdk.org> wrote:

> I'm happy to roll in any additional dead code you've identified into my PR if that makes things easier.

I think this makes sense. So please compare your PR with what I removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3834488249

From duke at openjdk.org  Mon Feb  2 11:14:47 2026
From: duke at openjdk.org (David Beaumont)
Date: Mon, 2 Feb 2026 11:14:47 GMT
Subject: RFR: 8376760: VerifyJimage.java#compare intermittent failed with
 fastdebug [v3]
In-Reply-To: <GwOWYkJcdZDAhuNJUMV3UFtExG_tTCLE_rcxTz6fs98=.4be1697f-c896-4c49-b0b2-84fdb9773280@github.com>
References: <j360mZjyQnFn5YnxFiE75b-6WEbzQh0AHBDFRTmo6Zk=.fc329853-99bc-4867-bc81-d9ffa46ba386@github.com>
 <GwOWYkJcdZDAhuNJUMV3UFtExG_tTCLE_rcxTz6fs98=.4be1697f-c896-4c49-b0b2-84fdb9773280@github.com>
Message-ID: <VKxYiVWcWNUjEFkPvadCqMVVfAwY7UmG-kLXVEo9o6A=.90c77193-e0e6-4212-94cd-2d214a2b8145@github.com>

On Sun, 1 Feb 2026 10:19:51 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test tools/jimage/VerifyJimage.java#compare intermittent timed out with fastdebug build. I think it would be better to ajust the jtreg timeout factor(20*timeoutFactor) rather that set the fix timeout value(20) for awaitTermination.
>> 
>> The test run all passed 100 times simultaneously.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary import

Looks good, thanks for simplifying.
I'm assuming the fix has been verified as fixing the observable issue.

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

Marked as reviewed by david-beaumont at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/29498#pullrequestreview-3738767908

From thartmann at openjdk.org  Mon Feb  2 11:40:03 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 2 Feb 2026 11:40:03 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v10]
In-Reply-To: <iZvhI3BfgpXasgO7gcp4JDKeu2orh2L7EOHioaQkdcM=.3f1d5178-0492-4eff-83f3-7cb7516954bb@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <iZvhI3BfgpXasgO7gcp4JDKeu2orh2L7EOHioaQkdcM=.3f1d5178-0492-4eff-83f3-7cb7516954bb@github.com>
Message-ID: <EO0Ag3bbiaPYiLImA_wtxHWk62bDYqyCNWXdKdHPsM4=.4e386436-98b9-4e4e-92c6-82f016390e1f@github.com>

On Mon, 2 Feb 2026 09:55:37 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> ## Issue
>> 
>> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
>> 
>> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
>> 
>> ## Causes
>> 
>> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
>> 
>> ## Fix
>> 
>> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
>> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
>> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
>> 
>> # Testing
>> 
>> * Tier 1-3+
>> * 2 JTReg tests added
>>   * `TestRangeCheck.java` as regression test for the reported issue
>>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8374582: revert wrong copyright change

Thanks for working on this Damon. I added a few comments, otherwise it looks good!

src/hotspot/share/opto/library_call.cpp line 894:

> 892: 
> 893: inline Node* LibraryCallKit::generate_negative_guard(Node* index, RegionNode* region,
> 894:                                                      Node** pos_index, bool is_opaque) {

As we discussed offline, I think `with_opaque` is better here.

src/hotspot/share/opto/opaquenode.hpp line 145:

> 143: // with false in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 144: // In debug builds, we keep the actual checks as additional verification code (i.e. removing OpaqueConstantBoolNodes and
> 145: // use the BoolNode inputs instead).

Nice comment!

src/hotspot/share/opto/opaquenode.hpp line 148:

> 146: class OpaqueConstantBoolNode : public Node {
> 147:  private:
> 148:   bool _constant;

Should this be `const`?

src/hotspot/share/opto/opaquenode.hpp line 150:

> 148:   bool _constant;
> 149:  public:
> 150:   OpaqueConstantBoolNode(Compile* C, Node* tst, bool constant) : Node(nullptr, tst), _constant(constant) {

An alternative would be to have the `constant` be an actual input node instead of a field. In macro expansion, you could then do `_igvn.replace_node(n, n->in(2));` instead (maybe define an enum for the input indices). I don't have a strong opinion on this though and leave it up to you to decide ?

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3738450475
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2753636949
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2753548067
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2753551976
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2753586409

From dfenacci at openjdk.org  Mon Feb  2 12:01:51 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 2 Feb 2026 12:01:51 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v11]
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <SYNvAd9bK1WOrvH-jV6TmwWGy2QiwvKqmCLBhjjhWIw=.08ac1fbd-9392-47bf-b3d1-3a50787a3902@github.com>

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision:

 - JDK-8374582: add const
 - JDK-8374582: with_opaque

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29164/files
  - new: https://git.openjdk.org/jdk/pull/29164/files/5ac3e6e3..0d4eef88

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

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

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

From dfenacci at openjdk.org  Mon Feb  2 12:13:36 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 2 Feb 2026 12:13:36 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v10]
In-Reply-To: <EO0Ag3bbiaPYiLImA_wtxHWk62bDYqyCNWXdKdHPsM4=.4e386436-98b9-4e4e-92c6-82f016390e1f@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <iZvhI3BfgpXasgO7gcp4JDKeu2orh2L7EOHioaQkdcM=.3f1d5178-0492-4eff-83f3-7cb7516954bb@github.com>
 <EO0Ag3bbiaPYiLImA_wtxHWk62bDYqyCNWXdKdHPsM4=.4e386436-98b9-4e4e-92c6-82f016390e1f@github.com>
Message-ID: <imlEoHvlrVgBuwT0cVHZXI9sq1foraqTPr9n_ZftA0o=.35bdbc84-0213-474c-abea-cf72cbf16155@github.com>

On Mon, 2 Feb 2026 10:29:20 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8374582: revert wrong copyright change
>
> src/hotspot/share/opto/library_call.cpp line 894:
> 
>> 892: 
>> 893: inline Node* LibraryCallKit::generate_negative_guard(Node* index, RegionNode* region,
>> 894:                                                      Node** pos_index, bool is_opaque) {
> 
> As we discussed offline, I think `with_opaque` is better here.

Renamed. Thanks @TobiHartmann.

> src/hotspot/share/opto/opaquenode.hpp line 148:
> 
>> 146: class OpaqueConstantBoolNode : public Node {
>> 147:  private:
>> 148:   bool _constant;
> 
> Should this be `const`?

Yep, fixed.

> src/hotspot/share/opto/opaquenode.hpp line 150:
> 
>> 148:   bool _constant;
>> 149:  public:
>> 150:   OpaqueConstantBoolNode(Compile* C, Node* tst, bool constant) : Node(nullptr, tst), _constant(constant) {
> 
> An alternative would be to have the `constant` be an actual input node instead of a field. In macro expansion, you could then do `_igvn.replace_node(n, n->in(2));` instead (maybe define an enum for the input indices). I don't have a strong opinion on this though and leave it up to you to decide ?

Cool trick! ?... but now I can't decide between the two ? @chhagedorn do you fancy being the tiebreaker?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2754030906
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2754030537
PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2754032138

From chagedorn at openjdk.org  Mon Feb  2 13:28:57 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 2 Feb 2026 13:28:57 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v10]
In-Reply-To: <imlEoHvlrVgBuwT0cVHZXI9sq1foraqTPr9n_ZftA0o=.35bdbc84-0213-474c-abea-cf72cbf16155@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <iZvhI3BfgpXasgO7gcp4JDKeu2orh2L7EOHioaQkdcM=.3f1d5178-0492-4eff-83f3-7cb7516954bb@github.com>
 <EO0Ag3bbiaPYiLImA_wtxHWk62bDYqyCNWXdKdHPsM4=.4e386436-98b9-4e4e-92c6-82f016390e1f@github.com>
 <imlEoHvlrVgBuwT0cVHZXI9sq1foraqTPr9n_ZftA0o=.35bdbc84-0213-474c-abea-cf72cbf16155@github.com>
Message-ID: <p1CTwrxY457-B_lhYXpCVgsPkphZvaELerYm4dEM5x8=.d229fbf3-9f3b-4901-94ec-d50d382f3d0a@github.com>

On Mon, 2 Feb 2026 12:10:48 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> src/hotspot/share/opto/opaquenode.hpp line 150:
>> 
>>> 148:   bool _constant;
>>> 149:  public:
>>> 150:   OpaqueConstantBoolNode(Compile* C, Node* tst, bool constant) : Node(nullptr, tst), _constant(constant) {
>> 
>> An alternative would be to have the `constant` be an actual input node instead of a field. In macro expansion, you could then do `_igvn.replace_node(n, n->in(2));` instead (maybe define an enum for the input indices). I don't have a strong opinion on this though and leave it up to you to decide ?
>
> Cool trick! ?... but now I can't decide between the two ? @chhagedorn do you fancy being the tiebreaker?

The old `Opaque4` nodes used to have two data inputs where the second one was the replacement. I found it a little harder to view graphs in IGV with one more input. You also do not need to worry about trying to understand what the second input means. So, I would rather have a field if I may break the tie but both options are fine :-)

When going with a field, you could add a

NOT_PRODUCT(void dump_spec(outputStream* st) const);

that prints `#true` or `#false` depending on `_constant` (that could also then be shown in IGV with the "Show custom node info").

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2754324868

From dfenacci at openjdk.org  Mon Feb  2 14:03:00 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 2 Feb 2026 14:03:00 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v12]
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <2_bA8sRgRlbc279Aia0oD9gPBn8bcD5kLP3RnA4Xl4Q=.deaeaaf0-27a1-40f8-81f3-c8283c4d9529@github.com>

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision:

 - JDK-8374582: remove empty line
 - JDK-8374582: add constant dump

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29164/files
  - new: https://git.openjdk.org/jdk/pull/29164/files/0d4eef88..44b68dbc

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

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

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

From dfenacci at openjdk.org  Mon Feb  2 14:05:43 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 2 Feb 2026 14:05:43 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v10]
In-Reply-To: <p1CTwrxY457-B_lhYXpCVgsPkphZvaELerYm4dEM5x8=.d229fbf3-9f3b-4901-94ec-d50d382f3d0a@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <iZvhI3BfgpXasgO7gcp4JDKeu2orh2L7EOHioaQkdcM=.3f1d5178-0492-4eff-83f3-7cb7516954bb@github.com>
 <EO0Ag3bbiaPYiLImA_wtxHWk62bDYqyCNWXdKdHPsM4=.4e386436-98b9-4e4e-92c6-82f016390e1f@github.com>
 <imlEoHvlrVgBuwT0cVHZXI9sq1foraqTPr9n_ZftA0o=.35bdbc84-0213-474c-abea-cf72cbf16155@github.com>
 <p1CTwrxY457-B_lhYXpCVgsPkphZvaELerYm4dEM5x8=.d229fbf3-9f3b-4901-94ec-d50d382f3d0a@github.com>
Message-ID: <9TRsuJgH4W8hsmU02_3jXvLwPotWWdihBDjXoA_DZ3A=.577eb61f-6333-4cca-ad89-bc17c73bb660@github.com>

On Mon, 2 Feb 2026 13:26:12 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> So, I would rather have a field if I may break

Let's go with the field then ?

> ```NOT_PRODUCT(void dump_spec(outputStream* st) const);```

Good idea! Added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2754497278

From syan at openjdk.org  Mon Feb  2 14:06:53 2026
From: syan at openjdk.org (SendaoYan)
Date: Mon, 2 Feb 2026 14:06:53 GMT
Subject: RFR: 8376760: VerifyJimage.java#compare intermittent failed with
 fastdebug [v3]
In-Reply-To: <VKxYiVWcWNUjEFkPvadCqMVVfAwY7UmG-kLXVEo9o6A=.90c77193-e0e6-4212-94cd-2d214a2b8145@github.com>
References: <j360mZjyQnFn5YnxFiE75b-6WEbzQh0AHBDFRTmo6Zk=.fc329853-99bc-4867-bc81-d9ffa46ba386@github.com>
 <GwOWYkJcdZDAhuNJUMV3UFtExG_tTCLE_rcxTz6fs98=.4be1697f-c896-4c49-b0b2-84fdb9773280@github.com>
 <VKxYiVWcWNUjEFkPvadCqMVVfAwY7UmG-kLXVEo9o6A=.90c77193-e0e6-4212-94cd-2d214a2b8145@github.com>
Message-ID: <vqd8lSgDBbSPKT3STBAySnVPlSxiBy5JsnA3Np3qONE=.b42711b8-1861-4631-bbbe-9b80e3774b26@github.com>

On Mon, 2 Feb 2026 11:11:43 GMT, David Beaumont <duke at openjdk.org> wrote:

> Looks good, thanks for simplifying. I'm assuming the fix has been verified as fixing the observable issue.

Yes. Before this PR, I can reproduce this failure with fastdebug build. After this PR this test run all passed 100 times simultancely with fastdebug build.

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

PR Comment: https://git.openjdk.org/jdk/pull/29498#issuecomment-3835330230

From liach at openjdk.org  Mon Feb  2 14:29:33 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Feb 2026 14:29:33 GMT
Subject: RFR: 8376760: VerifyJimage.java#compare intermittent failed with
 fastdebug [v3]
In-Reply-To: <GwOWYkJcdZDAhuNJUMV3UFtExG_tTCLE_rcxTz6fs98=.4be1697f-c896-4c49-b0b2-84fdb9773280@github.com>
References: <j360mZjyQnFn5YnxFiE75b-6WEbzQh0AHBDFRTmo6Zk=.fc329853-99bc-4867-bc81-d9ffa46ba386@github.com>
 <GwOWYkJcdZDAhuNJUMV3UFtExG_tTCLE_rcxTz6fs98=.4be1697f-c896-4c49-b0b2-84fdb9773280@github.com>
Message-ID: <n_avEaP6hBwjpDtvC0B45oIoWUSFGDdot2mhx9pMg4Y=.d6fd87c1-288d-4449-bb2a-d6d5c680091b@github.com>

On Sun, 1 Feb 2026 10:19:51 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test tools/jimage/VerifyJimage.java#compare intermittent timed out with fastdebug build. I think it would be better to ajust the jtreg timeout factor(20*timeoutFactor) rather that set the fix timeout value(20) for awaitTermination.
>> 
>> The test run all passed 100 times simultaneously.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary import

Somehow david is not an author, so I will leave an approval to allow  integration.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29498#pullrequestreview-3739750934

From rriggs at openjdk.org  Mon Feb  2 14:46:37 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 2 Feb 2026 14:46:37 GMT
Subject: RFR: 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java
 intermittent timed out [v2]
In-Reply-To: <NqXWOMOT0dajB18FxH40ECEcXIh_RGHDA7TGaq9tOFQ=.c4e9e470-7791-4f5b-a446-a99c84710ebd@github.com>
References: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com>
 <NqXWOMOT0dajB18FxH40ECEcXIh_RGHDA7TGaq9tOFQ=.c4e9e470-7791-4f5b-a446-a99c84710ebd@github.com>
Message-ID: <sFOByL-GF3xGYWBamz6OWnQ9LAj0P0XYjCfNshBj9qk=.5a821308-3146-4945-9737-bfb4ab184303@github.com>

On Sat, 31 Jan 2026 04:40:13 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out, because `lsof` invoke huast lots of time when the tested machine has many processes, and the processes open too many files.
>> 
>> This PR add parameter -p pid to `lsof`, which will only generate output from the wanted processes, rather than all the processes on the machine, this will make `lsof` use less time to finish significantly. And this PR also use `Process.waitFor(long timeout, TimeUnit unit)` instead of `waitFor()` which will avoid waitFor invoke cause test timed out. Delete the history lsof input and output files will make diagnosis more easy.
>> 
>> Change has been verifed locally. The imtermittent timed out do not observed anymore.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert the change of lsof -p and only increase timeout value for test
>  - Revert "8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out"
>    
>    This reverts commit 23d6dd1ae20bdd8957826f443a95bd4e69000eab.

test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 243:

> 241:                 .start()) {
> 242:             boolean status = p.waitFor(Utils.adjustTimeout(120), TimeUnit.SECONDS);
> 243:             if (!status) {

Retry on destroyForcibly isn't necessary or productive. On Linux its equivalent to 'kill -9' and on Windows it isn't conditional.
If there is a case where the a single call isn't effective, that should be reported as a bug against `destroyForcibly`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29478#discussion_r2754697692

From thartmann at openjdk.org  Mon Feb  2 16:02:56 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 2 Feb 2026 16:02:56 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v12]
In-Reply-To: <2_bA8sRgRlbc279Aia0oD9gPBn8bcD5kLP3RnA4Xl4Q=.deaeaaf0-27a1-40f8-81f3-c8283c4d9529@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <2_bA8sRgRlbc279Aia0oD9gPBn8bcD5kLP3RnA4Xl4Q=.deaeaaf0-27a1-40f8-81f3-c8283c4d9529@github.com>
Message-ID: <_mVonDnsPn3yCi7haKqAlC_3iD8GNOojYbMt4xuUf_Y=.2c887c19-5dba-4501-bec4-faba0a2dca9b@github.com>

On Mon, 2 Feb 2026 14:03:00 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> ## Issue
>> 
>> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
>> 
>> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
>> 
>> ## Causes
>> 
>> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
>> 
>> ## Fix
>> 
>> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
>> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
>> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
>> 
>> # Testing
>> 
>> * Tier 1-3+
>> * 2 JTReg tests added
>>   * `TestRangeCheck.java` as regression test for the reported issue
>>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion
>
> Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - JDK-8374582: remove empty line
>  - JDK-8374582: add constant dump

That looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3740390312

From duke at openjdk.org  Mon Feb  2 16:55:04 2026
From: duke at openjdk.org (David Beaumont)
Date: Mon, 2 Feb 2026 16:55:04 GMT
Subject: RFR: 8376703: Some coding in libjimage seems to be not called at
 all or not called from PRODUCT code [v2]
In-Reply-To: <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
References: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
 <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
Message-ID: <vOwciANfl3QfmOKm6Vuw0tT_zKu4sXW_JiuwpFBYTGs=.95e84f67-895c-4694-8153-fccd74c7f3f2@github.com>

On Fri, 30 Jan 2026 12:41:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> libjimage has a few unused functions/methods; those are listed when logging elimination with  -Wl,--gc-sections -Wl,--print-gc-sections .
>> We could remove them (or with if are still needed for completeness  put them into  #if 0 ) to reduce lib size on Linux and AIX.
>> On Windows and macOS it seems the compiler/linker default settings are good enough to eliminate the code.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust COPYRIGHT headers

As it happens, there's no overlap here, so you should be fine going ahead with this PR as-is.

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

PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3836454649

From alanb at openjdk.org  Mon Feb  2 17:04:06 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 2 Feb 2026 17:04:06 GMT
Subject: RFR: 8376703: Some coding in libjimage seems to be not called at
 all or not called from PRODUCT code [v2]
In-Reply-To: <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
References: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
 <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
Message-ID: <GH0OezJSCt2y6q39Xo7XKLzk5xHrcrFDrKd3v9Pukd4=.c1e07ba7-1016-4e0c-8b4e-71afe457215f@github.com>

On Fri, 30 Jan 2026 12:41:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> libjimage has a few unused functions/methods; those are listed when logging elimination with  -Wl,--gc-sections -Wl,--print-gc-sections .
>> We could remove them (or with if are still needed for completeness  put them into  #if 0 ) to reduce lib size on Linux and AIX.
>> On Windows and macOS it seems the compiler/linker default settings are good enough to eliminate the code.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust COPYRIGHT headers

Marked as reviewed by alanb (Reviewer).

Thanks for checking/.

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

PR Review: https://git.openjdk.org/jdk/pull/29502#pullrequestreview-3740755279
PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3836487503

From duke at openjdk.org  Mon Feb  2 17:29:37 2026
From: duke at openjdk.org (David Beaumont)
Date: Mon, 2 Feb 2026 17:29:37 GMT
Subject: RFR: 8376703: Some coding in libjimage seems to be not called at
 all or not called from PRODUCT code [v2]
In-Reply-To: <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
References: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
 <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
Message-ID: <ZNsGVaMluZSltyJUr2i8nr_hBY7QTeyZqZfpPR2ZWog=.e63a8f65-6116-4368-84ea-d5ec461549fa@github.com>

On Fri, 30 Jan 2026 12:41:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> libjimage has a few unused functions/methods; those are listed when logging elimination with  -Wl,--gc-sections -Wl,--print-gc-sections .
>> We could remove them (or with if are still needed for completeness  put them into  #if 0 ) to reduce lib size on Linux and AIX.
>> On Windows and macOS it seems the compiler/linker default settings are good enough to eliminate the code.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust COPYRIGHT headers

This doesn't overlap with anything I'm changing, so for my perspective, it's all good.

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

PR Review: https://git.openjdk.org/jdk/pull/29502#pullrequestreview-3740909567

From liach at openjdk.org  Mon Feb  2 17:47:47 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Feb 2026 17:47:47 GMT
Subject: RFR: 8376954: Typos in CharacterRangeInfo and
 AsynchronousServerSocketChannel
In-Reply-To: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
References: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
Message-ID: <XuHe7QFOzzRDhNCs6WwHzyQjx6CMGy9m1frWT26ZLn4=.fa5778ad-a35f-4494-933c-cc03a047bfa0@github.com>

On Sun, 1 Feb 2026 13:57:36 GMT, Hendrik Schick <duke at openjdk.org> wrote:

> Fix typos in comments:
> 
> - in java.nio.channels.AsynchronousServerSocketChannel: altogther -> altogether
> - in java.lang.classfile.attribute.CharacterRangeInfo: removed duplicated 'the' twice

Created https://bugs.openjdk.org/browse/JDK-8376954 for you.

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

PR Comment: https://git.openjdk.org/jdk/pull/29513#issuecomment-3835341422

From duke at openjdk.org  Mon Feb  2 17:47:46 2026
From: duke at openjdk.org (Hendrik Schick)
Date: Mon, 2 Feb 2026 17:47:46 GMT
Subject: RFR: 8376954: Typos in CharacterRangeInfo and
 AsynchronousServerSocketChannel
Message-ID: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>

Fix typos in comments:

- in java.nio.channels.AsynchronousServerSocketChannel: altogther -> altogether
- in java.lang.classfile.attribute.CharacterRangeInfo: removed duplicated 'the' twice

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

Commit messages:
 - 8376954: Typos in CharacterRangeInfo and AsynchronousServerSocketChannel

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

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

From missa at openjdk.org  Mon Feb  2 18:40:37 2026
From: missa at openjdk.org (Mohamed Issa)
Date: Mon, 2 Feb 2026 18:40:37 GMT
Subject: RFR: 8371955: Support AVX10 floating point comparison instructions
 [v9]
In-Reply-To: <pDlUnmb64685l7fUy6_2jpow34OMR3JBs63-PMnoAM0=.ae33e19d-66ff-4f1f-b162-e4974e0b0fe5@github.com>
References: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>
 <xb6Vynn9YvjBOEQA07oDT6uaaZZwOqofv-oDx7U8QAY=.4d61455a-bbba-4d73-8c38-06e365827d05@github.com>
 <pDlUnmb64685l7fUy6_2jpow34OMR3JBs63-PMnoAM0=.ae33e19d-66ff-4f1f-b162-e4974e0b0fe5@github.com>
Message-ID: <71uI1BCZPJmBfUhtRMBcRREf63StolB9Ch0vhgPgZeU=.c3bbfca7-e9da-4caf-82c6-be28ef4f98fe@github.com>

On Thu, 29 Jan 2026 09:02:03 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> FYI: testing launched ?

@eme64 Did tests pass?

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

PR Comment: https://git.openjdk.org/jdk/pull/28337#issuecomment-3836979281

From rriggs at openjdk.org  Mon Feb  2 18:42:36 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 2 Feb 2026 18:42:36 GMT
Subject: RFR: 8376703: Some coding in libjimage seems to be not called at
 all or not called from PRODUCT code [v2]
In-Reply-To: <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
References: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
 <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
Message-ID: <IjrR6yMM4xDp44yj7VkZyxvHWw6ZlUEN7eGpGqWk4SE=.2a188834-ee5c-4906-9b44-4021fe3ebf72@github.com>

On Fri, 30 Jan 2026 12:41:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> libjimage has a few unused functions/methods; those are listed when logging elimination with  -Wl,--gc-sections -Wl,--print-gc-sections .
>> We could remove them (or with if are still needed for completeness  put them into  #if 0 ) to reduce lib size on Linux and AIX.
>> On Windows and macOS it seems the compiler/linker default settings are good enough to eliminate the code.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust COPYRIGHT headers

Looks fine.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29502#pullrequestreview-3741251777

From mbaesken at openjdk.org  Mon Feb  2 18:46:37 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 2 Feb 2026 18:46:37 GMT
Subject: RFR: 8376703: Some coding in libjimage seems to be not called at
 all or not called from PRODUCT code [v2]
In-Reply-To: <ZNsGVaMluZSltyJUr2i8nr_hBY7QTeyZqZfpPR2ZWog=.e63a8f65-6116-4368-84ea-d5ec461549fa@github.com>
References: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
 <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
 <ZNsGVaMluZSltyJUr2i8nr_hBY7QTeyZqZfpPR2ZWog=.e63a8f65-6116-4368-84ea-d5ec461549fa@github.com>
Message-ID: <f9en3FdDgZxGi489I-4SSk56o-ER-_GHbObhAlJBGkE=.5b014f82-58ec-45e5-bf65-9b50c640a4eb@github.com>

On Mon, 2 Feb 2026 17:27:02 GMT, David Beaumont <duke at openjdk.org> wrote:

> This doesn't overlap with anything I'm changing, so for my perspective, it's all good.

Thanks for checking !

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

PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3837005933

From mbaesken at openjdk.org  Mon Feb  2 18:49:51 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 2 Feb 2026 18:49:51 GMT
Subject: RFR: 8376703: Some coding in libjimage seems to be not called at
 all or not called from PRODUCT code [v2]
In-Reply-To: <Vyow0B_A9KreqlSGqQaPMTuflFXQX2wM_SmWe-N4me0=.9b468776-17be-4860-a8fe-5615231b8b0f@github.com>
References: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
 <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
 <FAuPYJi9LgadWpg_tshOyGLQHby2k5uriVWffXlSmEI=.89d1bd97-2d4a-46b7-a94d-0566c549cce5@github.com>
 <Vyow0B_A9KreqlSGqQaPMTuflFXQX2wM_SmWe-N4me0=.9b468776-17be-4860-a8fe-5615231b8b0f@github.com>
Message-ID: <l7ojCSuy-I1Cy4tgCcJt8V7xNpSlMJA3WMfdDEMuu1s=.395650c2-1899-43ad-88ff-5c3ec92d8582@github.com>

On Sat, 31 Jan 2026 16:24:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > but this is not unused/uncalled in our codebase. I think it is inlined at the 1 or 2 points were it is used. But the method is still generated into the library even in case that it is always inlined ; it may be difficult to address this with the usual linker settings on Linux (means without linktime-gc or LTO or similar stuff ) .
> 
> That is a bit unnerving but if someone were to use this warning to remove code that is used then there would be build or test failures.

Sure, we cannot remove such code. I tested a little bit and in some C coding, with always-inline attributes added I could force that such a function is always inlined  **_AND_**  was removed from the lib.  But this seems not to work well with C++ methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3837015503

From mbaesken at openjdk.org  Mon Feb  2 18:49:55 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 2 Feb 2026 18:49:55 GMT
Subject: RFR: 8376703: Some coding in libjimage seems to be not called at
 all or not called from PRODUCT code [v2]
In-Reply-To: <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
References: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
 <Krx8ZPfnKeZV885HxX8XSdJpAAYueXm06lNFtVTLqHU=.4ee8347d-c8bf-49fa-a1f1-6acab7220438@github.com>
Message-ID: <S9pYrusJhFgeYtWkuzv3UViJa24MJgSQxNv9g9XsTBE=.46354af9-4fd3-4be1-b830-d809f16398e2@github.com>

On Fri, 30 Jan 2026 12:41:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> libjimage has a few unused functions/methods; those are listed when logging elimination with  -Wl,--gc-sections -Wl,--print-gc-sections .
>> We could remove them (or with if are still needed for completeness  put them into  #if 0 ) to reduce lib size on Linux and AIX.
>> On Windows and macOS it seems the compiler/linker default settings are good enough to eliminate the code.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust COPYRIGHT headers

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3837018209

From mbaesken at openjdk.org  Mon Feb  2 18:53:27 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 2 Feb 2026 18:53:27 GMT
Subject: Integrated: 8376703: Some coding in libjimage seems to be not called
 at all or not called from PRODUCT code
In-Reply-To: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
References: <zJUTe2RS35JStA3btzNIOxhItFMzN3AA3OlEg5xKTwo=.43aab96f-b795-4dda-84ef-9988dc8ca960@github.com>
Message-ID: <-qXcSiNYeFebARo1cfFsJF-VkUKKvFmMdm5te0q4rHE=.f2a69365-a85d-4b3a-be63-7c5493a9630c@github.com>

On Fri, 30 Jan 2026 09:30:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> libjimage has a few unused functions/methods; those are listed when logging elimination with  -Wl,--gc-sections -Wl,--print-gc-sections .
> We could remove them (or with if are still needed for completeness  put them into  #if 0 ) to reduce lib size on Linux and AIX.
> On Windows and macOS it seems the compiler/linker default settings are good enough to eliminate the code.

This pull request has now been integrated.

Changeset: 8023c416
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8023c41690aee648eef800b69e517136e1cd062c
Stats:     73 lines in 5 files changed: 0 ins; 69 del; 4 mod

8376703: Some coding in libjimage seems to be not called at all or not called from PRODUCT code

Reviewed-by: alanb, rriggs

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

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

From liach at openjdk.org  Mon Feb  2 19:02:13 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Feb 2026 19:02:13 GMT
Subject: RFR: 8376954: Typos in CharacterRangeInfo and
 AsynchronousServerSocketChannel
In-Reply-To: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
References: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
Message-ID: <XTHzfIBlnr1pk1EPxylbuwOxJE3z9gK9vEkn1MmbkGA=.c4066d12-134c-41e4-b43d-31b0ed33cc33@github.com>

On Sun, 1 Feb 2026 13:57:36 GMT, Hendrik Schick <duke at openjdk.org> wrote:

> Fix typos in comments:
> 
> - in java.nio.channels.AsynchronousServerSocketChannel: altogther -> altogether
> - in java.lang.classfile.attribute.CharacterRangeInfo: removed duplicated 'the' twice

The CRT change looks fine. Let another reviewer review the socket channel.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29513#pullrequestreview-3741322251

From bpb at openjdk.org  Mon Feb  2 19:07:23 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 2 Feb 2026 19:07:23 GMT
Subject: RFR: 8376954: Typos in CharacterRangeInfo and
 AsynchronousServerSocketChannel
In-Reply-To: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
References: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
Message-ID: <ShcOkybzq_FEvjpp7DZRfhRcVwXR9RoKnGQv7f4GOio=.234f09a0-38d8-49b6-8023-a0923ced915e@github.com>

On Sun, 1 Feb 2026 13:57:36 GMT, Hendrik Schick <duke at openjdk.org> wrote:

> Fix typos in comments:
> 
> - in java.nio.channels.AsynchronousServerSocketChannel: altogther -> altogether
> - in java.lang.classfile.attribute.CharacterRangeInfo: removed duplicated 'the' twice

Marked as reviewed by bpb (Reviewer).

src/java.base/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java line 211:

> 209:      * connections on the socket. Its exact semantics are implementation specific.
> 210:      * In particular, an implementation may impose a maximum length or may choose
> 211:      * to ignore the parameter altogether. If the {@code backlog} parameter has

Looks fine.

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

PR Review: https://git.openjdk.org/jdk/pull/29513#pullrequestreview-3741341206
PR Review Comment: https://git.openjdk.org/jdk/pull/29513#discussion_r2755815114

From rriggs at openjdk.org  Mon Feb  2 19:32:30 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 2 Feb 2026 19:32:30 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v3]
In-Reply-To: <H-tjYRJJx8TvSspAWby0xuDiwN3jJ_CIaeHt4mFu2ZM=.741e4fe5-a528-482f-8da0-3a161c6810d8@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <H-tjYRJJx8TvSspAWby0xuDiwN3jJ_CIaeHt4mFu2ZM=.741e4fe5-a528-482f-8da0-3a161c6810d8@github.com>
Message-ID: <vTawPapYfjbjHsYI_0PI1O31JdRdukbmBltSN1KXCBA=.5dc5d830-0c50-4cee-a127-73df6572cc29@github.com>

On Fri, 30 Jan 2026 22:58:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed indentation

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29493#pullrequestreview-3741418933

From rriggs at openjdk.org  Mon Feb  2 19:43:48 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 2 Feb 2026 19:43:48 GMT
Subject: RFR: 8375585: Test java/lang/ProcessBuilder/PipelineLeaksFD.java
 failed
Message-ID: <RcWyeLjeptkC1ZUDvTukbnTXkeCPIOJtseYAcfk3jA8=.41f33014-ff91-431c-83a1-4595edb05669@github.com>

Revised test to explicitly compare file descriptor info only from parent and child.
If additional fd's are present in the child, it is hard to know their origin but they do not necessarily indicate a bug in Process launch.
 
Remove from the problem list.

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

Commit messages:
 - 8375585: Test java/lang/ProcessBuilder/PipelineLeaksFD.java failed

Changes: https://git.openjdk.org/jdk/pull/29530/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29530&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8375585
  Stats: 65 lines in 3 files changed: 31 ins; 13 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/29530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29530/head:pull/29530

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

From asemenyuk at openjdk.org  Mon Feb  2 19:46:01 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 2 Feb 2026 19:46:01 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
Message-ID: <Pswv4x32YHhRK46H6vTMMSUcSFYa1dcCIfpaICSD328=.87a18d79-87a5-44aa-9acf-0ba34c685280@github.com>

On Sun, 18 Jan 2026 05:17:40 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
>> - Added test to cover added functionality.
>> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]

src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/DottedVersion.java line 227:

> 225:     }
> 226: 
> 227:     public String toComponentsStringWithPadding(int numberOfComponents) {

The method's name is misleading, as the implementation may trim the components. It also duplicates the functionality of the `toComponentsString()`. I suggest splitting it into two methods: `DottedVersion trim(int componentLimit)` and `DottedVersion pad(int componentLimit)`.

If they want to get a string representation of exactly 3 version components they would call:

ver.trim(3).pad(3).toComponentsString();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2755914569

From asemenyuk at openjdk.org  Mon Feb  2 20:02:38 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 2 Feb 2026 20:02:38 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
Message-ID: <1HbJzaOksc5zJFxWpo3oyytyD7CRuY-pNlOQMyD3d-w=.bf3bf548-93fb-49ab-8f54-79684a498b70@github.com>

On Sun, 18 Jan 2026 05:17:40 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
>> - Added test to cover added functionality.
>> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]

src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/RuntimeVersionReader.java line 38:

> 36: 
> 37:     public static Optional<String> readVersion(Path releaseFilePath) throws IOException {
> 38:         if (!Files.isRegularFile(releaseFilePath)) {

What is the point of this check? If you remove it and let the function throw an IOException, the function signature can be simplified to `String readVersion(Path releaseFilePath) throws IOException`. Making it clear that the function either returns a valid JDK version or throws.

If you don't want to deal with handling exceptions in the caller, you can implement it without throwing:

Optional<String> readVersion(Path releaseFilePath) {
    try {
        ...
        return Optional.of(version);
    } catch (IOException ex) {
        return Optional.empty();
    }
}

Currently, it is a confusing mix of both approaches.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2755960178

From jlu at openjdk.org  Mon Feb  2 20:13:26 2026
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 2 Feb 2026 20:13:26 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v3]
In-Reply-To: <H-tjYRJJx8TvSspAWby0xuDiwN3jJ_CIaeHt4mFu2ZM=.741e4fe5-a528-482f-8da0-3a161c6810d8@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <H-tjYRJJx8TvSspAWby0xuDiwN3jJ_CIaeHt4mFu2ZM=.741e4fe5-a528-482f-8da0-3a161c6810d8@github.com>
Message-ID: <HRoAzpYGpbb4vFECCeUiXcFh0QXAvc9bhhzWrlHzbSQ=.9b690dab-3fc4-4143-8710-e587569d349b@github.com>

On Fri, 30 Jan 2026 22:58:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed indentation

For better test coverage should we also include a second run against the jline implementation?

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

PR Comment: https://git.openjdk.org/jdk/pull/29493#issuecomment-3837296754

From psandoz at openjdk.org  Mon Feb  2 20:25:15 2026
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 2 Feb 2026 20:25:15 GMT
Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass
 them to intrinsic entries [v6]
In-Reply-To: <k118UMK3mVVIMcluzGrC-ZpVT0sYBhSKtgFhQlzGCjE=.2d61f6e0-e2d0-4906-8331-d27dc312a865@github.com>
References: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
 <k118UMK3mVVIMcluzGrC-ZpVT0sYBhSKtgFhQlzGCjE=.2d61f6e0-e2d0-4906-8331-d27dc312a865@github.com>
Message-ID: <bS7FMO43tYrUmkb9oYo0Qw3E7vlFOsryUrRactQIkgg=.40e929be-322f-444b-9e60-cd262ad3a4c6@github.com>

On Mon, 2 Feb 2026 09:07:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support.
>> 
>> Patch add new lane type constants and pass them to vector intrinsic entry points.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment resolution

Very good. Approved, there is just one comment related to adding a comment for the LT_* values. Thank you for separating this out from the float16 PR. Needs a HotSpot reviewer too. We will run it through tier 1 to 3 testing.

src/hotspot/share/prims/vectorSupport.hpp line 140:

> 138:   };
> 139: 
> 140:   enum LaneType {

Please add a comment referencing `LaneType` and that the values in this enum correspond to the LaneType ordinal values.

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

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29481#pullrequestreview-3741431390
PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2755893774

From duke at openjdk.org  Mon Feb  2 20:43:40 2026
From: duke at openjdk.org (Hendrik Schick)
Date: Mon, 2 Feb 2026 20:43:40 GMT
Subject: RFR: 8376954: Typos in CharacterRangeInfo and
 AsynchronousServerSocketChannel
In-Reply-To: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
References: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
Message-ID: <Xf8kuXKtvPwUK27cUcdP-PZF5wivPuXI-u2in8AGh3s=.6c355af4-c35f-40a8-9ad8-f2b979246356@github.com>

On Sun, 1 Feb 2026 13:57:36 GMT, Hendrik Schick <duke at openjdk.org> wrote:

> Fix typos in comments:
> 
> - in java.nio.channels.AsynchronousServerSocketChannel: altogther -> altogether
> - in java.lang.classfile.attribute.CharacterRangeInfo: removed duplicated 'the' twice

thank you

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

PR Comment: https://git.openjdk.org/jdk/pull/29513#issuecomment-3837374382

From duke at openjdk.org  Mon Feb  2 20:43:41 2026
From: duke at openjdk.org (duke)
Date: Mon, 2 Feb 2026 20:43:41 GMT
Subject: RFR: 8376954: Typos in CharacterRangeInfo and
 AsynchronousServerSocketChannel
In-Reply-To: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
References: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
Message-ID: <o9zKuJnIniH8lWLaamnTGFNZyuJZ0nrjsmq3kHcFSfI=.57ea835b-d6e6-406c-9634-35d5915df524@github.com>

On Sun, 1 Feb 2026 13:57:36 GMT, Hendrik Schick <duke at openjdk.org> wrote:

> Fix typos in comments:
> 
> - in java.nio.channels.AsynchronousServerSocketChannel: altogther -> altogether
> - in java.lang.classfile.attribute.CharacterRangeInfo: removed duplicated 'the' twice

@ky0n 
Your change (at version 374ccbf02657d014a493042c05dc82940bb03f91) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/29513#issuecomment-3837375801

From asemenyuk at openjdk.org  Mon Feb  2 20:49:21 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 2 Feb 2026 20:49:21 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
Message-ID: <NEeBqEpKFRvjQg8rs2ropHOlKqpW_U6UpWbexU3p4Qg=.bf7bf267-2c59-44a0-9987-97b3bbabae59@github.com>

On Sun, 18 Jan 2026 05:17:40 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
>> - Added test to cover added functionality.
>> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]

Changes requested by asemenyuk (Reviewer).

src/jdk.jpackage/share/classes/jdk/jpackage/internal/FromOptions.java line 191:

> 189:             if (!APP_VERSION.containsIn(options)) {
> 190:                 // Version is not specified explicitly. Try to get it from the release file.
> 191:                 final Path releaseFile = RuntimeImageUtils.getReleaseFilePath(

The path to the predefined runtime directory (the directory with the standard JDK structure) is stored in the `predefinedRuntimeDirectory` variable.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/ModuleInfo.java line 64:

> 62:         // of `release` file.
> 63: 
> 64:         final Path releaseFile = RuntimeImageUtils.getReleaseFilePath(cookedRuntime);

Assume macOS-specificity has been removed from `RuntimeImageUtils.getReleaseFilePath()`, the code will be:

final Path releaseFile = RuntimeImageUtils.getReleaseFilePath(MacBundle.fromPath(cookedRuntime).map(MacBundle::homeDir).orElse(cookedRuntime));

src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/RuntimeImageUtils.java line 47:

> 45:         }
> 46: 
> 47:         return releaseFile;

Why do we need platform-specificity in this function?

Shouldn't it be as simple as:

public static Path getReleaseFilePath(Path runtimePath) {
    return runtimePath.resolve("release");
}

src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/RuntimeVersionReader.java line 47:

> 45:             String version = props.getProperty("JAVA_VERSION");
> 46:             if (version != null) {
> 47:                 version = version.replaceAll("^\"|\"$", "");

Why does this function filter the value of the "JAVA_VERSION" property?

It should not do any filtering; it should just read the value as its name suggests.

Filering is platform-specific and should be a separate method.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinFromOptions.java line 139:

> 137:         // When reading from release file it can be 1 or 3 or maybe more.
> 138:         // We always normalize to 4 components.
> 139:         DottedVersion ver = DottedVersion.greedy(version);

This should be `DottedVersion.lazy()`, not `DottedVersion.greedy()`, as the latter will throw if the string has a trailing substring that is not a valid version component.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinFromOptions.java line 141:

> 139:         DottedVersion ver = DottedVersion.greedy(version);
> 140:         BigInteger[] components = ver.getComponents();
> 141:         if (components.length == 1 || components.length == 3 ||

This condition is redundant if the DottedVersion class has `trim()` and `pad()` methods as suggested above. The whole function can be a one-liner:

return DottedVersion.lazy(version).trim(4).pad(4).toComponentsString();

test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/RuntimeVersionReaderTest.java line 41:

> 39: import org.junit.jupiter.api.io.TempDir;
> 40: 
> 41: public class RuntimeVersionReaderTest {

I doubt this unit test has ever been executed.

test/jdk/tools/jpackage/share/RuntimePackageTest.java line 87:

> 85: public class RuntimePackageTest {
> 86: 
> 87:     // @Test

Is this debugging leftovers?

test/jdk/tools/jpackage/share/RuntimePackageTest.java line 120:

> 118:     @Test
> 119:     // 27
> 120:     @Parameter(value = {"27", ""}, ifOS = {LINUX, MACOS})

I think we need some "unusual" test cases to test the robustness of the version-reading code. E.g.: "foo", "17.21.3+foo", "".

test/jdk/tools/jpackage/share/RuntimePackageTest.java line 160:

> 158:                     .cannedFormattedString("message.release-version",
> 159:                     version, runtimeImage.toString()));
> 160:             if (!normalizedVersion.isEmpty()) {

Why would we not have a normalized version in some cases? Shouldn't it always be available?

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

PR Review: https://git.openjdk.org/jdk/pull/29260#pullrequestreview-3741519906
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2756004587
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2756018116
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2756000367
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2755967624
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2756028862
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2756038982
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2756054341
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2756056271
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2756068456
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2756060100

From naoto at openjdk.org  Mon Feb  2 20:56:17 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 2 Feb 2026 20:56:17 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v4]
In-Reply-To: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
Message-ID: <ti3gyiAOIIsK7qyQYicJ7Gx0X3sayB5ofrCAscUmOgs=.7687ca28-b980-4e30-9afe-42c634bf1c3f@github.com>

> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.

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

 - added jline test run
 - Merge branch 'master' into JDK-8340830-Console-readLine-printf-mutually-blocking
 - Fixed indentation
 - Made ProxyingConsole value-based, used anonymous class for LazyConstant
 - Refine exceptions
 - initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29493/files
  - new: https://git.openjdk.org/jdk/pull/29493/files/84bb6ea4..a71f4c96

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

  Stats: 28623 lines in 342 files changed: 15782 ins; 11564 del; 1277 mod
  Patch: https://git.openjdk.org/jdk/pull/29493.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29493/head:pull/29493

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

From duke at openjdk.org  Mon Feb  2 21:01:21 2026
From: duke at openjdk.org (Hendrik Schick)
Date: Mon, 2 Feb 2026 21:01:21 GMT
Subject: Integrated: 8376954: Typos in CharacterRangeInfo and
 AsynchronousServerSocketChannel
In-Reply-To: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
References: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
Message-ID: <LrLRMV6WDYxpm4ZKj4pt1svexKNPUyUU8gTwqZdJyHo=.079d8bbf-c7b6-41d7-b7ae-f3059d6a539b@github.com>

On Sun, 1 Feb 2026 13:57:36 GMT, Hendrik Schick <duke at openjdk.org> wrote:

> Fix typos in comments:
> 
> - in java.nio.channels.AsynchronousServerSocketChannel: altogther -> altogether
> - in java.lang.classfile.attribute.CharacterRangeInfo: removed duplicated 'the' twice

This pull request has now been integrated.

Changeset: 5607a462
Author:    Hendrik Schick <hendrikjschick at gmail.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5607a4620c97ad2650a2dd3f464d03955fe17ef1
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8376954: Typos in CharacterRangeInfo and AsynchronousServerSocketChannel

Reviewed-by: liach, bpb

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

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

From vyazici at openjdk.org  Mon Feb  2 21:43:57 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Feb 2026 21:43:57 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v4]
In-Reply-To: <ti3gyiAOIIsK7qyQYicJ7Gx0X3sayB5ofrCAscUmOgs=.7687ca28-b980-4e30-9afe-42c634bf1c3f@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <ti3gyiAOIIsK7qyQYicJ7Gx0X3sayB5ofrCAscUmOgs=.7687ca28-b980-4e30-9afe-42c634bf1c3f@github.com>
Message-ID: <ab1WAMNauE7Twn0mfLX3lgrYB5nSy9vyMPb3P_p3-sI=.5701aeff-0588-44e8-9d4e-afde9a72fdfc@github.com>

On Mon, 2 Feb 2026 20:56:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.
>
> 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 six additional commits since the last revision:
> 
>  - added jline test run
>  - Merge branch 'master' into JDK-8340830-Console-readLine-printf-mutually-blocking
>  - Fixed indentation
>  - Made ProxyingConsole value-based, used anonymous class for LazyConstant
>  - Refine exceptions
>  - initial commit

test/jdk/java/io/Console/ReadWriteBlockingTest.java line 47:

> 45: 
> 46:     @Test
> 47:     @EnabledOnOs({OS.LINUX, OS.MAC})

You might want to tell this to JTreg and avoid some CPU cycles:

    @requires (os.family == "linux" | os.family == "mac")

`@EnabledOnOs` can receive a `disabledReason` argument, which might be handy in this case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2756205116

From vyazici at openjdk.org  Mon Feb  2 21:48:37 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Feb 2026 21:48:37 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v4]
In-Reply-To: <ti3gyiAOIIsK7qyQYicJ7Gx0X3sayB5ofrCAscUmOgs=.7687ca28-b980-4e30-9afe-42c634bf1c3f@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <ti3gyiAOIIsK7qyQYicJ7Gx0X3sayB5ofrCAscUmOgs=.7687ca28-b980-4e30-9afe-42c634bf1c3f@github.com>
Message-ID: <Zv8HqXbs5527ba5cVunKPa7UtoFT6v1IAP35LNUbkao=.630baef6-29e0-488b-afd3-473de7f0bfec@github.com>

On Mon, 2 Feb 2026 20:56:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.
>
> 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 six additional commits since the last revision:
> 
>  - added jline test run
>  - Merge branch 'master' into JDK-8340830-Console-readLine-printf-mutually-blocking
>  - Fixed indentation
>  - Made ProxyingConsole value-based, used anonymous class for LazyConstant
>  - Refine exceptions
>  - initial commit

@naotoj, I see we removed synchronization from two classes, and introduced tests to verify that nothing blocks anymore. Do we also have tests to verify that synchronization is not broken? If not, do we need to add them?

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

PR Comment: https://git.openjdk.org/jdk/pull/29493#issuecomment-3837538229

From naoto at openjdk.org  Mon Feb  2 22:05:03 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 2 Feb 2026 22:05:03 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v5]
In-Reply-To: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
Message-ID: <bDkndly51pLDHZIMCACnfcLuq-ZOvLfEMZdsfptGmEE=.ddd2890c-2654-45d7-b35a-aaf98a845b2a@github.com>

> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.

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

  Added @requires condition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29493/files
  - new: https://git.openjdk.org/jdk/pull/29493/files/a71f4c96..4c065425

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

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

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

From naoto at openjdk.org  Mon Feb  2 22:07:53 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 2 Feb 2026 22:07:53 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v4]
In-Reply-To: <Zv8HqXbs5527ba5cVunKPa7UtoFT6v1IAP35LNUbkao=.630baef6-29e0-488b-afd3-473de7f0bfec@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <ti3gyiAOIIsK7qyQYicJ7Gx0X3sayB5ofrCAscUmOgs=.7687ca28-b980-4e30-9afe-42c634bf1c3f@github.com>
 <Zv8HqXbs5527ba5cVunKPa7UtoFT6v1IAP35LNUbkao=.630baef6-29e0-488b-afd3-473de7f0bfec@github.com>
Message-ID: <NsYlQaBmvHLXTmZCOfu8Kfir5PeDYKdS-exxnbigAuw=.2bf390f5-71b5-4ea5-a037-c906af94939c@github.com>

On Mon, 2 Feb 2026 21:46:19 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>  Do we also have tests to verify that synchronization is not broken? If not, do we need to add them?

I don't think that is necessary, as those removed locks are simply ensuring the underlying read/write locks in StreamEncoder/Decoder, and those underlying synchronization should have been covered via the public `InputStreamReader` and/or `OutputStreamWriter`, which shares the underlying implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/29493#issuecomment-3837582326

From syan at openjdk.org  Tue Feb  3 02:41:41 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Feb 2026 02:41:41 GMT
Subject: RFR: 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java
 intermittent timed out [v3]
In-Reply-To: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com>
References: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com>
Message-ID: <Z8DFosZKbUT31IWqs5qGOj7sqOVM6NhMkCIhtRfb4aU=.389f8a84-0d27-4d8f-8144-588046280c70@github.com>

> Hi all,
> 
> Test java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out, because `lsof` invoke huast lots of time when the tested machine has many processes, and the processes open too many files.
> 
> This PR add parameter -p pid to `lsof`, which will only generate output from the wanted processes, rather than all the processes on the machine, this will make `lsof` use less time to finish significantly. And this PR also use `Process.waitFor(long timeout, TimeUnit unit)` instead of `waitFor()` which will avoid waitFor invoke cause test timed out. Delete the history lsof input and output files will make diagnosis more easy.
> 
> Change has been verifed locally. The imtermittent timed out do not observed anymore.

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

  Remove retry on destroyForcibly

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29478/files
  - new: https://git.openjdk.org/jdk/pull/29478/files/c4522418..ad1dd3b3

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

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

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

From syan at openjdk.org  Tue Feb  3 02:41:42 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Feb 2026 02:41:42 GMT
Subject: RFR: 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java
 intermittent timed out [v2]
In-Reply-To: <sFOByL-GF3xGYWBamz6OWnQ9LAj0P0XYjCfNshBj9qk=.5a821308-3146-4945-9737-bfb4ab184303@github.com>
References: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com>
 <NqXWOMOT0dajB18FxH40ECEcXIh_RGHDA7TGaq9tOFQ=.c4e9e470-7791-4f5b-a446-a99c84710ebd@github.com>
 <sFOByL-GF3xGYWBamz6OWnQ9LAj0P0XYjCfNshBj9qk=.5a821308-3146-4945-9737-bfb4ab184303@github.com>
Message-ID: <HkxVKifwUs4h5K09WMnLPalxLhvntcVhMkZy_bkOAq0=.6b07be56-f4b4-433f-9be5-7d52d5fe88ff@github.com>

On Mon, 2 Feb 2026 14:44:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert the change of lsof -p and only increase timeout value for test
>>  - Revert "8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out"
>>    
>>    This reverts commit 23d6dd1ae20bdd8957826f443a95bd4e69000eab.
>
> test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 243:
> 
>> 241:                 .start()) {
>> 242:             boolean status = p.waitFor(Utils.adjustTimeout(120), TimeUnit.SECONDS);
>> 243:             if (!status) {
> 
> Retry on destroyForcibly isn't necessary or productive. On Linux its equivalent to 'kill -9' and on Windows it isn't conditional.
> If there is a case where the a single call isn't effective, that should be reported as a bug against `destroyForcibly`.

Thanks for the detail explanations. The retry destroyForcibly has been removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29478#discussion_r2756912369

From almatvee at openjdk.org  Tue Feb  3 02:52:33 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 3 Feb 2026 02:52:33 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v7]
In-Reply-To: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
Message-ID: <ty3RpRbisGr8rMQUCRTiT6OMPNOIfrV1td1s_OYw1aw=.572c9d7b-1b5e-4c49-8a17-da96c658b193@github.com>

> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
> - Added test to cover added functionality.
> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.

Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge remote-tracking branch 'upstream/master' into JDK-8357404
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]
 - merge with upstream
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v5]
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v4]
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v3]
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2]
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified

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

Changes: https://git.openjdk.org/jdk/pull/29260/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=06
  Stats: 496 lines in 15 files changed: 450 ins; 12 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/29260.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29260/head:pull/29260

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

From jbhateja at openjdk.org  Tue Feb  3 03:31:52 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 3 Feb 2026 03:31:52 GMT
Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass
 them to intrinsic entries [v7]
In-Reply-To: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
References: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
Message-ID: <kDaABPfdYICCDElAjcNrY1MR61aIQO58SdxFCgZfVRY=.de99cd78-43ef-4664-bd6c-641ed75d3173@github.com>

> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support.
> 
> Patch add new lane type constants and pass them to vector intrinsic entry points.
> 
> All existing Vector API jtreg test are passing with the patch.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

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

  Review comments resolution

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29481/files
  - new: https://git.openjdk.org/jdk/pull/29481/files/23022d42..c1935efc

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

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

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

From jbhateja at openjdk.org  Tue Feb  3 03:31:54 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 3 Feb 2026 03:31:54 GMT
Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass
 them to intrinsic entries [v6]
In-Reply-To: <bS7FMO43tYrUmkb9oYo0Qw3E7vlFOsryUrRactQIkgg=.40e929be-322f-444b-9e60-cd262ad3a4c6@github.com>
References: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
 <k118UMK3mVVIMcluzGrC-ZpVT0sYBhSKtgFhQlzGCjE=.2d61f6e0-e2d0-4906-8331-d27dc312a865@github.com>
 <bS7FMO43tYrUmkb9oYo0Qw3E7vlFOsryUrRactQIkgg=.40e929be-322f-444b-9e60-cd262ad3a4c6@github.com>
Message-ID: <1g1hwUyCoVEwQmSnil3tnLEbyNDXAUGkfPSz3R8lNAg=.ca6498cb-acec-4b00-9b38-a01e720046df@github.com>

On Mon, 2 Feb 2026 20:22:46 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment resolution
>
> Very good. Approved, there is just one comment related to adding a comment for the LT_* values. Thank you for separating this out from the float16 PR. Needs a HotSpot reviewer too. We will run it through tier 1 to 3 testing.

Thanks @PaulSandoz , @merykitty please let me know if this is good to land.

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

PR Comment: https://git.openjdk.org/jdk/pull/29481#issuecomment-3838835040

From smarks at openjdk.org  Tue Feb  3 06:00:04 2026
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 3 Feb 2026 06:00:04 GMT
Subject: RFR: 8170896: TEST_BUG:
 java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed
 with unreferenced() not invoked after 20.0 seconds [v7]
In-Reply-To: <CGWbwrY-zvY2hY8MpgLoGG75Y7_aIPB3lJNrTIUAO-8=.df8757e9-ed4c-469d-a53f-b3b9c32bd23b@github.com>
References: <hvMMGGyVBK5YY_jEmOYEih8GUPB1QYV77eZXGqWSyWc=.eba81e2c-549a-4d80-a32d-39db5a42bf35@github.com>
 <CGWbwrY-zvY2hY8MpgLoGG75Y7_aIPB3lJNrTIUAO-8=.df8757e9-ed4c-469d-a53f-b3b9c32bd23b@github.com>
Message-ID: <oqcHR1Diqbfr9-ZcEQ4gfxKFgsmYlIEUlfAZlRUCF1o=.bdc52d1f-edfa-4a66-8120-d976ab1f3548@github.com>

On Thu, 29 Jan 2026 10:40:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which addresses intermittent failures in `java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java`?
>> 
>> The `@summary` in that test's test definition about what this test does:
>> 
>>>  @summary When the "java.rmi.dgc.leaseValue" system property is set to a
>>>  value much lower than its default (10 minutes), then the server-side
>>>  user-visible detection of DGC lease expiration-- in the form of
>>>  Unreferenced.unreferenced() invocations and possibly even local garbage
>>>  collection (including weak reference notification, finalization, etc.)--
>>>  may be delayed longer than expected.  While this is not a spec violation
>>>  (because there are no timeliness guarantees for any of these garbage
>>>  collection-related events), the user might expect that an unreferenced()
>>>  invocation for an object whose last client has terminated abnormally
>>>  should occur on relatively the same time order as the lease value
>>>  granted.
>> 
>> In its current form, the test uses a lease expiry of 10 seconds, launches a trivial `java` application which looks up the bound object from the registry and then terminates itself. After launching that trivial java application, the test then waits for 20 seconds, expecting that the `Unreferenced.unreferenced()` callback (upon lease expiry of 10 seconds) will be called within those 20 seconds. This wait intermittently fails because the `Unreferenced.unreferenced()` doesn't get called within those 20 seconds. 
>> 
>> Experiments show that the reason for these intermittent failures is due to the `SelfTerminator` application which does the registry lookup (and which involves connection establishment and communication over a socket) can sometimes take several seconds (5 or more for example). That effectively means that by the time this `SelfTerminator` starts its termination after the lookup, it's already several seconds into the "wait()" in the test.
>> 
>> The commit in this PR cleans up the test to more accurately track the duration of how long it took between the lease expiry and the `Unreferenced.unreferenced()` callback to be invoked. Additionally, just to make the test more robust, the maximum expected duration has been increased to 60 seconds instead of 20 seconds. Given the text in the test's summary, I think this increase is still within the expectations of how long it takes for the callback to be invoked after the client has exited abnormally.
>> 
>> The test continue...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   print the configured lease expiry time in the test

Marked as reviewed by smarks (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28919#pullrequestreview-3743133434

From smarks at openjdk.org  Tue Feb  3 06:00:07 2026
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 3 Feb 2026 06:00:07 GMT
Subject: RFR: 8170896: TEST_BUG:
 java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed
 with unreferenced() not invoked after 20.0 seconds [v6]
In-Reply-To: <15VbURLxrSteSR3dOlZxhT5wk5c0pBGLN6jkXQzNuoc=.d65ed2de-50cc-44da-8534-072a8f125af4@github.com>
References: <hvMMGGyVBK5YY_jEmOYEih8GUPB1QYV77eZXGqWSyWc=.eba81e2c-549a-4d80-a32d-39db5a42bf35@github.com>
 <5K3QplZHL8hWIrPPOk1iRFVrvtVR5yBRkkYFv4i0xCU=.9f851648-7359-41bf-9320-63e56147ae39@github.com>
 <15VbURLxrSteSR3dOlZxhT5wk5c0pBGLN6jkXQzNuoc=.d65ed2de-50cc-44da-8534-072a8f125af4@github.com>
Message-ID: <zvN4fM4SB4Q0DESXP47q-4QV_O2dR2NSTe61QY0ojOQ=.bb802c04-6fcb-40cc-9711-d2686cbbbedb@github.com>

On Thu, 29 Jan 2026 10:25:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> 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 nine additional commits since the last revision:
>> 
>>  - Stuart's review - no need to write start time in a file
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - Mark's suggestion - move the duration check to separate method
>>  - merge latest from master branch
>>  - Mark's review - use CountDownLatch
>>  - merge latest from master branch
>>  - 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds
>
> Thank you Stuart for the review.
> 
>> The observation is that the timeout logic is entirely within the parent JVM. The child's role is simply to obtain a lease and halt immediately. The parent JVM could be changed to call JavaVM.waitFor() to await the child's termination and to obtain a timestamp. This would remove the need to create a temporary file into which the child writes a timestamp from which the parent reads the timestamp. In addition, waitFor() allows the parent to check the child's exit status and signal an error if the status is nonzero.
>>
>> I guess one could argue that having the child obtain the timestamp immediately after the registry call is closer to the beginning of the actual lease. However, I don't think this makes much of a practical difference. 
> 
> What you suggest is reasonable and simpler as well. I've updated the PR to remove the part where we used to write the start time to a file and then read it.
> 
> With the updated log messages in this PR, I think if this continues to fail intermittently, we will have some useful log messages which can then help us decide if we have to track the start time more closely in the SelfTerminator process.
> 
> 
>> Another small cleanup item: is it necessary to have a @modules declaration in the test? I don't see anything in the test that uses RMI internals. (The Test Library might need this stuff, though, not sure.)
> 
> I gave that a try, but turns out the call to a test library class in this test:
> 
>> TestLibrary.getRegistryPort(localRegistry);
> 
> requires the use of these explicit "--add-exports" (through the `@modules`) because `TestLibrary` references those internal classes.

@jaikiran Thanks for the updates.

Thanks for checking the `@modules` declaration. Yeah, the RMI test library does require some of that stuff after all.

Regarding the timestamp cleanup, yes, this looks good. One thing to consider is when to get the start timestamp. The current code gets it after the subprocess was started. An alternative is to get the timestamp after the subprocess has exited. Which is better? Not sure.

The start timestamp is trying to represent the time at which the DGC lease was obtained. To do this accurately we'd have to instrument the DGC code in the parent JVM. This seems like it's too intrusive though. Getting the timestamp (a) after the child has started or (b) after the child has exited are only approximations to this. The timestamp (a) is potentially too early, as we don't know how long it will actually take for the child to start up and obtain the lease. Thus, the measured time (a) might be too long. The timestamp (b) is potentially too late, as the child had previously obtained the timestamp and has exited, and the parent has been notified, before it gets the timestamp. Thus, the measured time (b) might be too short.

Maybe this makes no practical difference, but our CI environment is hostile enough that sometimes I'm startled by how long it takes to do something like forking a child process.

If the problem is that the test times out spuriously, it may be reasonable to consider moving the timestamp to (b) after the child has exited, so that the chance of spurious timeouts is reduced. However it's probably not worth fiddling around with this more at the moment. Let's just integrate this and if it works, great. But if the test continues to fail intermittently, maybe consider moving the start timestamp along with other possible adjustments.

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

PR Comment: https://git.openjdk.org/jdk/pull/28919#issuecomment-3839226368

From vyazici at openjdk.org  Tue Feb  3 06:20:08 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 3 Feb 2026 06:20:08 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v5]
In-Reply-To: <bDkndly51pLDHZIMCACnfcLuq-ZOvLfEMZdsfptGmEE=.ddd2890c-2654-45d7-b35a-aaf98a845b2a@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <bDkndly51pLDHZIMCACnfcLuq-ZOvLfEMZdsfptGmEE=.ddd2890c-2654-45d7-b35a-aaf98a845b2a@github.com>
Message-ID: <aoZo-3eVtJmgxEPxvF0kI2grODGBhoED8wNGitUNdnI=.856bef05-816b-47e7-b6f1-7be706737195@github.com>

On Mon, 2 Feb 2026 22:05:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @requires condition

Marked as reviewed by vyazici (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/29493#pullrequestreview-3743204451

From dholmes at openjdk.org  Tue Feb  3 06:56:04 2026
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Feb 2026 06:56:04 GMT
Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for
 all cases [v3]
In-Reply-To: <DvrFBzS_aVm41CQTzgtnDeA2qi7CCjFB1kk5E6acq3s=.11ef918a-c8e9-4d8f-a72b-47316c6de159@github.com>
References: <sbp120wZjbJcEpyWDT9It7wFl_zU1kXNiHz7QMkd6RA=.46fa522d-104a-4c6f-a18f-cb0f8f37cad4@github.com>
 <dlRikUE-BmPRKGwktctuYer4xb6xVcZi0_Fy-0dy4p8=.110195ec-3422-4748-a583-0ecdabe54f93@github.com>
 <sUJpxyA4MilPQprGD61BTvaHcXLLBWuxBHeCy2TzvlI=.f4992798-3254-4920-bd1a-4dd817f09be9@github.com>
 <6WdkzWF-d6yGLKVUP9pCiYE1ghOdL5sTlcBiA1bE4c0=.802606b6-f958-4dea-a6a7-3d8a406c177c@github.com>
 <DvrFBzS_aVm41CQTzgtnDeA2qi7CCjFB1kk5E6acq3s=.11ef918a-c8e9-4d8f-a72b-47316c6de159@github.com>
Message-ID: <G3CSP4g35Bc-qgydgRL93JvKD-_AtOn_JDEdNmrK2xM=.45e7394d-3c5f-475c-9083-198850d60bdc@github.com>

On Fri, 30 Jan 2026 08:07:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Still not clear to me why any new thread is not already filtered out long before now; nor why we have not needed this in the past.
>
> We want ThreadSnapshot.of(Thread) to accept a Thread in any state. Existing behavior is to return null for platform threads that are not alive. For virtual threads it will return a snapshot so we want to change that. The ThreadNotAlive test in the PR allows us to test these cases as they are hard to demonstrate with the thread dump.
> 
> ThreadSnapshot.of(Thread) does not filter out the "not alive" cases. It could, in which case ThreadSnapshotFactory::get_thread_snapshot would need to assert if called with a new/unstarted thread. The terminating thread case would still need to be handled by ThreadSnapshotFactory::get_thread_snapshot. For platform threads there is no JavaThread so it bails easy. For virtual threads it needs to examine the state. Would you prefer if ThreadSnapshot.of(Thread) pre-checked the state so that get_thread_snapshot could be guaranteed to never see a new/unstarted thread?
>  
> Update: I changed ThreadSnapshot.of(Thread) to filter before calling get_thread_snapshot, hopefully this will be easier to understand.

I was assuming/expecting that the top-level code in `ThreadDumper` would filter out not-alive threads the same way `Thread.getStackTrace` does. You don't want lower-level code to have to worry about NEW threads, though of course they still have to deal with races against termination.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2757501486

From alanb at openjdk.org  Tue Feb  3 08:31:13 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Feb 2026 08:31:13 GMT
Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for
 all cases [v3]
In-Reply-To: <G3CSP4g35Bc-qgydgRL93JvKD-_AtOn_JDEdNmrK2xM=.45e7394d-3c5f-475c-9083-198850d60bdc@github.com>
References: <sbp120wZjbJcEpyWDT9It7wFl_zU1kXNiHz7QMkd6RA=.46fa522d-104a-4c6f-a18f-cb0f8f37cad4@github.com>
 <dlRikUE-BmPRKGwktctuYer4xb6xVcZi0_Fy-0dy4p8=.110195ec-3422-4748-a583-0ecdabe54f93@github.com>
 <sUJpxyA4MilPQprGD61BTvaHcXLLBWuxBHeCy2TzvlI=.f4992798-3254-4920-bd1a-4dd817f09be9@github.com>
 <6WdkzWF-d6yGLKVUP9pCiYE1ghOdL5sTlcBiA1bE4c0=.802606b6-f958-4dea-a6a7-3d8a406c177c@github.com>
 <DvrFBzS_aVm41CQTzgtnDeA2qi7CCjFB1kk5E6acq3s=.11ef918a-c8e9-4d8f-a72b-47316c6de159@github.com>
 <G3CSP4g35Bc-qgydgRL93JvKD-_AtOn_JDEdNmrK2xM=.45e7394d-3c5f-475c-9083-198850d60bdc@github.com>
Message-ID: <o9ssvXXkCfY-NbRKb6WureV3GHwSbePXGsKSWAtxpjo=.04b30ab9-76eb-4928-a32c-106147337182@github.com>

On Tue, 3 Feb 2026 06:53:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We want ThreadSnapshot.of(Thread) to accept a Thread in any state. Existing behavior is to return null for platform threads that are not alive. For virtual threads it will return a snapshot so we want to change that. The ThreadNotAlive test in the PR allows us to test these cases as they are hard to demonstrate with the thread dump.
>> 
>> ThreadSnapshot.of(Thread) does not filter out the "not alive" cases. It could, in which case ThreadSnapshotFactory::get_thread_snapshot would need to assert if called with a new/unstarted thread. The terminating thread case would still need to be handled by ThreadSnapshotFactory::get_thread_snapshot. For platform threads there is no JavaThread so it bails easy. For virtual threads it needs to examine the state. Would you prefer if ThreadSnapshot.of(Thread) pre-checked the state so that get_thread_snapshot could be guaranteed to never see a new/unstarted thread?
>>  
>> Update: I changed ThreadSnapshot.of(Thread) to filter before calling get_thread_snapshot, hopefully this will be easier to understand.
>
> I was assuming/expecting that the top-level code in `ThreadDumper` would filter out not-alive threads the same way `Thread.getStackTrace` does. You don't want lower-level code to have to worry about NEW threads, though of course they still have to deal with races against termination.

The proposal is that ThreadSnapshot.of(Thread) can be called with any platform or virtual Thread in any state. With the update, it eagerly tests with isAlive so will filter NEW and already TERMINATED threads. If/when we change Thread.getStackTrace to use ThreadSnapshot then the isAlive check can be dropped from Thread.getStackTrace. The underlying implementation in get_thread_snapshot does not need to deal with the NEW state.

There is no need for ThreadDumper to do any additional filtering. The thread streams that it consumes filter Threads that are not alive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2757854181

From aartemov at openjdk.org  Tue Feb  3 09:10:09 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 3 Feb 2026 09:10:09 GMT
Subject: RFR: 8376665: Port fdlibm acosh to Java [v2]
In-Reply-To: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
References: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
Message-ID: <sb_vMaBBoGc8XvwTNF8spvn395LXznFgQlwrBzN1RCU=.ee68145f-488d-4a45-ba7f-c5abd378e97d@github.com>

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM acosh method.
> 
> Original C vs transliteration port:
> 
> 
> $ diff -w fdlib_acosh.c.txt Acosh.translit.java
> 1c1,3
> < /* __ieee754_acosh(x)
> ---
>> /**
>>  * Return the Inverse Hyperbolic Cosine of x
>>  *
> 7,8c9,10
> <  *            acosh(x) := log(2x-1/(sqrt(x*x-1)+x)) if x>2; else
> <  *            acosh(x) := log1p(t+sqrt(2.0*t+t*t)); where t=x-1.
> ---
>>  *            := log(2x-1/(sqrt(x*x-1)+x)) if x>2; else
>>  *            := log1p(t+sqrt(2.0*t+t*t)); where t=x-1.
> 14,31c16,19
> <
> < #include "fdlibm.h"
> <
> < #ifdef __STDC__
> < static const double
> < #else
> < static double
> < #endif
> < one   = 1.0,
> < ln2   = 6.93147180559945286227e-01;  /* 0x3FE62E42, 0xFEFA39EF */
> <
> < #ifdef __STDC__
> <       double __ieee754_acosh(double x)
> < #else
> <       double __ieee754_acosh(x)
> <       double x;
> < #endif
> < {
> ---
>> private static final class Acosh {
>>       private static final double one = 1.0;
>>       private static final double ln2 = 6.93147180559945286227e-01;
>>       static double compute(double x) {
> 41c29
> <               return __ieee754_log(x)+ln2;    /* acosh(huge)=log(2x) */
> ---
>>                               return log(x)+ln2;   /* acosh(huge)=log(2x) */
> 46c34
> <           return __ieee754_log(2.0*x-one/(x+sqrt(t-one)));
> ---
>>                       return log(2.0*x-one/(x+sqrt(t-one)));
> 49a38
>>               }
> 
> 
> 
> Transliteration vs more idiomatic port:
> 
> $ diff -w Acosh.translit.java Acosh.fdlibm.java
> 5,7c5,9
> <  * Based on
> <  *  acosh(x) = log [ x + sqrt(x*x-1) ]
> <  *  we have
> ---
>>  *
>>  *
>>  *      acosh(x) is defined so that acosh(cosh(alpha)) = alpha, -INF < alpha < < INF
>>  *      and cosh(acosh(x)) = x, 1 <= x  < INF.
>>  *      It can be written as acosh(x) = ln(x + sqrt(x^2 - 1)), 1 <= x  < INF.
> 11a14,15
>>  *
>>  *
> 16,17c20
> < private static final class Acosh {
> <       private static final double one = 1.0;
> ---
>> static final class Acosh {
> 18a22
>>
> 23c27
> <               if(hx<0x3ff00000) {      /* x < 1 */
> ---
>>               if(hx < 0x3ff00000) {                           // x < 1 */
> 25,26c29,30
> <               } else if(hx >=0x41b00000) {    /* x > 2**28 */
> <                       if(hx >=0x7ff00000) {    /* x is inf of NaN */
> ---
>>               } else if (hx >= 0x41b00000) {                  // x > 2**28
>>                       if(hx >= 0x7ff00000) {                      // x is inf of NaN
> 28,29c32,34
> <                       } else
> <                               return log(x)+ln2;   /* acosh(huge)=log(2x) *...

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

  8376665: Fixed range, added special test case.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29488/files
  - new: https://git.openjdk.org/jdk/pull/29488/files/a70da053..44147eb7

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

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

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

From jpai at openjdk.org  Tue Feb  3 09:35:44 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Feb 2026 09:35:44 GMT
Subject: RFR: 8170896: TEST_BUG:
 java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed
 with unreferenced() not invoked after 20.0 seconds [v6]
In-Reply-To: <zvN4fM4SB4Q0DESXP47q-4QV_O2dR2NSTe61QY0ojOQ=.bb802c04-6fcb-40cc-9711-d2686cbbbedb@github.com>
References: <hvMMGGyVBK5YY_jEmOYEih8GUPB1QYV77eZXGqWSyWc=.eba81e2c-549a-4d80-a32d-39db5a42bf35@github.com>
 <5K3QplZHL8hWIrPPOk1iRFVrvtVR5yBRkkYFv4i0xCU=.9f851648-7359-41bf-9320-63e56147ae39@github.com>
 <15VbURLxrSteSR3dOlZxhT5wk5c0pBGLN6jkXQzNuoc=.d65ed2de-50cc-44da-8534-072a8f125af4@github.com>
 <zvN4fM4SB4Q0DESXP47q-4QV_O2dR2NSTe61QY0ojOQ=.bb802c04-6fcb-40cc-9711-d2686cbbbedb@github.com>
Message-ID: <0POzjK3LvlGnVzVfnNTopGZ5VS7GQNYL8FSiBiKY45A=.a9904e21-9516-4a99-827a-fcb64b4bb9c6@github.com>

On Tue, 3 Feb 2026 05:56:54 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> However it's probably not worth fiddling around with this more at the moment. Let's just integrate this and if it works, great. But if the test continues to fail intermittently, maybe consider moving the start timestamp along with other possible adjustments.

That sounds good to me too Stuart. Some of the important log messages we have introduced in this PR include a timestamp, so if this does fail the next time, we will have some additional details that can help us decide any further changes.

Thank you everyone for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28919#issuecomment-3840164575

From jpai at openjdk.org  Tue Feb  3 09:38:12 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Feb 2026 09:38:12 GMT
Subject: Integrated: 8170896: TEST_BUG:
 java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed
 with unreferenced() not invoked after 20.0 seconds
In-Reply-To: <hvMMGGyVBK5YY_jEmOYEih8GUPB1QYV77eZXGqWSyWc=.eba81e2c-549a-4d80-a32d-39db5a42bf35@github.com>
References: <hvMMGGyVBK5YY_jEmOYEih8GUPB1QYV77eZXGqWSyWc=.eba81e2c-549a-4d80-a32d-39db5a42bf35@github.com>
Message-ID: <P5GomvHG4RgqmNZ3ZmsNLIDUymeF1eGAb4ngY_uZJzQ=.8a146d73-9d6b-48f8-b854-ec828946f2c9@github.com>

On Fri, 19 Dec 2025 07:41:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which addresses intermittent failures in `java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java`?
> 
> The `@summary` in that test's test definition about what this test does:
> 
>>  @summary When the "java.rmi.dgc.leaseValue" system property is set to a
>>  value much lower than its default (10 minutes), then the server-side
>>  user-visible detection of DGC lease expiration-- in the form of
>>  Unreferenced.unreferenced() invocations and possibly even local garbage
>>  collection (including weak reference notification, finalization, etc.)--
>>  may be delayed longer than expected.  While this is not a spec violation
>>  (because there are no timeliness guarantees for any of these garbage
>>  collection-related events), the user might expect that an unreferenced()
>>  invocation for an object whose last client has terminated abnormally
>>  should occur on relatively the same time order as the lease value
>>  granted.
> 
> In its current form, the test uses a lease expiry of 10 seconds, launches a trivial `java` application which looks up the bound object from the registry and then terminates itself. After launching that trivial java application, the test then waits for 20 seconds, expecting that the `Unreferenced.unreferenced()` callback (upon lease expiry of 10 seconds) will be called within those 20 seconds. This wait intermittently fails because the `Unreferenced.unreferenced()` doesn't get called within those 20 seconds. 
> 
> Experiments show that the reason for these intermittent failures is due to the `SelfTerminator` application which does the registry lookup (and which involves connection establishment and communication over a socket) can sometimes take several seconds (5 or more for example). That effectively means that by the time this `SelfTerminator` starts its termination after the lookup, it's already several seconds into the "wait()" in the test.
> 
> The commit in this PR cleans up the test to more accurately track the duration of how long it took between the lease expiry and the `Unreferenced.unreferenced()` callback to be invoked. Additionally, just to make the test more robust, the maximum expected duration has been increased to 60 seconds instead of 20 seconds. Given the text in the test's summary, I think this increase is still within the expectations of how long it takes for the callback to be invoked after the client has exited abnormally.
> 
> The test continues to pass with this change and a te...

This pull request has now been integrated.

Changeset: efa16e9e
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/efa16e9e5fb07088ef2e0f2509e40fd97e4141d1
Stats:     95 lines in 2 files changed: 43 ins; 26 del; 26 mod

8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds

Reviewed-by: smarks, msheppar, dfuchs

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

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

From jpai at openjdk.org  Tue Feb  3 10:12:20 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Feb 2026 10:12:20 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v5]
In-Reply-To: <bDkndly51pLDHZIMCACnfcLuq-ZOvLfEMZdsfptGmEE=.ddd2890c-2654-45d7-b35a-aaf98a845b2a@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <bDkndly51pLDHZIMCACnfcLuq-ZOvLfEMZdsfptGmEE=.ddd2890c-2654-45d7-b35a-aaf98a845b2a@github.com>
Message-ID: <HWDb93lF_ujtoiVFjGzezGdRPU_VISRMjHvPm_EqKkQ=.d14f3c3d-e7aa-4acb-a3c6-14f378457ea6@github.com>

On Mon, 2 Feb 2026 22:05:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @requires condition

test/jdk/java/io/Console/ReadWriteBlockingTest.java line 51:

> 49:     public void testReadWriteBlocking() throws Exception {
> 50:         // check "expect" command availability
> 51:         var expect = Paths.get("/usr/bin/expect");

Nit - in recent times we have been using `Path.of(...)` instead of `Paths.get(...)`. `Paths.get(...)` is specified to merely invoke `Path.of(...)`.

test/jdk/java/io/Console/ReadWriteBlockingTest.java line 61:

> 59:         var jdkDir = System.getProperty("test.jdk");
> 60:         OutputAnalyzer output = ProcessTools.executeProcess(
> 61:             "expect",

Hello Naoto, is it intentional that we check for the presence of `/usr/bin/expect` but then rely on `PATH` when launching the `expect` process? Should this instead be `/usr/bin/expect`?

test/jdk/java/io/Console/ReadWriteBlockingTest.java line 66:

> 64:             jdkDir + "/bin/java",
> 65:             "-classpath", testClasses,
> 66:             "ReadWriteBlockingTest");

I think it's an oversight that the `-Djdk.console=jdk.internal.le` system property is being set in the `@run` of this test definition instead of being passed here to the launched `java` application. I think the test might have to be refactored a bit to have one single `@run ....` and then here in the test method launch the `java` main() with and without that system property.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2758247326
PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2758256127
PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2758281246

From jpai at openjdk.org  Tue Feb  3 10:19:41 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Feb 2026 10:19:41 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v5]
In-Reply-To: <bDkndly51pLDHZIMCACnfcLuq-ZOvLfEMZdsfptGmEE=.ddd2890c-2654-45d7-b35a-aaf98a845b2a@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <bDkndly51pLDHZIMCACnfcLuq-ZOvLfEMZdsfptGmEE=.ddd2890c-2654-45d7-b35a-aaf98a845b2a@github.com>
Message-ID: <imyzoMhw3fx4cuDJiZI_Gi2lfS3UWg5pEd-YxnKcZDc=.578a9cad-e0d8-4e41-af17-df3ea34214b3@github.com>

On Mon, 2 Feb 2026 22:05:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @requires condition

test/jdk/java/io/Console/ReadWriteBlockingTest.java line 76:

> 74:             try {
> 75:                 // give some time for main thread to invoke readLine()
> 76:                 Thread.sleep(1000);

Instead of `Thread.sleep(...)` would it be better to do something like (untested code):


var con = System.console();
CountDownLatch latch = new CountDownLatch(2);

Thread.ofVirtual().start(() -> {
    try {
        latch.countDown(); // announce our arrival
        try {
            latch.await(); // wait for other thread to arrive
        } catch (InterruptedException _) {
            // ignore
        }
        con.printf("printf() invoked");
    } catch (Throwable t) {
        t.printStackTrace();
        throw t;
    }
});

latch.countDown(); // announce our arrival
latch.await(); // wait for other thread to arrive
con.readLine("");

That way the chances to the read and write threads racing, increases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2758313096

From jpai at openjdk.org  Tue Feb  3 10:40:05 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Feb 2026 10:40:05 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v5]
In-Reply-To: <bDkndly51pLDHZIMCACnfcLuq-ZOvLfEMZdsfptGmEE=.ddd2890c-2654-45d7-b35a-aaf98a845b2a@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <bDkndly51pLDHZIMCACnfcLuq-ZOvLfEMZdsfptGmEE=.ddd2890c-2654-45d7-b35a-aaf98a845b2a@github.com>
Message-ID: <BwKGfxN0wMW0mCDMgiqOIAwzyUw0vHkQKdLWVjNibGw=.b32a5122-e8ed-4fbd-b0fc-eebed6fe0e7d@github.com>

On Mon, 2 Feb 2026 22:05:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @requires condition

src/java.base/share/classes/java/io/ProxyingConsole.java line 40:

> 38:  */
> 39: @ValueBased
> 40: final class ProxyingConsole extends Console {

I am not familiar with `@ValueBased` and I just read up its documentation. Based on what it says about constructors https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/doc-files/ValueBased.html#L48:

> the class does not declare (or has deprecated any) accessible constructors

since `ProxyingConsole` declares a `ProxyingConsole(JdkConsole delegate)` constructor, does it still qualify as a `@ValueBased` class?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2758406203

From jpai at openjdk.org  Tue Feb  3 10:50:43 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Feb 2026 10:50:43 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v5]
In-Reply-To: <bDkndly51pLDHZIMCACnfcLuq-ZOvLfEMZdsfptGmEE=.ddd2890c-2654-45d7-b35a-aaf98a845b2a@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <bDkndly51pLDHZIMCACnfcLuq-ZOvLfEMZdsfptGmEE=.ddd2890c-2654-45d7-b35a-aaf98a845b2a@github.com>
Message-ID: <QYcWPJZ3Pvfr-x83kOHGicJDHYoWmCQlPa-q-jAY5g4=.05550896-c451-4c70-abf8-9b2d3d51b059@github.com>

On Mon, 2 Feb 2026 22:05:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @requires condition

test/jdk/java/io/Console/readWriteBlocking.exp line 27:

> 25: eval spawn $argv
> 26: 
> 27: expect {

More of a question than a review, given what this regression test is for - detecting a deadlock in `Console` API implementation, is the use of `expect` tool necessary for this test? Or could the test just ensure that the launched `java` application completes normally after the two threads read/write using the `Console` instance?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2758454581

From dholmes at openjdk.org  Tue Feb  3 11:07:51 2026
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Feb 2026 11:07:51 GMT
Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for
 all cases [v3]
In-Reply-To: <o9ssvXXkCfY-NbRKb6WureV3GHwSbePXGsKSWAtxpjo=.04b30ab9-76eb-4928-a32c-106147337182@github.com>
References: <sbp120wZjbJcEpyWDT9It7wFl_zU1kXNiHz7QMkd6RA=.46fa522d-104a-4c6f-a18f-cb0f8f37cad4@github.com>
 <dlRikUE-BmPRKGwktctuYer4xb6xVcZi0_Fy-0dy4p8=.110195ec-3422-4748-a583-0ecdabe54f93@github.com>
 <sUJpxyA4MilPQprGD61BTvaHcXLLBWuxBHeCy2TzvlI=.f4992798-3254-4920-bd1a-4dd817f09be9@github.com>
 <6WdkzWF-d6yGLKVUP9pCiYE1ghOdL5sTlcBiA1bE4c0=.802606b6-f958-4dea-a6a7-3d8a406c177c@github.com>
 <DvrFBzS_aVm41CQTzgtnDeA2qi7CCjFB1kk5E6acq3s=.11ef918a-c8e9-4d8f-a72b-47316c6de159@github.com>
 <G3CSP4g35Bc-qgydgRL93JvKD-_AtOn_JDEdNmrK2xM=.45e7394d-3c5f-475c-9083-198850d60bdc@github.com>
 <o9ssvXXkCfY-NbRKb6WureV3GHwSbePXGsKSWAtxpjo=.04b30ab9-76eb-4928-a32c-106147337182@github.com>
Message-ID: <J6KotdlOTsUcVHjsI2rEuFpV4bvmLhxz2gjRABPzvoc=.2e48e967-2ee9-4fed-a36a-938ae3bd5bc3@github.com>

On Tue, 3 Feb 2026 08:28:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There is no need for ThreadDumper to do any additional filtering. The thread streams that it consumes filter out Threads that are not alive.

Okay that is not at all obvious. But in that case you are never passing a NEW thread to `ThreadSnapshot.of()`. But if that is to be the primary API for getting stacktraces then having it filter on isAlive is reasonable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2758520184

From alanb at openjdk.org  Tue Feb  3 12:04:40 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Feb 2026 12:04:40 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v23]
In-Reply-To: <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
Message-ID: <Qo7hKF39XC0HuHoizEOI_me6l5BFk4nPV4zA-2NtrIk=.40ac0cbf-3206-49f6-880f-fcb26e4e9e8c@github.com>

On Sun, 1 Feb 2026 12:55:29 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 two additional commits since the last revision:
> 
>  - Add comment
>  - Fix logic error

src/java.base/share/classes/java/lang/String.java line 1886:

> 1884:      * @since 27
> 1885:      */
> 1886:     public int codePointCount() {

Are you planning to override the API docs here to say that it returns the number of Unicode code points in this String? That would get the API docs consistent with the existing 3-arg codePointCount and avoid referencing the String as a character sequence in the String docs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2758723775

From jbhateja at openjdk.org  Tue Feb  3 12:56:52 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 3 Feb 2026 12:56:52 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v12]
In-Reply-To: <EUYLcTJ-tPZabk2LcLzwYne6MgOdrQ7PDqkx6lOvsJs=.7c5a65d0-0efc-4636-843d-93815f327a25@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <YbIRslmURu8J4TLXTCHEeo7F3IwpvGPiYMDA-6w7_xA=.386a3af7-73ac-42f2-9e05-d34c436872a7@github.com>
 <BCaFfmFgSFPW0kPql80L-9Uic7tu5fwpnXBLpn9uyP8=.b184ac3f-faac-4062-9b15-ad07ac5fe0c0@github.com>
 <EUYLcTJ-tPZabk2LcLzwYne6MgOdrQ7PDqkx6lOvsJs=.7c5a65d0-0efc-4636-843d-93815f327a25@github.com>
Message-ID: <vcDvy5nhpl-bE3zC6vlyQ-0_Ds5VyIAmW-r8YQUSFjM=.5e5f6537-f28a-4864-8f01-09eb7da7a254@github.com>

On Mon, 26 Jan 2026 17:43:41 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> LGTM! Thanks for your updating!
>
>> Hi @XiaohongGong , your comments have been addressed. Hi @sviswa7, can you kindly review x86 part.
> 
> Thanks @jatin-bhateja. I will take a look next week.

Hi @sviswa7 , Please let me know if you have comments on x86 backend part.

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

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3841145292

From duke at openjdk.org  Tue Feb  3 13:30:41 2026
From: duke at openjdk.org (David Beaumont)
Date: Tue, 3 Feb 2026 13:30:41 GMT
Subject: RFR: 8377070: Migrate preview mode support for jimage to mainline
Message-ID: <hrFvapR-FfjUfX5TBKowIxO6Xfac9eOaWOc7JtyVtVo=.c3e88771-0ac9-44c7-a415-916d3f76ac80@github.com>

Implementation of preview-mode support for jimage modules file, migrated from Valhalla related work (see JDK-8352750).

This PR (the first of several) migrates work from Valhalla (lworld) to the JDK mainline repository in relation to "preview mode" support. It affects the creation and reading of the jimage file, both in Java (BasicImageReader/ImageReader) and C++ (imageFile.xpp/jimage.xpp).

Preview mode is a mechanism by which alternate version of JDK class files and resources can be made available for class loading and reflection when the '--enable-preview' flag is passed to the runtime.

Alternate classes/resource appear in each module under the:

/<module>/META-INF/preview/<path-to>/<resource-or-class>

and replace the original:

/<module>/<path-to>/<resource-or-class>

files when preview mode is enabled.

While initially useful for Valhalla work, this mechanism will be used for other cases where preview features (in the JEP 12 sense) require alternate classes/resources to be provided. None of the changes in this (or the follow-up PRs) are Valhalla specific.

In this PR:
* the writing of jimage files is modified to recognize and handle preview mode paths
* flags in the jimage file are added or modified to support preview mode efficiently
* (C++) the class loader is modified to permit reading preview versions of classes
* (Java) the image reader and associated JRT file-system classes are modified to permit reading preview files
* unit tests are added to ensure preview mode works as expected when enabled
* (temporary) any code calling into the affected API (other than tests) specifies that preview mode is disabled

Future PRs will add the plumbing to enable preview mode correctly, but with the PR there should be no observable change in behaviour (especially since no preview classes or resources are being supplied at this point).

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

Commit messages:
 - Merge branch 'master' into jimage_preview_mode
 - undo exploded image changes for now
 - Add new files too (oops)
 - Patched jimage preview mode support from lworld

Changes: https://git.openjdk.org/jdk/pull/29414/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29414&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377070
  Stats: 3074 lines in 37 files changed: 2060 ins; 588 del; 426 mod
  Patch: https://git.openjdk.org/jdk/pull/29414.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29414/head:pull/29414

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

From duke at openjdk.org  Tue Feb  3 13:30:43 2026
From: duke at openjdk.org (David Beaumont)
Date: Tue, 3 Feb 2026 13:30:43 GMT
Subject: RFR: 8377070: Migrate preview mode support for jimage to mainline
In-Reply-To: <hrFvapR-FfjUfX5TBKowIxO6Xfac9eOaWOc7JtyVtVo=.c3e88771-0ac9-44c7-a415-916d3f76ac80@github.com>
References: <hrFvapR-FfjUfX5TBKowIxO6Xfac9eOaWOc7JtyVtVo=.c3e88771-0ac9-44c7-a415-916d3f76ac80@github.com>
Message-ID: <NfWiT89EbUsQCeFaBc9af-axHuJgehBwRw-5U3gvM00=.36d5bff0-935a-463f-ad62-75228884e886@github.com>

On Mon, 26 Jan 2026 12:42:06 GMT, David Beaumont <duke at openjdk.org> wrote:

> Implementation of preview-mode support for jimage modules file, migrated from Valhalla related work (see JDK-8352750).
> 
> This PR (the first of several) migrates work from Valhalla (lworld) to the JDK mainline repository in relation to "preview mode" support. It affects the creation and reading of the jimage file, both in Java (BasicImageReader/ImageReader) and C++ (imageFile.xpp/jimage.xpp).
> 
> Preview mode is a mechanism by which alternate version of JDK class files and resources can be made available for class loading and reflection when the '--enable-preview' flag is passed to the runtime.
> 
> Alternate classes/resource appear in each module under the:
> 
> /<module>/META-INF/preview/<path-to>/<resource-or-class>
> 
> and replace the original:
> 
> /<module>/<path-to>/<resource-or-class>
> 
> files when preview mode is enabled.
> 
> While initially useful for Valhalla work, this mechanism will be used for other cases where preview features (in the JEP 12 sense) require alternate classes/resources to be provided. None of the changes in this (or the follow-up PRs) are Valhalla specific.
> 
> In this PR:
> * the writing of jimage files is modified to recognize and handle preview mode paths
> * flags in the jimage file are added or modified to support preview mode efficiently
> * (C++) the class loader is modified to permit reading preview versions of classes
> * (Java) the image reader and associated JRT file-system classes are modified to permit reading preview files
> * unit tests are added to ensure preview mode works as expected when enabled
> * (temporary) any code calling into the affected API (other than tests) specifies that preview mode is disabled
> 
> Future PRs will add the plumbing to enable preview mode correctly, but with the PR there should be no observable change in behaviour (especially since no preview classes or resources are being supplied at this point).

src/hotspot/share/classfile/classLoader.cpp line 246:

> 244:   jint error;
> 245:   JImage_file = (*JImageOpen)(modules_path, &error);
> 246:   if (Arguments::has_jimage() && JImage_file == nullptr) {

Error check added to mainline but refactored here for simplicity (these functions are intended to encapsulate this sort of thing).

src/hotspot/share/classfile/classLoader.cpp line 1420:

> 1418:   jio_snprintf(modules_path, JVM_MAXPATHLEN, "%s%slib%smodules", Arguments::get_java_home(), fileSep, fileSep);
> 1419:   JImage_file =(*JImageOpen)(modules_path, &error);
> 1420:   if (JImage_file == nullptr) {

This check was moved into jimage_open().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29414#discussion_r2758662629
PR Review Comment: https://git.openjdk.org/jdk/pull/29414#discussion_r2758667570

From msheppar at openjdk.org  Tue Feb  3 13:38:01 2026
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 3 Feb 2026 13:38:01 GMT
Subject: RFR: 8170896: TEST_BUG:
 java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed
 with unreferenced() not invoked after 20.0 seconds [v7]
In-Reply-To: <CGWbwrY-zvY2hY8MpgLoGG75Y7_aIPB3lJNrTIUAO-8=.df8757e9-ed4c-469d-a53f-b3b9c32bd23b@github.com>
References: <hvMMGGyVBK5YY_jEmOYEih8GUPB1QYV77eZXGqWSyWc=.eba81e2c-549a-4d80-a32d-39db5a42bf35@github.com>
 <CGWbwrY-zvY2hY8MpgLoGG75Y7_aIPB3lJNrTIUAO-8=.df8757e9-ed4c-469d-a53f-b3b9c32bd23b@github.com>
Message-ID: <YwKIRUL3xZp1aXneibAD3yBClzxO1k-Y8Fhn68ysAHw=.ce33d80d-f3e4-4f28-bcf9-3c801758ca20@github.com>

On Thu, 29 Jan 2026 10:40:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which addresses intermittent failures in `java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java`?
>> 
>> The `@summary` in that test's test definition about what this test does:
>> 
>>>  @summary When the "java.rmi.dgc.leaseValue" system property is set to a
>>>  value much lower than its default (10 minutes), then the server-side
>>>  user-visible detection of DGC lease expiration-- in the form of
>>>  Unreferenced.unreferenced() invocations and possibly even local garbage
>>>  collection (including weak reference notification, finalization, etc.)--
>>>  may be delayed longer than expected.  While this is not a spec violation
>>>  (because there are no timeliness guarantees for any of these garbage
>>>  collection-related events), the user might expect that an unreferenced()
>>>  invocation for an object whose last client has terminated abnormally
>>>  should occur on relatively the same time order as the lease value
>>>  granted.
>> 
>> In its current form, the test uses a lease expiry of 10 seconds, launches a trivial `java` application which looks up the bound object from the registry and then terminates itself. After launching that trivial java application, the test then waits for 20 seconds, expecting that the `Unreferenced.unreferenced()` callback (upon lease expiry of 10 seconds) will be called within those 20 seconds. This wait intermittently fails because the `Unreferenced.unreferenced()` doesn't get called within those 20 seconds. 
>> 
>> Experiments show that the reason for these intermittent failures is due to the `SelfTerminator` application which does the registry lookup (and which involves connection establishment and communication over a socket) can sometimes take several seconds (5 or more for example). That effectively means that by the time this `SelfTerminator` starts its termination after the lookup, it's already several seconds into the "wait()" in the test.
>> 
>> The commit in this PR cleans up the test to more accurately track the duration of how long it took between the lease expiry and the `Unreferenced.unreferenced()` callback to be invoked. Additionally, just to make the test more robust, the maximum expected duration has been increased to 60 seconds instead of 20 seconds. Given the text in the test's summary, I think this increase is still within the expectations of how long it takes for the callback to be invoked after the client has exited abnormally.
>> 
>> The test continue...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   print the configured lease expiry time in the test

test/jdk/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java line 102:

> 100:             // creating the condition for a lease expiry).
> 101:             jvm.start();
> 102:             final Instant startTime = Instant.now();

apologies for the late comment after integration 

I think this timestamp would have been better taken after the the sub process has been reaped, i.e. after the jvm.waitFor(), as this will indicate that the "lease mechanism" has been activated. As such, the test is about the timely activation of the "lease processing". By taking the timestamp after the subprocess join, it is the absolute point indicating that lease process should have taken place.

There is the potential for some very lengthy delays in the round trip invocation of the SelfTerminator subprocess. That is, 
there is the time for launching the subprocess and the time for reaping the subporcess (procesing SIGCHILD) etc. Both of these can be relatively lengthy, depending on the load of a system, and the CI pipeline can has plenty of variablility.

In any case the "timeout durtaion" has been increased, which should mitigate the launch and reaper variability

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28919#discussion_r2759120221

From myankelevich at openjdk.org  Tue Feb  3 14:23:13 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 3 Feb 2026 14:23:13 GMT
Subject: RFR: 8377063: Add EchoPassword.java to manual group
Message-ID: <aGlMUvvPuOdYezDWpPpGNNNjgx5ptSjLZqBrCUXWB1Q=.873c56f0-7b4b-47ab-b946-3927cc7f2009@github.com>

Added EchoPassword.java to a security manual group

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

Commit messages:
 - JDK-8377063: Add EchoPassword.java to manual group

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

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

From kfarrell at openjdk.org  Tue Feb  3 14:29:33 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Tue, 3 Feb 2026 14:29:33 GMT
Subject: RFR: 8359706: Add file descriptor count to VM.info [v9]
In-Reply-To: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
References: <a1HhcupsCROYETAf5X3Gbz5WqojDYbwjMcR4ZKx7uGI=.bedae8d1-08e8-426e-b073-5e207e18573a@github.com>
Message-ID: <GpsVN7UWYXQB5Ho02llNKs-zd31sgNrjgp4wNxI49JE=.51c6d6d3-bf77-457a-afbc-c57f45dff0c8@github.com>

> Currently, it is only possible to read the number of open file descriptors of a Java process via the `UnixOperatingSystemMXBean` which is only accessible via JMX enabled tools. To improve servicability, it would be benifical to be able to view this information from jcmd VM.info output or hs_err_pid crash logs. This could help diagnose resource exhaustion and troubleshoot "too many open files" errors in Java processes on Unix platforms.
> 
> This PR adds reporting the current open file descriptor count to both jcmd VM.info output or hs_err_pid crash logs by refactoring the native JNI logic from `Java_com_sun_management_internal_OperatingSystemImpl_getOpenFileDescriptorCount0` of the `UnixOperatingSystemMXBean` into hotspot. Apple's API for retrieving open file descriptor count provides an array of the actual FDs to determine the count. To avoid using `malloc` to store this array in a potential signal handling context where stack space may be limited, the apple implementation instead allocates a fixed 32KB struct on the stack to store the open FDs and only reports the result if the struct is less than the max (1024 FDs). This should cover the majoirty of use cases.

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

  update test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27971/files
  - new: https://git.openjdk.org/jdk/pull/27971/files/926fc920..e9ed58ad

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

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

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

From rgiulietti at openjdk.org  Tue Feb  3 14:45:38 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 3 Feb 2026 14:45:38 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v6]
In-Reply-To: <bmbeeFjqHyafsodO2lP5Jrll5EkLzk7KBAw5abnaYio=.9a231fce-2ee9-4080-93ab-5d9ef54a0915@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <bmbeeFjqHyafsodO2lP5Jrll5EkLzk7KBAw5abnaYio=.9a231fce-2ee9-4080-93ab-5d9ef54a0915@github.com>
Message-ID: <dxWIp-tMsVvqDAmOtYPBFNMXZyuX-5bC956EuqnHU9s=.af382f1a-d0f1-440c-9f45-673d14bea4c3@github.com>

On Thu, 29 Jan 2026 12:01:46 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM asinh method.
>> 
>> Original C vs transliteration port:
>> 
>> 
>> $ diff -w fdlib_asinh.c Asinh.translit.java
>> 1c1,3
>> < /* asinh(x)
>> ---
>>> /**
>>> * Return the Inverse Hyperbolic Sine of x
>>> *
>> 2a5
>>> *
>> 10a14,17
>>> private static final class Asinh {
>>>       private static final double one = 1.0;
>>>       private static final double ln2 = 6.93147180559945286227e-01;
>>>       private static final double huge = 1.0e300;
>> 12,29c19
>> < #include "fdlibm.h"
>> <
>> < #ifdef __STDC__
>> < static const double
>> < #else
>> < static double
>> < #endif
>> < one =  1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */
>> < ln2 =  6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */
>> < huge=  1.00000000000000000000e+300;
>> <
>> < #ifdef __STDC__
>> <       double asinh(double x)
>> < #else
>> <       double asinh(x)
>> <       double x;
>> < #endif
>> < {
>> ---
>>>       static double compute(double x) {
>> 39c29
>> <           w = __ieee754_log(fabs(x))+ln2;
>> ---
>>>                       w = log(Math.abs(x))+ln2;
>> 41,42c31,32
>> <           t = fabs(x);
>> <           w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t));
>> ---
>>>                       t = Math.abs(x);
>>>                       w = log(2.0*t+one/(sqrt(x*x+one)+t));
>> 45c35
>> <           w =log1p(fabs(x)+t/(one+sqrt(one+t)));
>> ---
>>>                       w =log1p(Math.abs(x)+t/(one+sqrt(one+t)));
>> 47a38
>>>       }
>> 
>> Transliteration port vs more idiomatic port:
>> 
>> 
>> $ diff -w Asinh.translit.java Asinh.fdlibm.java
>> 6,9c6,12
>> < *  Based on
>> < *    asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ]
>> < *   we have
>> < *   asinh(x) := x  if  1+x*x=1,
>> ---
>>>  *
>>>  *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF
>>>  *      and sinh(asinh(x)) = x, -INF < x  < INF.
>>>  *      It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x  < INF.
>>>  *      1. Replace x by |x| as the function is odd.
>>>  *      2.
>>>  *          asinh(x) := x, if 1+x^2 = 1,
>> 12a16,22
>>>  *
>>>  *
>>>  *
>>>  * Special cases:
>>>  *      only asinh(0)=0 is exact for finite x.
>>>  *      asinh(NaN) is NaN
>>>  *      asinh(INF) is INF
>> 14,15c24
>> < private static final class Asinh {
>> <       private static final double one = 1.0;
>> ---
>>> static final class Asinh {
>> 24c33,35
>> <               if(ix>=0x7ff00000) return x+x;  /* x is inf or NaN */
>> ---
>>>               if(ix >= 0x7ff00000) {
>>>                       return x...
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8375285: Added missed link in documentation.

Will review the test code in another round.

src/java.base/share/classes/java/lang/FdLibm.java line 3518:

> 3516:      *
> 3517:      *
> 3518:      *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha, -INF < alpha < < INF

Suggestion:

     *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha, -&infin; &lt; alpha &lt; &infin;

&infin; looks better
&lt; avoids confusing an HTML parser (not sure if it really needed, though)

src/java.base/share/classes/java/lang/FdLibm.java line 3519:

> 3517:      *
> 3518:      *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha, -INF < alpha < < INF
> 3519:      *      and sinh(asinh(x)) = x, -INF < x  < INF.

Similarly

src/java.base/share/classes/java/lang/FdLibm.java line 3520:

> 3518:      *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha, -INF < alpha < < INF
> 3519:      *      and sinh(asinh(x)) = x, -INF < x  < INF.
> 3520:      *      It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x  < INF.

This is not the formulation in the original fdlibm code.

src/java.base/share/classes/java/lang/FdLibm.java line 3531:

> 3529:      *
> 3530:      * Special cases:
> 3531:      *      only asinh(0)=0 is exact for finite x.

Suggestion:

     *      only asinh(&plusmn;0) = &plusmn;0 is exact for finite x.

src/java.base/share/classes/java/lang/FdLibm.java line 3533:

> 3531:      *      only asinh(0)=0 is exact for finite x.
> 3532:      *      asinh(NaN) is NaN
> 3533:      *      asinh(INF) is INF

Suggestion:

     *      asinh(&plusmn;&infin;) = &plusmn;&infin;

src/java.base/share/classes/java/lang/FdLibm.java line 3543:

> 3541:             int hx, ix;
> 3542:             hx = __HI(x);
> 3543:             ix = hx & 0x7fffffff;

Suggestion:

            ix = hx & 0x7fff_ffff;

as well as other hexadecimal literals below. It's easier for counting whether the number of hex digits is correct.

src/java.base/share/classes/java/lang/Math.java line 2765:

> 2763:      * The inverse hyperbolic sine of <i>x</i> is defined to be a function such that
> 2764:      *  asinh({@linkplain Math#sinh sinh(<i>x</i>)}) = <i>x</i> for any <i>x</i>.
> 2765:      *  Note that range of the exact asinh is not limited.

Suggestion:

     *  Note that domain of the exact asinh is unrestricted.

src/java.base/share/classes/java/lang/Math.java line 2777:

> 2775:      * <li>If the argument is negative infinity, then the result is
> 2776:      * negative infinity.
> 2777:      *

It is possible to collapse both items into one, as is done for the zero case.

src/java.base/share/classes/java/lang/StrictMath.java line 2197:

> 2195:      * @return  The inverse hyperbolic sine of {@code x}.
> 2196:      * @since 27
> 2197:      */

See the comment for Math

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

PR Review: https://git.openjdk.org/jdk/pull/29273#pullrequestreview-3745650028
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2759404605
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2759404841
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2759405044
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2759405227
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2759405470
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2759405711
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2759415326
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2759415580
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2759419099

From alanb at openjdk.org  Tue Feb  3 14:48:49 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Feb 2026 14:48:49 GMT
Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for
 all cases [v3]
In-Reply-To: <J6KotdlOTsUcVHjsI2rEuFpV4bvmLhxz2gjRABPzvoc=.2e48e967-2ee9-4fed-a36a-938ae3bd5bc3@github.com>
References: <sbp120wZjbJcEpyWDT9It7wFl_zU1kXNiHz7QMkd6RA=.46fa522d-104a-4c6f-a18f-cb0f8f37cad4@github.com>
 <dlRikUE-BmPRKGwktctuYer4xb6xVcZi0_Fy-0dy4p8=.110195ec-3422-4748-a583-0ecdabe54f93@github.com>
 <sUJpxyA4MilPQprGD61BTvaHcXLLBWuxBHeCy2TzvlI=.f4992798-3254-4920-bd1a-4dd817f09be9@github.com>
 <6WdkzWF-d6yGLKVUP9pCiYE1ghOdL5sTlcBiA1bE4c0=.802606b6-f958-4dea-a6a7-3d8a406c177c@github.com>
 <DvrFBzS_aVm41CQTzgtnDeA2qi7CCjFB1kk5E6acq3s=.11ef918a-c8e9-4d8f-a72b-47316c6de159@github.com>
 <G3CSP4g35Bc-qgydgRL93JvKD-_AtOn_JDEdNmrK2xM=.45e7394d-3c5f-475c-9083-198850d60bdc@github.com>
 <o9ssvXXkCfY-NbRKb6WureV3GHwSbePXGsKSWAtxpjo=.04b30ab9-76eb-4928-a32c-106147337182@github.com>
 <J6KotdlOTsUcVHjsI2rEuFpV4bvmLhxz2gjRABPzvoc=.2e48e967-2ee9-4fed-a36a-938ae3bd5bc3@github.com>
Message-ID: <Jg__j3dlIwv_TlodGjNe6XrbNtA9jE2YssOxPKfcrg4=.aaba21b4-8e8a-4d1c-ac67-f0a19aab9137@github.com>

On Tue, 3 Feb 2026 11:04:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The proposal is that ThreadSnapshot.of(Thread) can be called with any platform or virtual Thread in any state. With the update, it eagerly tests with isAlive so will filter out NEW and already TERMINATED threads. If/when we change Thread.getStackTrace to use ThreadSnapshot then the isAlive check can be dropped from Thread.getStackTrace. The underlying implementation in get_thread_snapshot does not need to deal with the NEW state.
>> 
>> There is no need for ThreadDumper to do any additional filtering. The thread streams that it consumes filter out Threads that are not alive.
>
>> There is no need for ThreadDumper to do any additional filtering. The thread streams that it consumes filter out Threads that are not alive.
> 
> Okay that is not at all obvious. But in that case you are never passing a NEW thread to `ThreadSnapshot.of()`. But if that is to be the primary API for getting stacktraces then having it filter on isAlive is reasonable.

The thread stream is documented to be a stream of "live" threads and the implementations filter out unstarted or already terminated threads.

If I read your latest message correctly then I think you are agreement with the current chnage to test isAlive at the "front door". It means get_thread_snapshot is never called with an unstarted/NEW Thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2759456977

From syan at openjdk.org  Tue Feb  3 15:16:40 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Feb 2026 15:16:40 GMT
Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted
 [v6]
In-Reply-To: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
References: <sWDh7tRPf-Jwf45yW6ylMUReRZOB8tJIASogCDEETGg=.73ddb2dd-5538-4c0e-8675-3492a7cfa2c0@github.com>
Message-ID: <o_M3wQJCxQnux3qoM1-5-rO1Hx9CK3GY8osgG_1zgVs=.4ce470b3-902e-4f84-aa40-c9b760f234e2@github.com>

> Hi all,
> 
> Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the cpuset unmounted. The details shows in jbs issue. I think it's better to check the 'cpu period' or 'cpuset' available or not before run the releated tests.
> 
> Change has been verified locally. Test-fix only, no risk.

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

 - Merge branch 'openjdk:master' into jbs8374364
 - Update comment "If cgroups is not configured, the test is skipped." which suggestion from @dholmes-ora
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update copyright year for test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java
 - Check cpu period and cpuset avaialable before test
 - Fix year
 - Move DockerTestUtils.checkCanTestDocker() inside MetricsTester
 - 8374364: TestCgroupMetrics.java fails when docker service unavailable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28996/files
  - new: https://git.openjdk.org/jdk/pull/28996/files/8e2ee419..109302e5

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

  Stats: 130803 lines in 3552 files changed: 62581 ins; 31208 del; 37014 mod
  Patch: https://git.openjdk.org/jdk/pull/28996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28996/head:pull/28996

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

From msheppar at openjdk.org  Tue Feb  3 16:33:22 2026
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 3 Feb 2026 16:33:22 GMT
Subject: RFR: 8377063: Add EchoPassword.java to manual group
In-Reply-To: <aGlMUvvPuOdYezDWpPpGNNNjgx5ptSjLZqBrCUXWB1Q=.873c56f0-7b4b-47ab-b946-3927cc7f2009@github.com>
References: <aGlMUvvPuOdYezDWpPpGNNNjgx5ptSjLZqBrCUXWB1Q=.873c56f0-7b4b-47ab-b946-3927cc7f2009@github.com>
Message-ID: <oFNqT9l7zjIFHekkTlqQ7YEiWbhjJOYQcw6U4r_ntdc=.71ba2428-42c4-41ad-b1f1-542b8aa9da7a@github.com>

On Tue, 3 Feb 2026 14:14:45 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Added EchoPassword.java to a security manual group

FWIW ... LGTM

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

Marked as reviewed by msheppar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29544#pullrequestreview-3746281127

From naoto at openjdk.org  Tue Feb  3 16:53:34 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Feb 2026 16:53:34 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v23]
In-Reply-To: <Qo7hKF39XC0HuHoizEOI_me6l5BFk4nPV4zA-2NtrIk=.40ac0cbf-3206-49f6-880f-fcb26e4e9e8c@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
 <Qo7hKF39XC0HuHoizEOI_me6l5BFk4nPV4zA-2NtrIk=.40ac0cbf-3206-49f6-880f-fcb26e4e9e8c@github.com>
Message-ID: <0nrxPt9EBTADN3jACynCXe6V3kf0duVrvdT-mcD-nqo=.a0764e66-8f41-4632-aa88-4bdd163e9e79@github.com>

On Tue, 3 Feb 2026 11:59:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tatsunori Uchino has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add comment
>>  - Fix logic error
>
> src/java.base/share/classes/java/lang/String.java line 1886:
> 
>> 1884:      * @since 27
>> 1885:      */
>> 1886:     public int codePointCount() {
> 
> Are you planning to override the API docs here to say that it returns the number of Unicode code points in this String? That would get the API docs consistent with the existing 3-arg codePointCount and avoid referencing the String as a character sequence in the String docs.

That was my suggestion to remove the text, as the generated javadoc apparently shows the text is from CharSequence. It sure does replacing the CharSequence with String aligns with the other method, but it also introduces copying the almost identical text, which could introduce editorial left over if CharSequence text changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2760034348

From rriggs at openjdk.org  Tue Feb  3 17:27:45 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 3 Feb 2026 17:27:45 GMT
Subject: RFR: 8375585: Test java/lang/ProcessBuilder/PipelineLeaksFD.java
 failed [v2]
In-Reply-To: <RcWyeLjeptkC1ZUDvTukbnTXkeCPIOJtseYAcfk3jA8=.41f33014-ff91-431c-83a1-4595edb05669@github.com>
References: <RcWyeLjeptkC1ZUDvTukbnTXkeCPIOJtseYAcfk3jA8=.41f33014-ff91-431c-83a1-4595edb05669@github.com>
Message-ID: <6MiTFQRyjzZydLbwtLE9fIHC6PT53A1OCQo60eim8bc=.e26f2357-018d-430e-b918-f4c7969bee49@github.com>

> Revised test to explicitly compare file descriptor info only from parent and child.
> If additional fd's are present in the child, it is hard to know their origin but they do not necessarily indicate a bug in Process launch.
>  
> Remove from the problem list.

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

  Refactor checks of child pipe use against parent use.
  Removed simple counts of names as they were unreliable.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29530/files
  - new: https://git.openjdk.org/jdk/pull/29530/files/d42ee5b3..0cf0611f

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

  Stats: 39 lines in 1 file changed: 15 ins; 4 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/29530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29530/head:pull/29530

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

From naoto at openjdk.org  Tue Feb  3 17:36:16 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Feb 2026 17:36:16 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v6]
In-Reply-To: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
Message-ID: <AohEOd7EEzMghYCyyRBjkuRKqsoC4IizImiuBNaCjBU=.ad10b6ab-561b-4cfb-b323-be25732029c5@github.com>

> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.

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

 - Reflects Jai's review comments
 - Merge branch 'master' into JDK-8340830-Console-readLine-printf-mutually-blocking
 - Added @requires condition
 - added jline test run
 - Merge branch 'master' into JDK-8340830-Console-readLine-printf-mutually-blocking
 - Fixed indentation
 - Made ProxyingConsole value-based, used anonymous class for LazyConstant
 - Refine exceptions
 - initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29493/files
  - new: https://git.openjdk.org/jdk/pull/29493/files/4c065425..7edf566e

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

  Stats: 15055 lines in 186 files changed: 5176 ins; 3137 del; 6742 mod
  Patch: https://git.openjdk.org/jdk/pull/29493.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29493/head:pull/29493

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

From rriggs at openjdk.org  Tue Feb  3 17:40:16 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 3 Feb 2026 17:40:16 GMT
Subject: RFR: 8375585: Test java/lang/ProcessBuilder/PipelineLeaksFD.java
 failed [v3]
In-Reply-To: <RcWyeLjeptkC1ZUDvTukbnTXkeCPIOJtseYAcfk3jA8=.41f33014-ff91-431c-83a1-4595edb05669@github.com>
References: <RcWyeLjeptkC1ZUDvTukbnTXkeCPIOJtseYAcfk3jA8=.41f33014-ff91-431c-83a1-4595edb05669@github.com>
Message-ID: <epBcVRtBXQkUQFxN0xfVEp1dsXecHTA859GwQL8AOkc=.801d2702-3ac3-4145-85b2-d71f092cf08a@github.com>

> Revised test to explicitly compare file descriptor info only from parent and child.
> If additional fd's are present in the child, it is hard to know their origin but they do not necessarily indicate a bug in Process launch.
>  
> Remove from the problem list.

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

  Removed use of count.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29530/files
  - new: https://git.openjdk.org/jdk/pull/29530/files/0cf0611f..a3e8b8b7

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

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

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

From naoto at openjdk.org  Tue Feb  3 17:44:15 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Feb 2026 17:44:15 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v6]
In-Reply-To: <AohEOd7EEzMghYCyyRBjkuRKqsoC4IizImiuBNaCjBU=.ad10b6ab-561b-4cfb-b323-be25732029c5@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <AohEOd7EEzMghYCyyRBjkuRKqsoC4IizImiuBNaCjBU=.ad10b6ab-561b-4cfb-b323-be25732029c5@github.com>
Message-ID: <LMcHxYemhq1I_p0LmzdgFw-AATTfDCbYOezax0SZK7Y=.977b5230-1ff1-47ac-9439-0818af013a2d@github.com>

On Tue, 3 Feb 2026 17:36:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.
>
> 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 nine additional commits since the last revision:
> 
>  - Reflects Jai's review comments
>  - Merge branch 'master' into JDK-8340830-Console-readLine-printf-mutually-blocking
>  - Added @requires condition
>  - added jline test run
>  - Merge branch 'master' into JDK-8340830-Console-readLine-printf-mutually-blocking
>  - Fixed indentation
>  - Made ProxyingConsole value-based, used anonymous class for LazyConstant
>  - Refine exceptions
>  - initial commit

Thanks, Jai. I addressed your points in the new commit.

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

PR Review: https://git.openjdk.org/jdk/pull/29493#pullrequestreview-3746621999

From naoto at openjdk.org  Tue Feb  3 17:44:21 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Feb 2026 17:44:21 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v5]
In-Reply-To: <BwKGfxN0wMW0mCDMgiqOIAwzyUw0vHkQKdLWVjNibGw=.b32a5122-e8ed-4fbd-b0fc-eebed6fe0e7d@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <bDkndly51pLDHZIMCACnfcLuq-ZOvLfEMZdsfptGmEE=.ddd2890c-2654-45d7-b35a-aaf98a845b2a@github.com>
 <BwKGfxN0wMW0mCDMgiqOIAwzyUw0vHkQKdLWVjNibGw=.b32a5122-e8ed-4fbd-b0fc-eebed6fe0e7d@github.com>
Message-ID: <foTeCYbjtM-KoZdAiNUsYl3fPfont1ZaHa5EuCO28MM=.e5a710b3-439e-4211-a08a-fe59e221fa1c@github.com>

On Tue, 3 Feb 2026 10:37:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added @requires condition
>
> src/java.base/share/classes/java/io/ProxyingConsole.java line 40:
> 
>> 38:  */
>> 39: @ValueBased
>> 40: final class ProxyingConsole extends Console {
> 
> I am not familiar with `@ValueBased` and I just read up its documentation. Based on what it says about constructors https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/doc-files/ValueBased.html#L48:
> 
>> the class does not declare (or has deprecated any) accessible constructors
> 
> since `ProxyingConsole` declares a `ProxyingConsole(JdkConsole delegate)` constructor, does it still qualify as a `@ValueBased` class?

I think that should be OK, as `ProxyingConsole` is a private class

> test/jdk/java/io/Console/ReadWriteBlockingTest.java line 66:
> 
>> 64:             jdkDir + "/bin/java",
>> 65:             "-classpath", testClasses,
>> 66:             "ReadWriteBlockingTest");
> 
> I think it's an oversight that the `-Djdk.console=jdk.internal.le` system property is being set in the `@run` of this test definition instead of being passed here to the launched `java` application. I think the test might have to be refactored a bit to have one single `@run ....` and then here in the test method launch the `java` main() with and without that system property.

Good catch! Thanks. The test was not running jline indeed. Now the system property is passed down to the java launcher so that the test correctly checks for both java.base and jline implementations. I think keeping the test run separately would help diagnose the jtreg logs.

> test/jdk/java/io/Console/readWriteBlocking.exp line 27:
> 
>> 25: eval spawn $argv
>> 26: 
>> 27: expect {
> 
> More of a question than a review, given what this regression test is for - detecting a deadlock in `Console` API implementation, is the use of `expect` tool necessary for this test? Or could the test just ensure that the launched `java` application completes normally after the two threads read/write using the `Console` instance?

Yes, it is necessary. Without running it through `expect`, `System.console()` returns null for java.base, as the jtreg environment is not an interactive terminal environment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2760219089
PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2760229748
PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2760223403

From jlu at openjdk.org  Tue Feb  3 19:11:35 2026
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Feb 2026 19:11:35 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v6]
In-Reply-To: <AohEOd7EEzMghYCyyRBjkuRKqsoC4IizImiuBNaCjBU=.ad10b6ab-561b-4cfb-b323-be25732029c5@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <AohEOd7EEzMghYCyyRBjkuRKqsoC4IizImiuBNaCjBU=.ad10b6ab-561b-4cfb-b323-be25732029c5@github.com>
Message-ID: <mtqV6A93xAK13_OcrzL_dgEAIhMTHUKasQIOM5xUV_E=.a64eeb95-37fc-424e-8b4b-a05d12ea8a0f@github.com>

On Tue, 3 Feb 2026 17:36:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.
>
> 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 nine additional commits since the last revision:
> 
>  - Reflects Jai's review comments
>  - Merge branch 'master' into JDK-8340830-Console-readLine-printf-mutually-blocking
>  - Added @requires condition
>  - added jline test run
>  - Merge branch 'master' into JDK-8340830-Console-readLine-printf-mutually-blocking
>  - Fixed indentation
>  - Made ProxyingConsole value-based, used anonymous class for LazyConstant
>  - Refine exceptions
>  - initial commit

test/jdk/java/io/Console/ReadWriteBlockingTest.java line 27:

> 25:  * @test
> 26:  * @bug 8340830
> 27:  * @summary Check if writing to Console is not blocked by other thread's read.

Should we make it apparent in the summary that this test is non-deterministic?

test/jdk/java/io/Console/ReadWriteBlockingTest.java line 78:

> 76:         CountDownLatch latch = new CountDownLatch(2);
> 77: 
> 78:         Thread.ofVirtual().start(() -> {

Based on the way this test is setup with _expect_, I think the previous testing code was actually better at detecting the issue at hand, since it "presumably" had a higher chance to `readLine` first. Given the old implementation, `readLine` would acquire the write lock unnecessarily, preventing `printf` from entering and executing, causing the test to fail since _expect_ would never receive the "printf() invoked" and never be able to provide input to `readLine`.

The new test "presumably" has equal chances to either read or write first. However, if the `printf` executes first, I don't see how the test will fail. With the old implementation, even if `printf` acquires the lock at first and `readLine` was blocked from entering, `printf` will eventually finish and release the lock, and provide the expected message to _expect_.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2760567760
PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2760540406

From jlu at openjdk.org  Tue Feb  3 19:11:36 2026
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Feb 2026 19:11:36 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v5]
In-Reply-To: <foTeCYbjtM-KoZdAiNUsYl3fPfont1ZaHa5EuCO28MM=.e5a710b3-439e-4211-a08a-fe59e221fa1c@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <bDkndly51pLDHZIMCACnfcLuq-ZOvLfEMZdsfptGmEE=.ddd2890c-2654-45d7-b35a-aaf98a845b2a@github.com>
 <BwKGfxN0wMW0mCDMgiqOIAwzyUw0vHkQKdLWVjNibGw=.b32a5122-e8ed-4fbd-b0fc-eebed6fe0e7d@github.com>
 <foTeCYbjtM-KoZdAiNUsYl3fPfont1ZaHa5EuCO28MM=.e5a710b3-439e-4211-a08a-fe59e221fa1c@github.com>
Message-ID: <6Haqf_DNAN7WoqLC1w4gJrzTVpsfKHL5D3pNneNDQ04=.3eccc65e-a990-4b09-8dbd-4c2a49b58dfc@github.com>

On Tue, 3 Feb 2026 17:39:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/io/Console/ReadWriteBlockingTest.java line 66:
>> 
>>> 64:             jdkDir + "/bin/java",
>>> 65:             "-classpath", testClasses,
>>> 66:             "ReadWriteBlockingTest");
>> 
>> I think it's an oversight that the `-Djdk.console=jdk.internal.le` system property is being set in the `@run` of this test definition instead of being passed here to the launched `java` application. I think the test might have to be refactored a bit to have one single `@run ....` and then here in the test method launch the `java` main() with and without that system property.
>
> Good catch! Thanks. The test was not running jline indeed. Now the system property is passed down to the java launcher so that the test correctly checks for both java.base and jline implementations. I think keeping the test run separately would help diagnose the jtreg logs.

A parameterized test with a string value source containing the two property values would also be a concise way to have helpful Jtreg logs if we wanted to keep it to a single `@run`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2760560771

From duke at openjdk.org  Tue Feb  3 19:12:43 2026
From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur)
Date: Tue, 3 Feb 2026 19:12:43 GMT
Subject: Integrated: 8370688: java.util.jar.JarEntry.getCodeSigners() and
 getCertificates() should specify that they return a copy of the arrays
In-Reply-To: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
References: <FVzcI0gAVPEDhfXcPP7XDXwGMSOj0PpThMkwfyAoB9A=.a6adff3a-a140-490a-8e45-a224cb241f4b@github.com>
Message-ID: <64wmA1PFvgjX2xQCuSMyPwy_aSP7v1t_7ECeBvJG1ec=.d03acbeb-ab50-47b0-969c-9c40562c907b@github.com>

On Tue, 2 Dec 2025 20:28:50 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this.

This pull request has now been integrated.

Changeset: 58d2edb9
Author:    Koushik Thirupattur <koushik.thirupattur at oracle.com>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/58d2edb9fc1bb68363e697b43be04c493ead81c5
Stats:     9 lines in 1 file changed: 4 ins; 0 del; 5 mod

8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays

Reviewed-by: jpai, mullan, liach

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

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

From rriggs at openjdk.org  Tue Feb  3 19:56:03 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 3 Feb 2026 19:56:03 GMT
Subject: RFR: 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java
 intermittent timed out [v3]
In-Reply-To: <Z8DFosZKbUT31IWqs5qGOj7sqOVM6NhMkCIhtRfb4aU=.389f8a84-0d27-4d8f-8144-588046280c70@github.com>
References: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com>
 <Z8DFosZKbUT31IWqs5qGOj7sqOVM6NhMkCIhtRfb4aU=.389f8a84-0d27-4d8f-8144-588046280c70@github.com>
Message-ID: <nisOWv9vgiSuyFKcN9ClHddSerTrVPRdYGZrRh1eKII=.e1e4d5c8-6089-458d-872a-b50ecdc357a3@github.com>

On Tue, 3 Feb 2026 02:41:41 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out, because `lsof` invoke huast lots of time when the tested machine has many processes, and the processes open too many files.
>> 
>> This PR add parameter -p pid to `lsof`, which will only generate output from the wanted processes, rather than all the processes on the machine, this will make `lsof` use less time to finish significantly. And this PR also use `Process.waitFor(long timeout, TimeUnit unit)` instead of `waitFor()` which will avoid waitFor invoke cause test timed out. Delete the history lsof input and output files will make diagnosis more easy.
>> 
>> Change has been verifed locally. The imtermittent timed out do not observed anymore.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove retry on destroyForcibly

Looks fine; thanks for the updates.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29478#pullrequestreview-3747265316

From rriggs at openjdk.org  Tue Feb  3 19:58:10 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 3 Feb 2026 19:58:10 GMT
Subject: RFR: 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java
 intermittent timed out [v3]
In-Reply-To: <Z8DFosZKbUT31IWqs5qGOj7sqOVM6NhMkCIhtRfb4aU=.389f8a84-0d27-4d8f-8144-588046280c70@github.com>
References: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com>
 <Z8DFosZKbUT31IWqs5qGOj7sqOVM6NhMkCIhtRfb4aU=.389f8a84-0d27-4d8f-8144-588046280c70@github.com>
Message-ID: <q3e8WOUstw54h6MO2Ub70OENyMJ2m48fA5ZD3VwhZfg=.6eca1712-58d5-435c-ac3e-0dc6e2795fe9@github.com>

On Tue, 3 Feb 2026 02:41:41 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out, because `lsof` invoke huast lots of time when the tested machine has many processes, and the processes open too many files.
>> 
>> This PR add parameter -p pid to `lsof`, which will only generate output from the wanted processes, rather than all the processes on the machine, this will make `lsof` use less time to finish significantly. And this PR also use `Process.waitFor(long timeout, TimeUnit unit)` instead of `waitFor()` which will avoid waitFor invoke cause test timed out. Delete the history lsof input and output files will make diagnosis more easy.
>> 
>> Change has been verifed locally. The imtermittent timed out do not observed anymore.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove retry on destroyForcibly

fyi, The PR for the other PipelineLeadFD failure is in review: #29530.

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

PR Comment: https://git.openjdk.org/jdk/pull/29478#issuecomment-3843348247

From naoto at openjdk.org  Tue Feb  3 20:03:30 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Feb 2026 20:03:30 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v7]
In-Reply-To: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
Message-ID: <24lzKxVAIEP5x6kKnicKq09nnBP25QChgQrFOKrD_nQ=.b77c20ae-c956-4e58-a13f-739d7e941e51@github.com>

> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.

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

  Reflects Justin's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29493/files
  - new: https://git.openjdk.org/jdk/pull/29493/files/7edf566e..fed88b18

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

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

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

From naoto at openjdk.org  Tue Feb  3 20:03:32 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Feb 2026 20:03:32 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v5]
In-Reply-To: <6Haqf_DNAN7WoqLC1w4gJrzTVpsfKHL5D3pNneNDQ04=.3eccc65e-a990-4b09-8dbd-4c2a49b58dfc@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <bDkndly51pLDHZIMCACnfcLuq-ZOvLfEMZdsfptGmEE=.ddd2890c-2654-45d7-b35a-aaf98a845b2a@github.com>
 <BwKGfxN0wMW0mCDMgiqOIAwzyUw0vHkQKdLWVjNibGw=.b32a5122-e8ed-4fbd-b0fc-eebed6fe0e7d@github.com>
 <foTeCYbjtM-KoZdAiNUsYl3fPfont1ZaHa5EuCO28MM=.e5a710b3-439e-4211-a08a-fe59e221fa1c@github.com>
 <6Haqf_DNAN7WoqLC1w4gJrzTVpsfKHL5D3pNneNDQ04=.3eccc65e-a990-4b09-8dbd-4c2a49b58dfc@github.com>
Message-ID: <TNSrlBPiqGqranDhWT-AjytdPW-oAerRQ15UtsfQPho=.a869d8da-6bde-4f83-811c-aff4e7520f88@github.com>

On Tue, 3 Feb 2026 19:01:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Good catch! Thanks. The test was not running jline indeed. Now the system property is passed down to the java launcher so that the test correctly checks for both java.base and jline implementations. I think keeping the test run separately would help diagnose the jtreg logs.
>
> A parameterized test with a string value source containing the two property values would also be a concise way to have helpful Jtreg logs if we wanted to keep it to a single `@run`.

Good point. Made it a single run with parameterized

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2760753745

From naoto at openjdk.org  Tue Feb  3 20:03:37 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Feb 2026 20:03:37 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v6]
In-Reply-To: <mtqV6A93xAK13_OcrzL_dgEAIhMTHUKasQIOM5xUV_E=.a64eeb95-37fc-424e-8b4b-a05d12ea8a0f@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <AohEOd7EEzMghYCyyRBjkuRKqsoC4IizImiuBNaCjBU=.ad10b6ab-561b-4cfb-b323-be25732029c5@github.com>
 <mtqV6A93xAK13_OcrzL_dgEAIhMTHUKasQIOM5xUV_E=.a64eeb95-37fc-424e-8b4b-a05d12ea8a0f@github.com>
Message-ID: <riAFN7HJc3RcIkB5UYpqbTdN8yoOVgpbl-oHObDMJzA=.d07050fe-5979-4b0b-9947-f532f3d99bad@github.com>

On Tue, 3 Feb 2026 18:55:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
>> 
>>  - Reflects Jai's review comments
>>  - Merge branch 'master' into JDK-8340830-Console-readLine-printf-mutually-blocking
>>  - Added @requires condition
>>  - added jline test run
>>  - Merge branch 'master' into JDK-8340830-Console-readLine-printf-mutually-blocking
>>  - Fixed indentation
>>  - Made ProxyingConsole value-based, used anonymous class for LazyConstant
>>  - Refine exceptions
>>  - initial commit
>
> test/jdk/java/io/Console/ReadWriteBlockingTest.java line 78:
> 
>> 76:         CountDownLatch latch = new CountDownLatch(2);
>> 77: 
>> 78:         Thread.ofVirtual().start(() -> {
> 
> Based on the way this test is setup with _expect_, I think the previous testing code was actually better at detecting the issue at hand, since it "presumably" had a higher chance to `readLine` first. Given the old implementation, `readLine` would acquire the write lock unnecessarily, preventing `printf` from entering and executing, causing the test to fail since _expect_ would never receive the "printf() invoked" and never be able to provide input to `readLine`.
> 
> The new test "presumably" has equal chances to either read or write first. However, if the `printf` executes first, I don't see how the test will fail. With the old implementation, even if `printf` acquires the lock at first and `readLine` was blocked from entering, `printf` will eventually finish and release the lock, and provide the expected message to _expect_.

Actually, I think the test is deterministic, even withouth any sleep/latch. The reason is that the wait is released with `expect` when it receives "printf() invoked" no matter which threads uses the console first. Removed the count down latch in the previous commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2760762631

From naoto at openjdk.org  Tue Feb  3 20:06:56 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Feb 2026 20:06:56 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v6]
In-Reply-To: <riAFN7HJc3RcIkB5UYpqbTdN8yoOVgpbl-oHObDMJzA=.d07050fe-5979-4b0b-9947-f532f3d99bad@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <AohEOd7EEzMghYCyyRBjkuRKqsoC4IizImiuBNaCjBU=.ad10b6ab-561b-4cfb-b323-be25732029c5@github.com>
 <mtqV6A93xAK13_OcrzL_dgEAIhMTHUKasQIOM5xUV_E=.a64eeb95-37fc-424e-8b4b-a05d12ea8a0f@github.com>
 <riAFN7HJc3RcIkB5UYpqbTdN8yoOVgpbl-oHObDMJzA=.d07050fe-5979-4b0b-9947-f532f3d99bad@github.com>
Message-ID: <_uNoqu4FM65eGXNIgX5r1is0qlcWdhxcDN3oSMERvtM=.de182ee5-662c-4092-95ef-fdae9977b1b1@github.com>

On Tue, 3 Feb 2026 19:59:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/io/Console/ReadWriteBlockingTest.java line 78:
>> 
>>> 76:         CountDownLatch latch = new CountDownLatch(2);
>>> 77: 
>>> 78:         Thread.ofVirtual().start(() -> {
>> 
>> Based on the way this test is setup with _expect_, I think the previous testing code was actually better at detecting the issue at hand, since it "presumably" had a higher chance to `readLine` first. Given the old implementation, `readLine` would acquire the write lock unnecessarily, preventing `printf` from entering and executing, causing the test to fail since _expect_ would never receive the "printf() invoked" and never be able to provide input to `readLine`.
>> 
>> The new test "presumably" has equal chances to either read or write first. However, if the `printf` executes first, I don't see how the test will fail. With the old implementation, even if `printf` acquires the lock at first and `readLine` was blocked from entering, `printf` will eventually finish and release the lock, and provide the expected message to _expect_.
>
> Actually, I think the test is deterministic, even withouth any sleep/latch. The reason is that the wait is released with `expect` when it receives "printf() invoked" no matter which threads uses the console first. Removed the count down latch in the previous commit.

OK, it is not. Will revert to the original, which has higher possibility.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2760780596

From naoto at openjdk.org  Tue Feb  3 20:15:13 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Feb 2026 20:15:13 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v8]
In-Reply-To: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
Message-ID: <VzTaqxMVJQQZDOG9xLi8w_ec7vDkQOYWCcJQkx8w3Ks=.0690d70f-09aa-4e35-99ba-9c03f6fc4d6f@github.com>

> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.

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

  Restores the original race condition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29493/files
  - new: https://git.openjdk.org/jdk/pull/29493/files/fed88b18..dc7ae4d4

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

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

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

From jlu at openjdk.org  Tue Feb  3 22:12:24 2026
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Feb 2026 22:12:24 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v8]
In-Reply-To: <VzTaqxMVJQQZDOG9xLi8w_ec7vDkQOYWCcJQkx8w3Ks=.0690d70f-09aa-4e35-99ba-9c03f6fc4d6f@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <VzTaqxMVJQQZDOG9xLi8w_ec7vDkQOYWCcJQkx8w3Ks=.0690d70f-09aa-4e35-99ba-9c03f6fc4d6f@github.com>
Message-ID: <ECOdBW2HMJdFaQM-UvmahjxNunx8ZjnPRzCQIPW33qk=.6a707af0-7f0c-4821-8295-ccb73ece1561@github.com>

On Tue, 3 Feb 2026 20:15:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restores the original race condition

Marked as reviewed by jlu (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29493#pullrequestreview-3747851526

From jlu at openjdk.org  Tue Feb  3 22:16:35 2026
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Feb 2026 22:16:35 GMT
Subject: RFR: 8377116: Refactor java/util/zip TestNG tests to JUnit
Message-ID: <QPduW9IIUl5rdWQ4uTQpnO_2yqX8E2sZO12uTEE2oaE=.40f85d49-bac5-4b73-88d2-4ff597a6ba46@github.com>

This PR consists of a conversion for the java/util/zip TestNG tests to JUnit. Changes are mainly automated. https://github.com/openjdk/jdk/commit/1aeb8a634b8f255853516015f4b39bd79dd94090 is required to resolve a failure since JUnit parameterized tests automatically close arguments that implement `AutoCloseable`.

Test stats before:
Framework-based tests: 274 = 107 TestNG + 167 JUnit

Test stats after:
Framework-based tests: 274 = 0 TestNG + 274 JUnit

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

Commit messages:
 - Update copyright years
 - Drop TestInstance.Lifecycle.PER_CLASS for default
 - Clean up imports
 - Modernize object[][]
 - Resolve auto close issue for CloseInflaterDeflaterTest.testZipCloseEntry
 - Apply automated conversion

Changes: https://git.openjdk.org/jdk/pull/29552/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29552&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377116
  Stats: 351 lines in 10 files changed: 74 ins; 41 del; 236 mod
  Patch: https://git.openjdk.org/jdk/pull/29552.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29552/head:pull/29552

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

From almatvee at openjdk.org  Tue Feb  3 23:04:47 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 3 Feb 2026 23:04:47 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <1HbJzaOksc5zJFxWpo3oyytyD7CRuY-pNlOQMyD3d-w=.bf3bf548-93fb-49ab-8f54-79684a498b70@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
 <1HbJzaOksc5zJFxWpo3oyytyD7CRuY-pNlOQMyD3d-w=.bf3bf548-93fb-49ab-8f54-79684a498b70@github.com>
Message-ID: <0Hww7ua0XsoqD1NrP_ID5SdvaYypvAyzN7pkw_bKLd8=.8f5139d1-50fa-4c36-a648-5ee6dd563654@github.com>

On Mon, 2 Feb 2026 20:00:21 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/RuntimeVersionReader.java line 38:
> 
>> 36: 
>> 37:     public static Optional<String> readVersion(Path releaseFilePath) throws IOException {
>> 38:         if (!Files.isRegularFile(releaseFilePath)) {
> 
> What is the point of this check? If you remove it and let the function throw an IOException, the function signature can be simplified to `String readVersion(Path releaseFilePath) throws IOException`. Making it clear that the function either returns a valid JDK version or throws.
> 
> If you don't want to deal with handling exceptions in the caller, you can implement it without throwing:
> 
> Optional<String> readVersion(Path releaseFilePath) {
>     try {
>         ...
>         return Optional.of(version);
>     } catch (IOException ex) {
>         return Optional.empty();
>     }
> }
> 
> Currently, it is a confusing mix of both approaches.

Will be implemented without throwing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2761396784

From rhalade at openjdk.org  Tue Feb  3 23:04:42 2026
From: rhalade at openjdk.org (Rajan Halade)
Date: Tue, 3 Feb 2026 23:04:42 GMT
Subject: RFR: 8377063: Add EchoPassword.java to manual group
In-Reply-To: <aGlMUvvPuOdYezDWpPpGNNNjgx5ptSjLZqBrCUXWB1Q=.873c56f0-7b4b-47ab-b946-3927cc7f2009@github.com>
References: <aGlMUvvPuOdYezDWpPpGNNNjgx5ptSjLZqBrCUXWB1Q=.873c56f0-7b4b-47ab-b946-3927cc7f2009@github.com>
Message-ID: <_3-OHoZ5H69GfNZj3XnTZhY3UR5H8ShWrcBM90if5-Y=.c0ab9f6f-cf09-41c0-856d-dc7f6863a1ac@github.com>

On Tue, 3 Feb 2026 14:14:45 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Added EchoPassword.java to a security manual group

Marked as reviewed by rhalade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29544#pullrequestreview-3748075062

From almatvee at openjdk.org  Tue Feb  3 23:08:54 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 3 Feb 2026 23:08:54 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <NEeBqEpKFRvjQg8rs2ropHOlKqpW_U6UpWbexU3p4Qg=.bf7bf267-2c59-44a0-9987-97b3bbabae59@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
 <NEeBqEpKFRvjQg8rs2ropHOlKqpW_U6UpWbexU3p4Qg=.bf7bf267-2c59-44a0-9987-97b3bbabae59@github.com>
Message-ID: <YK-Ugiw4bfPm4RQlBzu47oxqvArpgn_9j_NZI-jIbzY=.23e52b9c-41cb-4f28-8791-9712dd6f2fb1@github.com>

On Mon, 2 Feb 2026 20:03:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/RuntimeVersionReader.java line 47:
> 
>> 45:             String version = props.getProperty("JAVA_VERSION");
>> 46:             if (version != null) {
>> 47:                 version = version.replaceAll("^\"|\"$", "");
> 
> Why does this function filter the value of the "JAVA_VERSION" property?
> 
> It should not do any filtering; it should just read the value as its name suggests.
> 
> Filering is platform-specific and should be a separate method.

For some reason `JAVA_VERSION` is set to quoted string and `getProperty()` will return `"27"` instead of `27`. I think `"` is not truly part of version string and `replaceAll()` removes it. I do not think that removing leading and trailing `"` should be platform specific.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2761418265

From almatvee at openjdk.org  Tue Feb  3 23:18:13 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 3 Feb 2026 23:18:13 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <NEeBqEpKFRvjQg8rs2ropHOlKqpW_U6UpWbexU3p4Qg=.bf7bf267-2c59-44a0-9987-97b3bbabae59@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
 <NEeBqEpKFRvjQg8rs2ropHOlKqpW_U6UpWbexU3p4Qg=.bf7bf267-2c59-44a0-9987-97b3bbabae59@github.com>
Message-ID: <5TLrb0kJHNkxOHjwwkoIi0G2LegHNbBgOaVtdPG7phc=.770eb9b8-0945-41a5-a9a1-54df946340ec@github.com>

On Mon, 2 Feb 2026 20:38:07 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]
>
> test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/RuntimeVersionReaderTest.java line 41:
> 
>> 39: import org.junit.jupiter.api.io.TempDir;
>> 40: 
>> 41: public class RuntimeVersionReaderTest {
> 
> I doubt this unit test has ever been executed.

Confused. I did run it manually. Test works as expected.

jtreg -w build/jtreg/work -r build/jtreg/report -jdk build/macosx-x64/images/jdk open/test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/RuntimeVersionReaderTest.java
Test results: passed: 1
Framework-based tests: 3 = 0 TestNG + 3 JUnit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2761452605

From almatvee at openjdk.org  Wed Feb  4 00:28:12 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 4 Feb 2026 00:28:12 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <NEeBqEpKFRvjQg8rs2ropHOlKqpW_U6UpWbexU3p4Qg=.bf7bf267-2c59-44a0-9987-97b3bbabae59@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
 <NEeBqEpKFRvjQg8rs2ropHOlKqpW_U6UpWbexU3p4Qg=.bf7bf267-2c59-44a0-9987-97b3bbabae59@github.com>
Message-ID: <rPwNzwDI8_kFTbpnicsh3XxoxzZ8TM-3ri0Rc8HikNg=.c4e94445-08a8-40dc-ae51-66970b9daf61@github.com>

On Mon, 2 Feb 2026 20:16:01 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/RuntimeImageUtils.java line 47:
> 
>> 45:         }
>> 46: 
>> 47:         return releaseFile;
> 
> Why do we need platform-specificity in this function?
> 
> Shouldn't it be as simple as:
> 
> public static Path getReleaseFilePath(Path runtimePath) {
>     return runtimePath.resolve("release");
> }

This function is being called 3 times already. I think having platform specific code in it is better, then duplicating:

RuntimeImageUtils.getReleaseFilePath(MacBundle.fromPath(cookedRuntime).map(MacBundle::homeDir).orElse(cookedRuntime));

I do like idea of using `MacBundle.fromPath()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2761617991

From almatvee at openjdk.org  Wed Feb  4 00:38:22 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 4 Feb 2026 00:38:22 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <NEeBqEpKFRvjQg8rs2ropHOlKqpW_U6UpWbexU3p4Qg=.bf7bf267-2c59-44a0-9987-97b3bbabae59@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
 <NEeBqEpKFRvjQg8rs2ropHOlKqpW_U6UpWbexU3p4Qg=.bf7bf267-2c59-44a0-9987-97b3bbabae59@github.com>
Message-ID: <3BTDlRceXAipcsgDXcSE4444jvHp39nMcMJiO8T3yMM=.136e7aaf-649e-4e87-a9e3-36905ff51889@github.com>

On Mon, 2 Feb 2026 20:38:57 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]
>
> test/jdk/tools/jpackage/share/RuntimePackageTest.java line 87:
> 
>> 85: public class RuntimePackageTest {
>> 86: 
>> 87:     // @Test
> 
> Is this debugging leftovers?

Yes it is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2761639377

From almatvee at openjdk.org  Wed Feb  4 00:42:52 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 4 Feb 2026 00:42:52 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <NEeBqEpKFRvjQg8rs2ropHOlKqpW_U6UpWbexU3p4Qg=.bf7bf267-2c59-44a0-9987-97b3bbabae59@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
 <NEeBqEpKFRvjQg8rs2ropHOlKqpW_U6UpWbexU3p4Qg=.bf7bf267-2c59-44a0-9987-97b3bbabae59@github.com>
Message-ID: <PXPM-SZNo1ngXH-AQSVsP8hhyU96D4DTWcVU0958jjA=.034b32cb-99e8-4c9b-9aaf-b84a1ba81222@github.com>

On Mon, 2 Feb 2026 20:40:34 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]
>
> test/jdk/tools/jpackage/share/RuntimePackageTest.java line 160:
> 
>> 158:                     .cannedFormattedString("message.release-version",
>> 159:                     version, runtimeImage.toString()));
>> 160:             if (!normalizedVersion.isEmpty()) {
> 
> Why would we not have a normalized version in some cases? Shouldn't it always be available?

Message `Using version "{0}" normalized to platform supported format from "{1}"` is only displayed if version read from release file was normalized. If version can be used as is from release file, then message is not printed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2761646894

From jpai at openjdk.org  Wed Feb  4 01:13:44 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Feb 2026 01:13:44 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v5]
In-Reply-To: <foTeCYbjtM-KoZdAiNUsYl3fPfont1ZaHa5EuCO28MM=.e5a710b3-439e-4211-a08a-fe59e221fa1c@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <bDkndly51pLDHZIMCACnfcLuq-ZOvLfEMZdsfptGmEE=.ddd2890c-2654-45d7-b35a-aaf98a845b2a@github.com>
 <BwKGfxN0wMW0mCDMgiqOIAwzyUw0vHkQKdLWVjNibGw=.b32a5122-e8ed-4fbd-b0fc-eebed6fe0e7d@github.com>
 <foTeCYbjtM-KoZdAiNUsYl3fPfont1ZaHa5EuCO28MM=.e5a710b3-439e-4211-a08a-fe59e221fa1c@github.com>
Message-ID: <kJJKBRlgHhh2ygCx_S-MsYDnsjcD3JXbUGixn4fVyG4=.500704f8-8272-4f49-b275-13801fcea896@github.com>

On Tue, 3 Feb 2026 17:37:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/io/Console/readWriteBlocking.exp line 27:
>> 
>>> 25: eval spawn $argv
>>> 26: 
>>> 27: expect {
>> 
>> More of a question than a review, given what this regression test is for - detecting a deadlock in `Console` API implementation, is the use of `expect` tool necessary for this test? Or could the test just ensure that the launched `java` application completes normally after the two threads read/write using the `Console` instance?
>
> Yes, it is necessary. Without running it through `expect`, `System.console()` returns null for java.base, as the jtreg environment is not an interactive terminal environment.

Thank you Naoto, I wasn't aware of that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2761708642

From jpai at openjdk.org  Wed Feb  4 01:16:36 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Feb 2026 01:16:36 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v8]
In-Reply-To: <VzTaqxMVJQQZDOG9xLi8w_ec7vDkQOYWCcJQkx8w3Ks=.0690d70f-09aa-4e35-99ba-9c03f6fc4d6f@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <VzTaqxMVJQQZDOG9xLi8w_ec7vDkQOYWCcJQkx8w3Ks=.0690d70f-09aa-4e35-99ba-9c03f6fc4d6f@github.com>
Message-ID: <bwRSw6I2D5n9FR7uSe-EOKUI80mM-sheOQmN6fc9AM4=.0ce0a405-9a01-4e36-b27c-7b03dc93a50b@github.com>

On Tue, 3 Feb 2026 20:15:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restores the original race condition

Thank you Naoto for the updates. This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29493#pullrequestreview-3748439707

From jpai at openjdk.org  Wed Feb  4 01:20:21 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Feb 2026 01:20:21 GMT
Subject: RFR: 8375585: Test java/lang/ProcessBuilder/PipelineLeaksFD.java
 failed [v3]
In-Reply-To: <epBcVRtBXQkUQFxN0xfVEp1dsXecHTA859GwQL8AOkc=.801d2702-3ac3-4145-85b2-d71f092cf08a@github.com>
References: <RcWyeLjeptkC1ZUDvTukbnTXkeCPIOJtseYAcfk3jA8=.41f33014-ff91-431c-83a1-4595edb05669@github.com>
 <epBcVRtBXQkUQFxN0xfVEp1dsXecHTA859GwQL8AOkc=.801d2702-3ac3-4145-85b2-d71f092cf08a@github.com>
Message-ID: <XnHaHQeX3z9GrKdJZnqxSLB5ftBRL8JV4u5bXRsTOX8=.9823ceec-55f5-4c9e-a0d3-66b17bf4d850@github.com>

On Tue, 3 Feb 2026 17:40:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Revised test to explicitly compare file descriptor info only from parent and child.
>> If additional fd's are present in the child, it is hard to know their origin but they do not necessarily indicate a bug in Process launch.
>>  
>> Remove from the problem list.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed use of count.

This looks reasonable to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29530#pullrequestreview-3748446332

From bpb at openjdk.org  Wed Feb  4 02:00:46 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Feb 2026 02:00:46 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v20]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <J0A0uK2ASzYItfVd5QCOjwLwuqWiOMswQNGpNaXLqv4=.58fb0d76-fa2a-46f2-8aa3-401706ec7746@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 20 commits:

 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - ... and 10 more: https://git.openjdk.org/jdk/compare/e51ccef9...84337f02

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

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=19
  Stats: 1539 lines in 92 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 syan at openjdk.org  Wed Feb  4 02:07:07 2026
From: syan at openjdk.org (SendaoYan)
Date: Wed, 4 Feb 2026 02:07:07 GMT
Subject: RFR: 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java
 intermittent timed out [v3]
In-Reply-To: <Z8DFosZKbUT31IWqs5qGOj7sqOVM6NhMkCIhtRfb4aU=.389f8a84-0d27-4d8f-8144-588046280c70@github.com>
References: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com>
 <Z8DFosZKbUT31IWqs5qGOj7sqOVM6NhMkCIhtRfb4aU=.389f8a84-0d27-4d8f-8144-588046280c70@github.com>
Message-ID: <J0JH5yZDR91lv3jYImI7_wpOodu4FeYfoyS4p8pJcY0=.18552d4f-a4e2-43b3-a9f5-ed43504a98ee@github.com>

On Tue, 3 Feb 2026 02:41:41 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out, because `lsof` invoke huast lots of time when the tested machine has many processes, and the processes open too many files.
>> 
>> This PR add parameter -p pid to `lsof`, which will only generate output from the wanted processes, rather than all the processes on the machine, this will make `lsof` use less time to finish significantly. And this PR also use `Process.waitFor(long timeout, TimeUnit unit)` instead of `waitFor()` which will avoid waitFor invoke cause test timed out. Delete the history lsof input and output files will make diagnosis more easy.
>> 
>> Change has been verifed locally. The imtermittent timed out do not observed anymore.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove retry on destroyForcibly

Thanks for the reviews and suggestions.

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

PR Comment: https://git.openjdk.org/jdk/pull/29478#issuecomment-3844818356

From syan at openjdk.org  Wed Feb  4 02:07:09 2026
From: syan at openjdk.org (SendaoYan)
Date: Wed, 4 Feb 2026 02:07:09 GMT
Subject: Integrated: 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java
 intermittent timed out
In-Reply-To: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com>
References: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com>
Message-ID: <6koYZrvJZmkQP2R4ai-3Sjdvr2WO-hz4ZlAEhte1Vgs=.c5ad24fc-d61f-4ae3-861e-9683b7837b5f@github.com>

On Thu, 29 Jan 2026 02:35:23 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out, because `lsof` invoke huast lots of time when the tested machine has many processes, and the processes open too many files.
> 
> This PR add parameter -p pid to `lsof`, which will only generate output from the wanted processes, rather than all the processes on the machine, this will make `lsof` use less time to finish significantly. And this PR also use `Process.waitFor(long timeout, TimeUnit unit)` instead of `waitFor()` which will avoid waitFor invoke cause test timed out. Delete the history lsof input and output files will make diagnosis more easy.
> 
> Change has been verifed locally. The imtermittent timed out do not observed anymore.

This pull request has now been integrated.

Changeset: 14a6e928
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/14a6e928ce9a10f6d85fae8db4ce303da20bde85
Stats:     9 lines in 1 file changed: 6 ins; 0 del; 3 mod

8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out

Reviewed-by: rriggs

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

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

From erfang at openjdk.org  Wed Feb  4 02:38:18 2026
From: erfang at openjdk.org (Eric Fang)
Date: Wed, 4 Feb 2026 02:38:18 GMT
Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for
 unsigned min/max reduction operations [v5]
In-Reply-To: <Q2wrStWVzJWL-6b6lxC3eCQv465aVRUdX5Kr95rT5bE=.38082a7b-70c9-4731-8d80-a8927b87f435@github.com>
References: <Q2wrStWVzJWL-6b6lxC3eCQv465aVRUdX5Kr95rT5bE=.38082a7b-70c9-4731-8d80-a8927b87f435@github.com>
Message-ID: <SbpbEN5HJpm8AaXs-K3czwJPgxj59bb_vwNKhZM9q4o=.abd23cad-9248-471c-9aa8-3d88f21abe20@github.com>

> This patch adds intrinsic support for UMIN and UMAX reduction operations in the Vector API on AArch64, enabling direct hardware instruction mapping for better performance.
> 
> Changes:
> --------
> 
> 1. C2 mid-end:
>    - Added UMinReductionVNode and UMaxReductionVNode
> 
> 2. AArch64 Backend:
>    - Added uminp/umaxp/sve_uminv/sve_umaxv instructions
>    - Updated match rules for all vector sizes and element types
>    - Both NEON and SVE implementation are supported
> 
> 3. Test:
>    - Added UMIN_REDUCTION_V and UMAX_REDUCTION_V to IRNode.java
>    - Added assembly tests in aarch64-asmtest.py for new instructions
>    - Added a JTReg test file VectorUMinMaxReductionTest.java
> 
> Different configurations were tested on aarch64 and x86 machines, and all tests passed.
> 
> Test results of JMH benchmarks from the panama-vector project:
> --------
> 
> On a Nvidia Grace machine with 128-bit SVE:
> 
> Benchmark                       Unit    Before  Error   After           Error   Uplift
> Byte128Vector.UMAXLanes         ops/ms  411.60  42.18   25226.51        33.92   61.29
> Byte128Vector.UMAXMaskedLanes   ops/ms  558.56  85.12   25182.90        28.74   45.09
> Byte128Vector.UMINLanes         ops/ms  645.58  780.76  28396.29        103.11  43.99
> Byte128Vector.UMINMaskedLanes   ops/ms  621.09  718.27  26122.62        42.68   42.06
> Byte64Vector.UMAXLanes          ops/ms  296.33  34.44   14357.74        15.95   48.45
> Byte64Vector.UMAXMaskedLanes    ops/ms  376.54  44.01   14269.24        21.41   37.90
> Byte64Vector.UMINLanes          ops/ms  373.45  426.51  15425.36        66.20   41.31
> Byte64Vector.UMINMaskedLanes    ops/ms  353.32  346.87  14201.37        13.79   40.19
> Int128Vector.UMAXLanes          ops/ms  174.79  192.51  9906.07         286.93  56.67
> Int128Vector.UMAXMaskedLanes    ops/ms  157.23  206.68  10246.77        11.44   65.17
> Int64Vector.UMAXLanes           ops/ms  95.30   126.49  4719.30         98.57   49.52
> Int64Vector.UMAXMaskedLanes     ops/ms  88.19   87.44   4693.18         19.76   53.22
> Long128Vector.UMAXLanes         ops/ms  80.62   97.82   5064.01         35.52   62.82
> Long128Vector.UMAXMaskedLanes   ops/ms  78.15   102.91  5028.24         8.74    64.34
> Long64Vector.UMAXLanes          ops/ms  47.56   62.01   46.76           52.28   0.98
> Long64Vector.UMAXMaskedLanes    ops/ms  45.44   46.76   45.79           42.91   1.01
> Short128Vector.UMAXLanes        ops/ms  316.65  410.30  14814.82        23.65   46.79
> Short128Vector.UMAXMaskedLanes  ops/ms  308.90  351.78  15155.26        31.03   49.06
> Sh...

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

  Add JMH benchmark VectorUMinUMaxReductionBenchmark.java
  
  Also refined the helper functions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28693/files
  - new: https://git.openjdk.org/jdk/pull/28693/files/10d74f13..234b4d90

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

  Stats: 275 lines in 3 files changed: 239 ins; 15 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/28693.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28693/head:pull/28693

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

From erfang at openjdk.org  Wed Feb  4 02:47:59 2026
From: erfang at openjdk.org (Eric Fang)
Date: Wed, 4 Feb 2026 02:47:59 GMT
Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for
 unsigned min/max reduction operations [v4]
In-Reply-To: <zCa6wyLAGCiKizlI18J7TlVsfTn4vVCjB81BXgnyc30=.05a546c3-6ce0-456e-b7bc-b495b310a1e1@github.com>
References: <Q2wrStWVzJWL-6b6lxC3eCQv465aVRUdX5Kr95rT5bE=.38082a7b-70c9-4731-8d80-a8927b87f435@github.com>
 <VbmZH3mjqzcjow4E9VQTWOimZuFUjhPIKXF6P1N4hkI=.31ea7b16-073d-4f5c-84dd-585851f4312a@github.com>
 <PxXEZWnuIxXmzNiYenaMCvTArU_oTU-N_htraBcAPDE=.54d25adb-6b60-4f73-b36e-fb925f7f7cfe@github.com>
 <EHNnyjdr2YzR1BxfF2SkY6DWhcfV7uE3wXu_IwaqlQA=.362950d6-398d-4e25-b777-ff7074d9a8c3@github.com>
 <zCa6wyLAGCiKizlI18J7TlVsfTn4vVCjB81BXgnyc30=.05a546c3-6ce0-456e-b7bc-b495b310a1e1@github.com>
Message-ID: <i3243r1OD8SNDSO39eSjV_cgF1kJJWs32lvyNpROHec=.58b324c8-f585-403c-931c-71a093c6a83c@github.com>

On Thu, 29 Jan 2026 10:27:56 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> The IR test framework is better at determining that by testing the right IR nodes are generated - and they get run as part of the existing HotSpot test suite.
>> 
>> But as a reviewer I'm not looking at the IR at all, but at the performance.
>
>> Hi @theRealAph @PaulSandoz , thanks for your insight! How to synchronize the JMH micro benchmarks between Panama and the mainline may be a more general issue that requires further investigation, design, and resources. As for how to move this PR forward, my idea is to write a new micro benchmark in this PR to demonstrate the optimization effect of this patch. Would that be acceptable to you?
> 
> Sure.

Hi @theRealAph I have added a JMH benchmark file to measure the performance changes of this PR, the test results are as follow:

On a Nvidia Grace machine with 128-bit SVE2:

<html xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:x="urn:schemas-microsoft-com:office:excel"
xmlns="http://www.w3.org/TR/REC-html40">

<head>

<meta name=ProgId content=Excel.Sheet>
<meta name=Generator content="Microsoft Excel 15">
<link id=Main-File rel=Main-File
href="file:////Users/erfang/Library/Group%20Containers/UBF8T346G9.Office/TemporaryItems/msohtmlclip/clip.htm">
<link rel=File-List
href="file:////Users/erfang/Library/Group%20Containers/UBF8T346G9.Office/TemporaryItems/msohtmlclip/clip_filelist.xml">



</head>

<body link="#467886" vlink="#96607D">


Benchmark | Unit | Before | Error | After | Error | Uplift
-- | -- | -- | -- | -- | -- | --
byteUMaxReduction | ops/ms | 460.81 | 0.56 | 21998.62 | 22.65 | 47.74
byteUMaxReductionMasked | ops/ms | 663.51 | 19.76 | 22687.57 | 24.96 | 34.19
byteUMinReduction | ops/ms | 461.01 | 0.59 | 21965.89 | 29.29 | 47.65
byteUMinReductionMasked | ops/ms | 686.28 | 51.44 | 21234.19 | 8.21 | 30.94
intUMaxReduction | ops/ms | 263.48 | 1.05 | 11133.25 | 8.73 | 42.25
intUMaxReductionMasked | ops/ms | 248.97 | 2.80 | 10790.52 | 4.17 | 43.34
intUMinReduction | ops/ms | 264.20 | 1.18 | 11134.88 | 4.75 | 42.15
intUMinReductionMasked | ops/ms | 243.88 | 1.89 | 10797.43 | 3.21 | 44.27
longUMaxReduction | ops/ms | 133.90 | 0.45 | 5239.43 | 3.34 | 39.13
longUMaxReductionMasked | ops/ms | 125.91 | 1.09 | 5218.63 | 6.26 | 41.45
longUMinReduction | ops/ms | 132.30 | 1.22 | 5233.60 | 5.37 | 39.56
longUMinReductionMasked | ops/ms | 126.78 | 0.98 | 5215.54 | 6.51 | 41.14
shortUMaxReduction | ops/ms | 345.13 | 0.63 | 9763.47 | 9.52 | 28.29
shortUMaxReductionMasked | ops/ms | 440.71 | 21.09 | 10595.24 | 4.12 | 24.04
shortUMinReduction | ops/ms | 345.65 | 0.62 | 10138.08 | 3.29 | 29.33
shortUMinReductionMasked | ops/ms | 414.75 | 26.63 | 10252.82 | 4.92 | 24.72



</body>

</html>

On a Nvidia Grace machine with 128-bit NEON:

<html xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:x="urn:schemas-microsoft-com:office:excel"
xmlns="http://www.w3.org/TR/REC-html40">

<head>

<meta name=ProgId content=Excel.Sheet>
<meta name=Generator content="Microsoft Excel 15">
<link id=Main-File rel=Main-File
href="file:////Users/erfang/Library/Group%20Containers/UBF8T346G9.Office/TemporaryItems/msohtmlclip/clip.htm">
<link rel=File-List
href="file:////Users/erfang/Library/Group%20Containers/UBF8T346G9.Office/TemporaryItems/msohtmlclip/clip_filelist.xml">



</head>

<body link="#467886" vlink="#96607D">


Benchmark | Unit | Before | Error | After | Error | Uplift
-- | -- | -- | -- | -- | -- | --
byteUMaxReduction | ops/ms | 452.94 | 0.79 | 21597.12 | 76.16 | 47.68
byteUMaxReductionMasked | ops/ms | 654.80 | 65.55 | 21776.97 | 21.80 | 33.26
byteUMinReduction | ops/ms | 452.64 | 0.52 | 21682.22 | 3.50 | 47.90
byteUMinReductionMasked | ops/ms | 603.68 | 35.37 | 20726.86 | 24.27 | 34.33
intUMaxReduction | ops/ms | 260.04 | 1.12 | 10936.03 | 3.31 | 42.05
intUMaxReductionMasked | ops/ms | 243.53 | 1.96 | 10066.68 | 2.17 | 41.34
intUMinReduction | ops/ms | 256.95 | 1.90 | 10934.16 | 5.39 | 42.55
intUMinReductionMasked | ops/ms | 241.82 | 2.14 | 10316.15 | 5.80 | 42.66
longUMaxReduction | ops/ms | 132.05 | 0.34 | 3191.26 | 1.10 | 24.17
longUMaxReductionMasked | ops/ms | 124.59 | 1.01 | 3119.95 | 0.94 | 25.04
longUMinReduction | ops/ms | 131.50 | 0.32 | 3188.86 | 0.99 | 24.25
longUMinReductionMasked | ops/ms | 125.59 | 1.12 | 3118.61 | 0.84 | 24.83
shortUMaxReduction | ops/ms | 343.67 | 0.57 | 9584.07 | 6.83 | 27.89
shortUMaxReductionMasked | ops/ms | 401.15 | 25.37 | 9858.90 | 2.44 | 24.58
shortUMinReduction | ops/ms | 344.17 | 0.79 | 9944.45 | 2.61 | 28.89
shortUMinReductionMasked | ops/ms | 404.24 | 20.85 | 9887.54 | 9.25 | 24.46



</body>

</html>

And we can see similar performance uplift on AWS Graviton3  (Neonverse-V1) and Graviton4  (Neonverse-V2) machines. Would you mind taking another look, thanks a lot !

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

PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3844925369

From syan at openjdk.org  Wed Feb  4 03:14:26 2026
From: syan at openjdk.org (SendaoYan)
Date: Wed, 4 Feb 2026 03:14:26 GMT
Subject: RFR: 8375585: Test java/lang/ProcessBuilder/PipelineLeaksFD.java
 failed [v3]
In-Reply-To: <epBcVRtBXQkUQFxN0xfVEp1dsXecHTA859GwQL8AOkc=.801d2702-3ac3-4145-85b2-d71f092cf08a@github.com>
References: <RcWyeLjeptkC1ZUDvTukbnTXkeCPIOJtseYAcfk3jA8=.41f33014-ff91-431c-83a1-4595edb05669@github.com>
 <epBcVRtBXQkUQFxN0xfVEp1dsXecHTA859GwQL8AOkc=.801d2702-3ac3-4145-85b2-d71f092cf08a@github.com>
Message-ID: <fe7JfcnCy3XhmHQBKwcPCM3zPvUI3MGTyDEbjvKP0wY=.a489887e-a745-4d92-93d6-6263ddf26049@github.com>

On Tue, 3 Feb 2026 17:40:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Revised test to explicitly compare file descriptor info only from parent and child.
>> If additional fd's are present in the child, it is hard to know their origin but they do not necessarily indicate a bug in Process launch.
>>  
>> Remove from the problem list.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed use of count.

I run this test 10k times and all passed after apply the proposed patch.

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

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/29530#pullrequestreview-3748707300

From asemenyuk at openjdk.org  Wed Feb  4 03:28:03 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 4 Feb 2026 03:28:03 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <5TLrb0kJHNkxOHjwwkoIi0G2LegHNbBgOaVtdPG7phc=.770eb9b8-0945-41a5-a9a1-54df946340ec@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
 <NEeBqEpKFRvjQg8rs2ropHOlKqpW_U6UpWbexU3p4Qg=.bf7bf267-2c59-44a0-9987-97b3bbabae59@github.com>
 <5TLrb0kJHNkxOHjwwkoIi0G2LegHNbBgOaVtdPG7phc=.770eb9b8-0945-41a5-a9a1-54df946340ec@github.com>
Message-ID: <eyBPOhSVaU4f7hXm3fc0_gEe_Y_Dl9W2hSHbz7-mT78=.5369048a-9026-483c-a2be-35103de1e4d0@github.com>

On Tue, 3 Feb 2026 23:15:24 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/RuntimeVersionReaderTest.java line 41:
>> 
>>> 39: import org.junit.jupiter.api.io.TempDir;
>>> 40: 
>>> 41: public class RuntimeVersionReaderTest {
>> 
>> I doubt this unit test has ever been executed.
>
> Confused. I did run it manually. Test works as expected.
> 
> jtreg -w build/jtreg/work -r build/jtreg/report -jdk build/macosx-x64/images/jdk open/test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/RuntimeVersionReaderTest.java
> Test results: passed: 1
> Framework-based tests: 3 = 0 TestNG + 3 JUnit

I take it back. I didn't notice that `test_release_file_with_version()` sets the "JAVA_VERSION" property, and that `test_release_file_without_version()` sets the "**JDK**_VERSION" property. It is not the same property.

>> test/jdk/tools/jpackage/share/RuntimePackageTest.java line 160:
>> 
>>> 158:                     .cannedFormattedString("message.release-version",
>>> 159:                     version, runtimeImage.toString()));
>>> 160:             if (!normalizedVersion.isEmpty()) {
>> 
>> Why would we not have a normalized version in some cases? Shouldn't it always be available?
>
> Message `Using version "{0}" normalized to platform supported format from "{1}"` is only displayed if version read from release file was normalized. If version can be used as is from release file, then message is not printed.

So, if the normalized version equals the source version, jpackage doesn't emit the normalization message. Make sense.
Then I suggest to split this test function in two:

@Parameter(value = {"27.1.2.3"}, ifOS = {LINUX, WINDOWS})
public static void testReleaseFileVersion(String version) {
    testReleaseFileVersion(version, version);
}

@Parameter(value = {"27.1.2.3.4", "27.1.2"}, ifOS = MACOS)
public static void testReleaseFileVersion(String version, String normalizedVersion) {
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2761985750
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2761967427

From asemenyuk at openjdk.org  Wed Feb  4 03:28:06 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 4 Feb 2026 03:28:06 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
Message-ID: <ZsbcKxd6IpINEEOyKrdhEz2XvmWqox90rTWuu-Uc-Eg=.1bfa7f10-592e-41d8-8ac1-bcfcdf7e1bcd@github.com>

On Sun, 18 Jan 2026 05:17:40 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
>> - Added test to cover added functionality.
>> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]

test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/RuntimeVersionReaderTest.java line 44:

> 42: 
> 43:     @Test
> 44:     public void test_release_file_with_version(@TempDir Path workdir) {

Should we test other values of the "JAVA_VERSION" property? Empty one, some unexpected one, like "foo"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2761990169

From asemenyuk at openjdk.org  Wed Feb  4 03:39:11 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 4 Feb 2026 03:39:11 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <YK-Ugiw4bfPm4RQlBzu47oxqvArpgn_9j_NZI-jIbzY=.23e52b9c-41cb-4f28-8791-9712dd6f2fb1@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
 <NEeBqEpKFRvjQg8rs2ropHOlKqpW_U6UpWbexU3p4Qg=.bf7bf267-2c59-44a0-9987-97b3bbabae59@github.com>
 <YK-Ugiw4bfPm4RQlBzu47oxqvArpgn_9j_NZI-jIbzY=.23e52b9c-41cb-4f28-8791-9712dd6f2fb1@github.com>
Message-ID: <2IrPPIp3XsPRZCmVCR7M8uLeu9kwWBknuDI45KV4-XU=.0819a030-4918-44fb-a8fd-dc25ce34ea38@github.com>

On Tue, 3 Feb 2026 23:06:31 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/RuntimeVersionReader.java line 47:
>> 
>>> 45:             String version = props.getProperty("JAVA_VERSION");
>>> 46:             if (version != null) {
>>> 47:                 version = version.replaceAll("^\"|\"$", "");
>> 
>> Why does this function filter the value of the "JAVA_VERSION" property?
>> 
>> It should not do any filtering; it should just read the value as its name suggests.
>> 
>> Filering is platform-specific and should be a separate method.
>
> For some reason `JAVA_VERSION` is set to quoted string and `getProperty()` will return `"27"` instead of `27`. I think `"` is not truly part of version string and `replaceAll()` removes it. I do not think that removing leading and trailing `"` should be platform specific.

Please add a comment explaining this.
We also need a test case where the property value is not enclosed in double quotes.

Makes me wonder: is java.util.Properties the correct choice for reading the "release" file?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2762011038

From almatvee at openjdk.org  Wed Feb  4 03:39:15 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 4 Feb 2026 03:39:15 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <ZsbcKxd6IpINEEOyKrdhEz2XvmWqox90rTWuu-Uc-Eg=.1bfa7f10-592e-41d8-8ac1-bcfcdf7e1bcd@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
 <ZsbcKxd6IpINEEOyKrdhEz2XvmWqox90rTWuu-Uc-Eg=.1bfa7f10-592e-41d8-8ac1-bcfcdf7e1bcd@github.com>
Message-ID: <qUCiOArNH0EaFgswtH-xfJFRpfA10mMNNPlgs-Bend0=.7ecedf97-e71e-49d4-8389-e0cf6161fe3e@github.com>

On Wed, 4 Feb 2026 03:24:39 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]
>
> test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/RuntimeVersionReaderTest.java line 44:
> 
>> 42: 
>> 43:     @Test
>> 44:     public void test_release_file_with_version(@TempDir Path workdir) {
> 
> Should we test other values of the "JAVA_VERSION" property? Empty one, some unexpected one, like "foo"?

Not as part of `RuntimeVersionReaderTest`. `RuntimeVersionReader` just read version as is, so not sure what such testing will test. Such testing should be done as part of `RuntimePackageTest`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2762012278

From asemenyuk at openjdk.org  Wed Feb  4 03:51:15 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 4 Feb 2026 03:51:15 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <rPwNzwDI8_kFTbpnicsh3XxoxzZ8TM-3ri0Rc8HikNg=.c4e94445-08a8-40dc-ae51-66970b9daf61@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
 <NEeBqEpKFRvjQg8rs2ropHOlKqpW_U6UpWbexU3p4Qg=.bf7bf267-2c59-44a0-9987-97b3bbabae59@github.com>
 <rPwNzwDI8_kFTbpnicsh3XxoxzZ8TM-3ri0Rc8HikNg=.c4e94445-08a8-40dc-ae51-66970b9daf61@github.com>
Message-ID: <fTPf5tbuIWqMtWUFDU60LDr6_P74FBqIrYPAoQi8hmg=.1b8cdca6-7ce6-4482-b23b-878bdc30cc36@github.com>

On Wed, 4 Feb 2026 00:25:16 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/RuntimeImageUtils.java line 47:
>> 
>>> 45:         }
>>> 46: 
>>> 47:         return releaseFile;
>> 
>> Why do we need platform-specificity in this function?
>> 
>> Shouldn't it be as simple as:
>> 
>> public static Path getReleaseFilePath(Path runtimePath) {
>>     return runtimePath.resolve("release");
>> }
>
> This function is being called 3 times already. I think having platform specific code in it is better, then duplicating:
> 
> RuntimeImageUtils.getReleaseFilePath(MacBundle.fromPath(cookedRuntime).map(MacBundle::homeDir).orElse(cookedRuntime));
> 
> I do like idea of using `MacBundle.fromPath()`.

The code that finds the JDK image directory in a random path is a separate function.
The function that returns a path to the "release" file in the JDK image should take a path to the JDK image directory.

If we need a convenience function that does both things, we should implement it on top of these two functions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2762031458

From asemenyuk at openjdk.org  Wed Feb  4 04:05:10 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 4 Feb 2026 04:05:10 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <qUCiOArNH0EaFgswtH-xfJFRpfA10mMNNPlgs-Bend0=.7ecedf97-e71e-49d4-8389-e0cf6161fe3e@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
 <ZsbcKxd6IpINEEOyKrdhEz2XvmWqox90rTWuu-Uc-Eg=.1bfa7f10-592e-41d8-8ac1-bcfcdf7e1bcd@github.com>
 <qUCiOArNH0EaFgswtH-xfJFRpfA10mMNNPlgs-Bend0=.7ecedf97-e71e-49d4-8389-e0cf6161fe3e@github.com>
Message-ID: <Vt5-3qVFYte6lQaKlrwUirOxtdOgfCEjSOHF989iNq4=.0fc6a833-4d80-4ef2-a75c-e507606a5213@github.com>

On Wed, 4 Feb 2026 03:36:36 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> RuntimeVersionReader just read version as is

It does not. It filters out double quotes from the property value, right? So it is not that straightforward.

These specifics should be covered in the `RuntimeVersionReaderTest` (unit test). 
How jpackage propagates the version from the "release" file into the installer is covered in `RuntimePackageTest` (integration/functional test).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2762068292

From liach at openjdk.org  Wed Feb  4 04:20:03 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 04:20:03 GMT
Subject: RFR: 8377116: Refactor java/util/zip TestNG tests to JUnit
In-Reply-To: <QPduW9IIUl5rdWQ4uTQpnO_2yqX8E2sZO12uTEE2oaE=.40f85d49-bac5-4b73-88d2-4ff597a6ba46@github.com>
References: <QPduW9IIUl5rdWQ4uTQpnO_2yqX8E2sZO12uTEE2oaE=.40f85d49-bac5-4b73-88d2-4ff597a6ba46@github.com>
Message-ID: <fsBvO90fdY65D0v2ArcX7FC8wnl8Pq8RFXmTPqU_W-Q=.078e482d-7ed8-4e75-ae51-b73d8a7209b5@github.com>

On Tue, 3 Feb 2026 22:09:58 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR consists of a conversion for the java/util/zip TestNG tests to JUnit. Changes are mainly automated. https://github.com/openjdk/jdk/commit/1aeb8a634b8f255853516015f4b39bd79dd94090 is required to resolve a failure since JUnit parameterized tests automatically close arguments that implement `AutoCloseable`.
> 
> Test stats before:
> Framework-based tests: 274 = 107 TestNG + 167 JUnit
> 
> Test stats after:
> Framework-based tests: 274 = 0 TestNG + 274 JUnit

test/jdk/java/util/zip/DeflaterDictionaryTests.java line 113:

> 111: 
> 112:             Assertions.assertEquals(resultLength, SRC_DATA.length());
> 113:             Assertions.assertArrayEquals(Arrays.copyOf(result, resultLength), input);

I think we should restore the original order here - maybe someone used testng the junit way. Same below.

test/jdk/java/util/zip/ZipFile/ZipFileDuplicateEntryTest.java line 289:

> 287:                             ze.getName(), ze.isDirectory(), new String(bytes));
> 288:                 }
> 289:                 assertArrayEquals(bytes, entry.bytes,

Let's reverse this one. This test is really weird with a mix of styles.

test/jdk/java/util/zip/ZipFile/ZipFileDuplicateEntryTest.java line 365:

> 363:         try (ZipFile zf = new ZipFile(ZIP_FILE.toFile())) {
> 364:             List<? extends ZipEntry> entries = zf.stream().collect(Collectors.toList());
> 365:             assertEquals(entries.size(), EXPECTED_ENTRIES.size());

Let's reverse this one.

test/jdk/java/util/zip/ZipFile/ZipFileDuplicateEntryTest.java line 390:

> 388:                         entry.name, je.getMethod(), entry.method);
> 389:             }
> 390:             assertEquals(je.getMethod(), entry.method);

Let's reverse this one, entry.method is called "Expected Method" above.

test/jdk/java/util/zip/ZipFile/ZipFileDuplicateEntryTest.java line 490:

> 488:         try (JarFile jf = new JarFile(TEST_JAR.toFile())) {
> 489:             List<? extends JarEntry> entries = jf.stream().collect(Collectors.toList());
> 490:             assertEquals(jf.size(), EXPECTED_ENTRIES.size());

Let's reverse the order of this one

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29552#discussion_r2762072205
PR Review Comment: https://git.openjdk.org/jdk/pull/29552#discussion_r2762096913
PR Review Comment: https://git.openjdk.org/jdk/pull/29552#discussion_r2762096178
PR Review Comment: https://git.openjdk.org/jdk/pull/29552#discussion_r2762093887
PR Review Comment: https://git.openjdk.org/jdk/pull/29552#discussion_r2762092307

From jbhateja at openjdk.org  Wed Feb  4 06:59:14 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 4 Feb 2026 06:59:14 GMT
Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass
 them to intrinsic entries [v7]
In-Reply-To: <kDaABPfdYICCDElAjcNrY1MR61aIQO58SdxFCgZfVRY=.de99cd78-43ef-4664-bd6c-641ed75d3173@github.com>
References: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
 <kDaABPfdYICCDElAjcNrY1MR61aIQO58SdxFCgZfVRY=.de99cd78-43ef-4664-bd6c-641ed75d3173@github.com>
Message-ID: <h0DiXtUajxYpMr8ULo6nQTathU8zfxKeuI25ph19SHc=.dcf632f2-2b2e-412f-95a5-1c0fce653bf1@github.com>

On Tue, 3 Feb 2026 03:31:52 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support.
>> 
>> Patch add new lane type constants and pass them to vector intrinsic entry points.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolution

Hi @merykitty , looking for your review approval to check-in this

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

PR Comment: https://git.openjdk.org/jdk/pull/29481#issuecomment-3845705837

From jbhateja at openjdk.org  Wed Feb  4 07:01:44 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 4 Feb 2026 07:01:44 GMT
Subject: RFR: 8376794: Enable copy and mismatch Partial Inlining for AMD AVX512
 targets
Message-ID: <LIdQi9c0pTKY9GZJoZVnpKC7DRYZYaATzujDQTPSyvY=.b0d8ee2f-bc7b-4174-b7f4-6e3cddc4721d@github.com>

Partial in-lining handles copy and mismatch for small array sizes less than -XX:ArrayOperationPartialInlineSize bytes through JIT code rather than calling optimized stubs thereby saving costly call overhead.

Enabling partial in-lining optimization for AMD EPYC servers supporting AVX-512 feature.

Following are the performance numbers on Turin at fixed frequency of 2.1GHz

<img width="440" height="440" alt="image" src="https://github.com/user-attachments/assets/14b55ee3-b65c-4247-8739-67f1b94dceb4" />
<img width="440" height="300" alt="image" src="https://github.com/user-attachments/assets/c00d6443-45a2-4277-961d-580ceea5da88" />

Kindly review and share your feedback.

Best Regards,
Jatin

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

Commit messages:
 - Extending micro-benchmark for short array mismatch
 - 8376794: Enable copy and mismatch Partial Inlining for AMD AVX512 targets

Changes: https://git.openjdk.org/jdk/pull/29519/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29519&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8376794
  Stats: 75 lines in 2 files changed: 47 ins; 5 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/29519.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29519/head:pull/29519

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

From syan at openjdk.org  Wed Feb  4 07:30:19 2026
From: syan at openjdk.org (SendaoYan)
Date: Wed, 4 Feb 2026 07:30:19 GMT
Subject: RFR: 8376760: VerifyJimage.java#compare intermittent failed with
 fastdebug [v3]
In-Reply-To: <n_avEaP6hBwjpDtvC0B45oIoWUSFGDdot2mhx9pMg4Y=.d6fd87c1-288d-4449-bb2a-d6d5c680091b@github.com>
References: <j360mZjyQnFn5YnxFiE75b-6WEbzQh0AHBDFRTmo6Zk=.fc329853-99bc-4867-bc81-d9ffa46ba386@github.com>
 <GwOWYkJcdZDAhuNJUMV3UFtExG_tTCLE_rcxTz6fs98=.4be1697f-c896-4c49-b0b2-84fdb9773280@github.com>
 <n_avEaP6hBwjpDtvC0B45oIoWUSFGDdot2mhx9pMg4Y=.d6fd87c1-288d-4449-bb2a-d6d5c680091b@github.com>
Message-ID: <WAd711Q-wv1elhW7-QC2RJKfCpOjleDiL40Ux1cd4-Q=.635735db-5465-4618-bf8a-6c570da36f67@github.com>

On Mon, 2 Feb 2026 14:26:36 GMT, Chen Liang <liach at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary import
>
> Somehow david is not an author, so I will leave an approval to allow  integration.

Thanks @liach @AlanBateman @david-beaumont

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

PR Comment: https://git.openjdk.org/jdk/pull/29498#issuecomment-3845803297

From syan at openjdk.org  Wed Feb  4 07:35:18 2026
From: syan at openjdk.org (SendaoYan)
Date: Wed, 4 Feb 2026 07:35:18 GMT
Subject: Integrated: 8376760: VerifyJimage.java#compare intermittent failed
 with fastdebug
In-Reply-To: <j360mZjyQnFn5YnxFiE75b-6WEbzQh0AHBDFRTmo6Zk=.fc329853-99bc-4867-bc81-d9ffa46ba386@github.com>
References: <j360mZjyQnFn5YnxFiE75b-6WEbzQh0AHBDFRTmo6Zk=.fc329853-99bc-4867-bc81-d9ffa46ba386@github.com>
Message-ID: <5bjNteyA2GalPJhYCirIuY6NwQKn-e-Ch_FgxsaKC6c=.24224fd9-7e50-4540-8707-8170fb7dbb00@github.com>

On Fri, 30 Jan 2026 02:20:09 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test tools/jimage/VerifyJimage.java#compare intermittent timed out with fastdebug build. I think it would be better to ajust the jtreg timeout factor(20*timeoutFactor) rather that set the fix timeout value(20) for awaitTermination.
> 
> The test run all passed 100 times simultaneously.

This pull request has now been integrated.

Changeset: 7e8fad62
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7e8fad625a2cdc9a4e46eb31c485de074997c7c0
Stats:     8 lines in 1 file changed: 0 ins; 6 del; 2 mod

8376760: VerifyJimage.java#compare intermittent failed with fastdebug

Reviewed-by: liach, alanb

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

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

From alanb at openjdk.org  Wed Feb  4 07:38:37 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Feb 2026 07:38:37 GMT
Subject: RFR: 8377116: Refactor java/util/zip TestNG tests to JUnit
In-Reply-To: <QPduW9IIUl5rdWQ4uTQpnO_2yqX8E2sZO12uTEE2oaE=.40f85d49-bac5-4b73-88d2-4ff597a6ba46@github.com>
References: <QPduW9IIUl5rdWQ4uTQpnO_2yqX8E2sZO12uTEE2oaE=.40f85d49-bac5-4b73-88d2-4ff597a6ba46@github.com>
Message-ID: <9bFLQa04PiceXyt5ZVAB4t5ZwfTXYEwLGd7-p-b1xdI=.0890db52-2556-4a4d-b9db-2e11a4f45e52@github.com>

On Tue, 3 Feb 2026 22:09:58 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR consists of a conversion for the java/util/zip TestNG tests to JUnit. Changes are mainly automated. https://github.com/openjdk/jdk/commit/1aeb8a634b8f255853516015f4b39bd79dd94090 is required to resolve a failure since JUnit parameterized tests automatically close arguments that implement `AutoCloseable`.
> 
> Test stats before:
> Framework-based tests: 274 = 107 TestNG + 167 JUnit
> 
> Test stats after:
> Framework-based tests: 274 = 0 TestNG + 274 JUnit

test/jdk/java/util/zip/CloseInflaterDeflaterTest.java line 93:

> 91: 
> 92:     /**
> 93:      * DataProvider to specify on which outputstream closeEntry() has to be called

It would be good to do a pass over the comments to replace the uses of DataProviders as these methods are now method sources.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29552#discussion_r2762615206

From alanb at openjdk.org  Wed Feb  4 07:41:30 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Feb 2026 07:41:30 GMT
Subject: RFR: 8377116: Refactor java/util/zip TestNG tests to JUnit
In-Reply-To: <QPduW9IIUl5rdWQ4uTQpnO_2yqX8E2sZO12uTEE2oaE=.40f85d49-bac5-4b73-88d2-4ff597a6ba46@github.com>
References: <QPduW9IIUl5rdWQ4uTQpnO_2yqX8E2sZO12uTEE2oaE=.40f85d49-bac5-4b73-88d2-4ff597a6ba46@github.com>
Message-ID: <df0zORy5B5kAg0cWO1ih9SlFPIH31IrCfwJ2U_jDeD0=.fa23772c-bff8-4465-a5ad-9bcd169c6e2b@github.com>

On Tue, 3 Feb 2026 22:09:58 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR consists of a conversion for the java/util/zip TestNG tests to JUnit. Changes are mainly automated. https://github.com/openjdk/jdk/commit/1aeb8a634b8f255853516015f4b39bd79dd94090 is required to resolve a failure since JUnit parameterized tests automatically close arguments that implement `AutoCloseable`.
> 
> Test stats before:
> Framework-based tests: 274 = 107 TestNG + 167 JUnit
> 
> Test stats after:
> Framework-based tests: 274 = 0 TestNG + 274 JUnit

test/jdk/java/util/zip/DeflaterDictionaryTests.java line 37:

> 35: 
> 36: import static java.nio.charset.StandardCharsets.UTF_8;
> 37: import static org.junit.jupiter.api.Assertions.assertThrows;

Maybe a combination of the TestNG test and the migration tool but it seems a bit strange to static import assertThrows and uses Assertions.assertXXX for everything else.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29552#discussion_r2762623998

From duke at openjdk.org  Wed Feb  4 07:53:00 2026
From: duke at openjdk.org (duke)
Date: Wed, 4 Feb 2026 07:53:00 GMT
Subject: Withdrawn: 8371656: HashMap.putAll() optimizations
In-Reply-To: <L9LdywP8aeyIW9SVHLEsRSUmuaa2vWWQyMW9pTrLtHA=.363bd16c-febb-4028-96b9-a01cdd0d86a2@github.com>
References: <L9LdywP8aeyIW9SVHLEsRSUmuaa2vWWQyMW9pTrLtHA=.363bd16c-febb-4028-96b9-a01cdd0d86a2@github.com>
Message-ID: <nst-5Va7TBkBUyG8qE4QQzrQiwjUatq7QuMzOFHYge8=.7eb5068a-7fa6-45fa-8c39-fabdb8212ed1@github.com>

On Tue, 11 Nov 2025 19:27:28 GMT, jengebr <duke at openjdk.org> wrote:

> # HashMap.putAll() optimizations: Eliminating Megamorphic Call Site Bottlenecks
> 
> ## Summary
> 
> This PR addresses performance bottlenecks in `HashMap.putMapEntries()` by implementing direct optimizations for specific input types: `j.u.HashMap` and `j.u.Collections$UnmodifiableMap`. The optimizations target `HashMap(Map)` constructor and `putAll()` operations based on the real-world megamorphic behavior identified in [JDK-8368292](https://bugs.openjdk.org/browse/JDK-8368292), delivering significant performance improvements when multiple `Map` subtypes are used.
> 
> ## Problem Context
> 
> ### Megamorphic Call Site Overhead in Map Iteration
> `HashMap.putMapEntries()` currently uses a generic approach that suffers from megamorphic call site overhead when applications perform bulk creation or population of HashMaps from various source map types:
> 
> 1. `m.entrySet()` becomes megamorphic across different map implementations
> 2. `entrySet().iterator()` creates different iterator types
> 3. `entry.getKey()` and `entry.getValue()` calls vary by map type
> 4. Individual `putVal()` calls for each entry
> 
> When the source is `Collections$UnmodifiableMap`, the problem is compounded by megamorphic wrappers around the already-megamorphic iteration methods. In cases where the unwrapped map is also a HashMap, both the wrapper overhead and the iteration overhead can be eliminated with a single optimization.
> 
> ## Optimized Methods
> 
> ### HashMap
> - **`putMapEntries(Map<? extends K, ? extends V> m, boolean evict)`**: Added fast paths for UnmodifiableMap unwrapping and HashMap-to-HashMap copying
> - **`putMapEntries(HashMap<? extends K, ? extends V> src, boolean evict)`**: copies HashMap-to-HashMap via direct Node processing.  Avoids polymorphic issues and eliminates redundant calls to HashMap.hash().
> 
> ## Implementation Details
> 
> ### HashMap-to-HashMap Fast Path
> Eliminates megamorphic iteration by targeting internal Node structure - and also reuses the pre-calculated hash code, thus avoiding megamorphic calls to Object.hashCode() and the sometimes-expensive recalculation (depending on key type).  This also eliminates direct reads from the key, thus reducing the set of objects accessed.
> 
> ### UnmodifiableMap Unwrapping
> Detects UnmodifiableMap instances and accesses the underlying map directly via the `m` field, eliminating wrapper-induced megamorphic call sites. UnmodifiableMap visibility changed from `private` to package-private to enable this direct access.
> 
> ## Performance Impact
> 
> | Source Type | Size |...

This pull request has been closed without being integrated.

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

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

From xgong at openjdk.org  Wed Feb  4 07:56:08 2026
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 4 Feb 2026 07:56:08 GMT
Subject: RFR: 8372136: VectorAPI: Refactor subword gather load API java
 implementation [v2]
In-Reply-To: <SEUxzD0msReThVgeMRw5uapRw-UIjewDJP27RAt3ZzY=.991e5f58-347e-44fe-92db-b56576aab780@github.com>
References: <SEUxzD0msReThVgeMRw5uapRw-UIjewDJP27RAt3ZzY=.991e5f58-347e-44fe-92db-b56576aab780@github.com>
Message-ID: <OevjO9jR4c1d857tawyZJ2ITebLuXsj0cCM1HzNZpBo=.90d3d9a4-ece9-420f-b769-09de6c39a9d9@github.com>

> The current subword (`byte`/`short`) gather load API implementation is not well-suited for platforms that provide native vector instructions for these operations. As **discussed in PR [1]**, we'd like to re-implement these APIs with a **unified cross-platform** solution.
> 
> The main idea is to re-implement the API at Java-level, by performing multiple sub-gather operations. Each sub-gather operation loads a portion of elements using a specific index vector by calling the HotSpot intrinsic API. The partial results are then merged using vector `slice` and `or` operations. This design simplifies the VM compiler intrinsic implementation and better aligns with the Vector API design principles.
> 
> Key changes:
> 1. Re-implement the subword gather load API at the Java level. The HotSpot intrinsic `VectorSupport.loadWithMap` is simplified by reducing the vector index parameters from four (vix1-vix4) to a single parameter.
> 2. Adjust the compiler intrinsic implementation to support the new Java API, including updates to the x86 backend implementation.
> 
> The performance impact varies across different scenarios on X86. I tested the performance with different AVX levels on an X86 machine that supports AVX512. To achieve optimal performance, I also **applied PR [2]**, which improves the performance of the **`slice()`** API on X86. Following is the summarized performance gains, where:
> 
> - "non masked" means the gather operation is not the masked gather API.
> - "masked" means the gather operation is the masked gather API.
> - "1 gather cases" means the gather API is implemented with a single gather operation. E.g. Load `Short128Vector` with `MaxVectorSize=256`.
> - "2 gather cases" means the gather API is implemented with 2 parts of gather operations. E.g. Load `Short256Vector` with `MaxVectorSize=256`.
> - "4 gather cases" means the gather API is implemented with 4 parts of gather operations. E.g. Load `Byte256Vector` with `MaxVectorSize=256`.
> - "Un-intrinsified" means the gather operation is not supported to be intrinsified by hotspot. E.g. Load `Byte512Vector` with `MaxVectorSize=256`. The singificant performance uplifts comes from the Java-level changes which removes the vector index generation and range checks for such cases.
> 
> 
> ----------------------------------------------------------------------------
>                |          UseAVX=3           |          UseAVX=2           |
>                |-----------------------------|-----------------------------|
>                |  non maske...

Xiaohong Gong 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 'jdk:master' into JDK-8372136
 - 8372136: VectorAPI: Refactor subword gather load API java implementation

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

Changes: https://git.openjdk.org/jdk/pull/28520/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28520&range=01
  Stats: 558 lines in 13 files changed: 383 ins; 78 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/28520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28520/head:pull/28520

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

From myankelevich at openjdk.org  Wed Feb  4 07:58:05 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 4 Feb 2026 07:58:05 GMT
Subject: RFR: 8377063: Add EchoPassword.java to manual group
In-Reply-To: <_3-OHoZ5H69GfNZj3XnTZhY3UR5H8ShWrcBM90if5-Y=.c0ab9f6f-cf09-41c0-856d-dc7f6863a1ac@github.com>
References: <aGlMUvvPuOdYezDWpPpGNNNjgx5ptSjLZqBrCUXWB1Q=.873c56f0-7b4b-47ab-b946-3927cc7f2009@github.com>
 <_3-OHoZ5H69GfNZj3XnTZhY3UR5H8ShWrcBM90if5-Y=.c0ab9f6f-cf09-41c0-856d-dc7f6863a1ac@github.com>
Message-ID: <IGV2W7sPswx-P7Er5RnPoyMYl3BKhdOqnlLTreSRFN0=.ad88c88e-2ab3-415b-866e-c4cae9dc9eda@github.com>

On Tue, 3 Feb 2026 23:01:58 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Added EchoPassword.java to a security manual group
>
> Marked as reviewed by rhalade (Reviewer).

Thanks @rhalade @msheppar!

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

PR Comment: https://git.openjdk.org/jdk/pull/29544#issuecomment-3845890918

From myankelevich at openjdk.org  Wed Feb  4 07:58:06 2026
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 4 Feb 2026 07:58:06 GMT
Subject: Integrated: 8377063: Add EchoPassword.java to manual group
In-Reply-To: <aGlMUvvPuOdYezDWpPpGNNNjgx5ptSjLZqBrCUXWB1Q=.873c56f0-7b4b-47ab-b946-3927cc7f2009@github.com>
References: <aGlMUvvPuOdYezDWpPpGNNNjgx5ptSjLZqBrCUXWB1Q=.873c56f0-7b4b-47ab-b946-3927cc7f2009@github.com>
Message-ID: <4oZa9HtcY9X6wCPdaRnPxStlKZlbioWtu_GsCmLjQIE=.11ec897a-f2e0-40cd-aeee-0fd21e6870b8@github.com>

On Tue, 3 Feb 2026 14:14:45 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> Added EchoPassword.java to a security manual group

This pull request has now been integrated.

Changeset: d67f72e0
Author:    Mikhail Yankelevich <myankelevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d67f72e0d55ce4da5928716fc6ab87d87516443b
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8377063: Add EchoPassword.java to manual group

Reviewed-by: msheppar, rhalade

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

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

From alanb at openjdk.org  Wed Feb  4 08:40:12 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Feb 2026 08:40:12 GMT
Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for
 all cases [v4]
In-Reply-To: <sbp120wZjbJcEpyWDT9It7wFl_zU1kXNiHz7QMkd6RA=.46fa522d-104a-4c6f-a18f-cb0f8f37cad4@github.com>
References: <sbp120wZjbJcEpyWDT9It7wFl_zU1kXNiHz7QMkd6RA=.46fa522d-104a-4c6f-a18f-cb0f8f37cad4@github.com>
Message-ID: <RlKpHz3GaSmQpSjV0X7J16qaHE4VEbiuqayztSMIpy4=.c823d3bd-5388-49de-b034-4800dec34049@github.com>

> JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace.
> 
> A summary of the changes:
> 
> - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state
> - Thread::getStackTrace is changed to use async_get_stack_trace for all cases
> - The SUSPENDED substate in VirtualThread is removed
> - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in
> - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace
> 
> The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait.
> 
> A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required.
> 
> Testing: tier1-5.  The changes has been already been tested in the loom repo for a few months.

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

 - Merge branch 'master' into JDK-8376568
 - Merge branch 'master' into JDK-8376568
 - Review feedback
 - Improve asserts
 - Cleanup
 - Merge branch 'master' into Thread.getStackTrace
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29461/files
  - new: https://git.openjdk.org/jdk/pull/29461/files/1b7c9ad7..9e7b266a

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

  Stats: 42808 lines in 491 files changed: 19796 ins; 14778 del; 8234 mod
  Patch: https://git.openjdk.org/jdk/pull/29461.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29461/head:pull/29461

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

From aartemov at openjdk.org  Wed Feb  4 08:54:26 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 4 Feb 2026 08:54:26 GMT
Subject: RFR: 8376665: Port fdlibm acosh to Java [v3]
In-Reply-To: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
References: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
Message-ID: <09GXzF9oQG67Wv1b-FnozilqzS5VlJvxz5_lGufNi4Q=.e84d501c-b15a-4112-8322-12fc38586c0b@github.com>

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM acosh method.
> 
> Original C vs transliteration port:
> 
> 
> $ diff -w fdlib_acosh.c.txt Acosh.translit.java
> 1c1,3
> < /* __ieee754_acosh(x)
> ---
>> /**
>>  * Return the Inverse Hyperbolic Cosine of x
>>  *
> 7,8c9,10
> <  *            acosh(x) := log(2x-1/(sqrt(x*x-1)+x)) if x>2; else
> <  *            acosh(x) := log1p(t+sqrt(2.0*t+t*t)); where t=x-1.
> ---
>>  *            := log(2x-1/(sqrt(x*x-1)+x)) if x>2; else
>>  *            := log1p(t+sqrt(2.0*t+t*t)); where t=x-1.
> 14,31c16,19
> <
> < #include "fdlibm.h"
> <
> < #ifdef __STDC__
> < static const double
> < #else
> < static double
> < #endif
> < one   = 1.0,
> < ln2   = 6.93147180559945286227e-01;  /* 0x3FE62E42, 0xFEFA39EF */
> <
> < #ifdef __STDC__
> <       double __ieee754_acosh(double x)
> < #else
> <       double __ieee754_acosh(x)
> <       double x;
> < #endif
> < {
> ---
>> private static final class Acosh {
>>       private static final double one = 1.0;
>>       private static final double ln2 = 6.93147180559945286227e-01;
>>       static double compute(double x) {
> 41c29
> <               return __ieee754_log(x)+ln2;    /* acosh(huge)=log(2x) */
> ---
>>                               return log(x)+ln2;   /* acosh(huge)=log(2x) */
> 46c34
> <           return __ieee754_log(2.0*x-one/(x+sqrt(t-one)));
> ---
>>                       return log(2.0*x-one/(x+sqrt(t-one)));
> 49a38
>>               }
> 
> 
> 
> Transliteration vs more idiomatic port:
> 
> $ diff -w Acosh.translit.java Acosh.fdlibm.java
> 5,7c5,9
> <  * Based on
> <  *  acosh(x) = log [ x + sqrt(x*x-1) ]
> <  *  we have
> ---
>>  *
>>  *
>>  *      acosh(x) is defined so that acosh(cosh(alpha)) = alpha, -INF < alpha < < INF
>>  *      and cosh(acosh(x)) = x, 1 <= x  < INF.
>>  *      It can be written as acosh(x) = ln(x + sqrt(x^2 - 1)), 1 <= x  < INF.
> 11a14,15
>>  *
>>  *
> 16,17c20
> < private static final class Acosh {
> <       private static final double one = 1.0;
> ---
>> static final class Acosh {
> 18a22
>>
> 23c27
> <               if(hx<0x3ff00000) {      /* x < 1 */
> ---
>>               if(hx < 0x3ff00000) {                           // x < 1 */
> 25,26c29,30
> <               } else if(hx >=0x41b00000) {    /* x > 2**28 */
> <                       if(hx >=0x7ff00000) {    /* x is inf of NaN */
> ---
>>               } else if (hx >= 0x41b00000) {                  // x > 2**28
>>                       if(hx >= 0x7ff00000) {                      // x is inf of NaN
> 28,29c32,34
> <                       } else
> <                               return log(x)+ln2;   /* acosh(huge)=log(2x) *...

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

  8376665: Fixed definition of inverse cosh.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29488/files
  - new: https://git.openjdk.org/jdk/pull/29488/files/44147eb7..fceec2f1

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

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

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

From aartemov at openjdk.org  Wed Feb  4 09:12:13 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 4 Feb 2026 09:12:13 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v7]
In-Reply-To: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
Message-ID: <SLa8IJFaOz6AIb3MSfYTNyT_FWyBnDojbpC-rPNYI3E=.21b761f1-bbce-474e-a9d8-bb32f60b530f@github.com>

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM asinh method.
> 
> Original C vs transliteration port:
> 
> 
> $ diff -w fdlib_asinh.c Asinh.translit.java
> 1c1,3
> < /* asinh(x)
> ---
>> /**
>> * Return the Inverse Hyperbolic Sine of x
>> *
> 2a5
>> *
> 10a14,17
>> private static final class Asinh {
>>       private static final double one = 1.0;
>>       private static final double ln2 = 6.93147180559945286227e-01;
>>       private static final double huge = 1.0e300;
> 12,29c19
> < #include "fdlibm.h"
> <
> < #ifdef __STDC__
> < static const double
> < #else
> < static double
> < #endif
> < one =  1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */
> < ln2 =  6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */
> < huge=  1.00000000000000000000e+300;
> <
> < #ifdef __STDC__
> <       double asinh(double x)
> < #else
> <       double asinh(x)
> <       double x;
> < #endif
> < {
> ---
>>       static double compute(double x) {
> 39c29
> <           w = __ieee754_log(fabs(x))+ln2;
> ---
>>                       w = log(Math.abs(x))+ln2;
> 41,42c31,32
> <           t = fabs(x);
> <           w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t));
> ---
>>                       t = Math.abs(x);
>>                       w = log(2.0*t+one/(sqrt(x*x+one)+t));
> 45c35
> <           w =log1p(fabs(x)+t/(one+sqrt(one+t)));
> ---
>>                       w =log1p(Math.abs(x)+t/(one+sqrt(one+t)));
> 47a38
>>       }
> 
> Transliteration port vs more idiomatic port:
> 
> 
> $ diff -w Asinh.translit.java Asinh.fdlibm.java
> 6,9c6,12
> < *  Based on
> < *    asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ]
> < *   we have
> < *   asinh(x) := x  if  1+x*x=1,
> ---
>>  *
>>  *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF
>>  *      and sinh(asinh(x)) = x, -INF < x  < INF.
>>  *      It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x  < INF.
>>  *      1. Replace x by |x| as the function is odd.
>>  *      2.
>>  *          asinh(x) := x, if 1+x^2 = 1,
> 12a16,22
>>  *
>>  *
>>  *
>>  * Special cases:
>>  *      only asinh(0)=0 is exact for finite x.
>>  *      asinh(NaN) is NaN
>>  *      asinh(INF) is INF
> 14,15c24
> < private static final class Asinh {
> <       private static final double one = 1.0;
> ---
>> static final class Asinh {
> 24c33,35
> <               if(ix>=0x7ff00000) return x+x;  /* x is inf or NaN */
> ---
>>               if(ix >= 0x7ff00000) {
>>                       return x + x;                       /* x is inf or NaN */
>>               }
> 26c37,39
> <                       if(huge+x>one) return x;    /* return x inexact except 0...

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

  8375285: Addressed reviewer's comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29273/files
  - new: https://git.openjdk.org/jdk/pull/29273/files/071df0ff..4f3a0acd

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

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

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

From aartemov at openjdk.org  Wed Feb  4 09:12:23 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 4 Feb 2026 09:12:23 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v6]
In-Reply-To: <dxWIp-tMsVvqDAmOtYPBFNMXZyuX-5bC956EuqnHU9s=.af382f1a-d0f1-440c-9f45-673d14bea4c3@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <bmbeeFjqHyafsodO2lP5Jrll5EkLzk7KBAw5abnaYio=.9a231fce-2ee9-4080-93ab-5d9ef54a0915@github.com>
 <dxWIp-tMsVvqDAmOtYPBFNMXZyuX-5bC956EuqnHU9s=.af382f1a-d0f1-440c-9f45-673d14bea4c3@github.com>
Message-ID: <LJIS9vg4djrFt3lvtMTzsmdWrO4PhYJtZ8-wRAP2RB8=.b5d42431-7233-4886-95a0-4d248683ebdc@github.com>

On Tue, 3 Feb 2026 14:35:15 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8375285: Added missed link in documentation.
>
> src/java.base/share/classes/java/lang/FdLibm.java line 3518:
> 
>> 3516:      *
>> 3517:      *
>> 3518:      *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha, -INF < alpha < < INF
> 
> Suggestion:
> 
>      *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha, -&infin; &lt; alpha &lt; &infin;
> 
> &infin; looks better
> &lt; avoids confusing an HTML parser (not sure if it really needed, though)

Addressed.

> src/java.base/share/classes/java/lang/FdLibm.java line 3519:
> 
>> 3517:      *
>> 3518:      *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha, -INF < alpha < < INF
>> 3519:      *      and sinh(asinh(x)) = x, -INF < x  < INF.
> 
> Similarly

Addressed.

> src/java.base/share/classes/java/lang/FdLibm.java line 3520:
> 
>> 3518:      *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha, -INF < alpha < < INF
>> 3519:      *      and sinh(asinh(x)) = x, -INF < x  < INF.
>> 3520:      *      It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x  < INF.
> 
> This is not the formulation in the original fdlibm code.

Thanks for spotting, missed the modulus braces. Addressed.

> src/java.base/share/classes/java/lang/FdLibm.java line 3531:
> 
>> 3529:      *
>> 3530:      * Special cases:
>> 3531:      *      only asinh(0)=0 is exact for finite x.
> 
> Suggestion:
> 
>      *      only asinh(&plusmn;0) = &plusmn;0 is exact for finite x.

Added as suggested.

> src/java.base/share/classes/java/lang/FdLibm.java line 3533:
> 
>> 3531:      *      only asinh(0)=0 is exact for finite x.
>> 3532:      *      asinh(NaN) is NaN
>> 3533:      *      asinh(INF) is INF
> 
> Suggestion:
> 
>      *      asinh(&plusmn;&infin;) = &plusmn;&infin;

Added as suggested.

> src/java.base/share/classes/java/lang/FdLibm.java line 3543:
> 
>> 3541:             int hx, ix;
>> 3542:             hx = __HI(x);
>> 3543:             ix = hx & 0x7fffffff;
> 
> Suggestion:
> 
>             ix = hx & 0x7fff_ffff;
> 
> as well as other hexadecimal literals below. It's easier for counting whether the number of hex digits is correct.

Noted!

> src/java.base/share/classes/java/lang/Math.java line 2765:
> 
>> 2763:      * The inverse hyperbolic sine of <i>x</i> is defined to be a function such that
>> 2764:      *  asinh({@linkplain Math#sinh sinh(<i>x</i>)}) = <i>x</i> for any <i>x</i>.
>> 2765:      *  Note that range of the exact asinh is not limited.
> 
> Suggestion:
> 
>      *  Note that domain of the exact asinh is unrestricted.

I addressed it by adding "Note that both range and domain of the exact asinh are unrestricted."

> src/java.base/share/classes/java/lang/Math.java line 2777:
> 
>> 2775:      * <li>If the argument is negative infinity, then the result is
>> 2776:      * negative infinity.
>> 2777:      *
> 
> It is possible to collapse both items into one, as is done for the zero case.

Addressed.

> src/java.base/share/classes/java/lang/StrictMath.java line 2197:
> 
>> 2195:      * @return  The inverse hyperbolic sine of {@code x}.
>> 2196:      * @since 27
>> 2197:      */
> 
> See the comment for Math

Addressed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2762955015
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2762954739
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2762954466
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2762954104
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2762953749
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2762953420
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2762952878
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2762952386
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2762952264

From aph at openjdk.org  Wed Feb  4 09:36:34 2026
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 4 Feb 2026 09:36:34 GMT
Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for
 unsigned min/max reduction operations [v5]
In-Reply-To: <SbpbEN5HJpm8AaXs-K3czwJPgxj59bb_vwNKhZM9q4o=.abd23cad-9248-471c-9aa8-3d88f21abe20@github.com>
References: <Q2wrStWVzJWL-6b6lxC3eCQv465aVRUdX5Kr95rT5bE=.38082a7b-70c9-4731-8d80-a8927b87f435@github.com>
 <SbpbEN5HJpm8AaXs-K3czwJPgxj59bb_vwNKhZM9q4o=.abd23cad-9248-471c-9aa8-3d88f21abe20@github.com>
Message-ID: <_i_8zMecp9cxkqiTboxmeTUtT3huxSc4bBDpI2OFUPk=.90436105-d433-43ac-8a4d-1429c02faa01@github.com>

On Wed, 4 Feb 2026 02:38:18 GMT, Eric Fang <erfang at openjdk.org> wrote:

>> This patch adds intrinsic support for UMIN and UMAX reduction operations in the Vector API on AArch64, enabling direct hardware instruction mapping for better performance.
>> 
>> Changes:
>> --------
>> 
>> 1. C2 mid-end:
>>    - Added UMinReductionVNode and UMaxReductionVNode
>> 
>> 2. AArch64 Backend:
>>    - Added uminp/umaxp/sve_uminv/sve_umaxv instructions
>>    - Updated match rules for all vector sizes and element types
>>    - Both NEON and SVE implementation are supported
>> 
>> 3. Test:
>>    - Added UMIN_REDUCTION_V and UMAX_REDUCTION_V to IRNode.java
>>    - Added assembly tests in aarch64-asmtest.py for new instructions
>>    - Added a JTReg test file VectorUMinMaxReductionTest.java
>> 
>> Different configurations were tested on aarch64 and x86 machines, and all tests passed.
>> 
>> Test results of JMH benchmarks from the panama-vector project:
>> --------
>> 
>> On a Nvidia Grace machine with 128-bit SVE:
>> 
>> Benchmark                       Unit    Before  Error   After           Error   Uplift
>> Byte128Vector.UMAXLanes         ops/ms  411.60  42.18   25226.51        33.92   61.29
>> Byte128Vector.UMAXMaskedLanes   ops/ms  558.56  85.12   25182.90        28.74   45.09
>> Byte128Vector.UMINLanes         ops/ms  645.58  780.76  28396.29        103.11  43.99
>> Byte128Vector.UMINMaskedLanes   ops/ms  621.09  718.27  26122.62        42.68   42.06
>> Byte64Vector.UMAXLanes          ops/ms  296.33  34.44   14357.74        15.95   48.45
>> Byte64Vector.UMAXMaskedLanes    ops/ms  376.54  44.01   14269.24        21.41   37.90
>> Byte64Vector.UMINLanes          ops/ms  373.45  426.51  15425.36        66.20   41.31
>> Byte64Vector.UMINMaskedLanes    ops/ms  353.32  346.87  14201.37        13.79   40.19
>> Int128Vector.UMAXLanes          ops/ms  174.79  192.51  9906.07         286.93  56.67
>> Int128Vector.UMAXMaskedLanes    ops/ms  157.23  206.68  10246.77        11.44   65.17
>> Int64Vector.UMAXLanes           ops/ms  95.30   126.49  4719.30         98.57   49.52
>> Int64Vector.UMAXMaskedLanes     ops/ms  88.19   87.44   4693.18         19.76   53.22
>> Long128Vector.UMAXLanes         ops/ms  80.62   97.82   5064.01         35.52   62.82
>> Long128Vector.UMAXMaskedLanes   ops/ms  78.15   102.91  5028.24         8.74    64.34
>> Long64Vector.UMAXLanes          ops/ms  47.56   62.01   46.76           52.28   0.98
>> Long64Vector.UMAXMaskedLanes    ops/ms  45.44   46.76   45.79           42.91   1.01
>> Short128Vector.UMAXLanes        ops/ms  316.65  410.30  14814.82        23.65   46.79
>> ...
>
> Eric Fang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add JMH benchmark VectorUMinUMaxReductionBenchmark.java
>   
>   Also refined the helper functions.

Looks good, thanks.

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

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28693#pullrequestreview-3749977270

From rgiulietti at openjdk.org  Wed Feb  4 11:14:29 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 4 Feb 2026 11:14:29 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v7]
In-Reply-To: <SLa8IJFaOz6AIb3MSfYTNyT_FWyBnDojbpC-rPNYI3E=.21b761f1-bbce-474e-a9d8-bb32f60b530f@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <SLa8IJFaOz6AIb3MSfYTNyT_FWyBnDojbpC-rPNYI3E=.21b761f1-bbce-474e-a9d8-bb32f60b530f@github.com>
Message-ID: <ZxsLgv4UkoBPrPJeLUGboTDzj5eV66JNgqA9hvbGh1U=.e63c176e-be94-4475-aa6b-c63690c5625a@github.com>

On Wed, 4 Feb 2026 09:12:13 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM asinh method.
>> 
>> Original C vs transliteration port:
>> 
>> 
>> $ diff -w fdlib_asinh.c Asinh.translit.java
>> 1c1,3
>> < /* asinh(x)
>> ---
>>> /**
>>> * Return the Inverse Hyperbolic Sine of x
>>> *
>> 2a5
>>> *
>> 10a14,17
>>> private static final class Asinh {
>>>       private static final double one = 1.0;
>>>       private static final double ln2 = 6.93147180559945286227e-01;
>>>       private static final double huge = 1.0e300;
>> 12,29c19
>> < #include "fdlibm.h"
>> <
>> < #ifdef __STDC__
>> < static const double
>> < #else
>> < static double
>> < #endif
>> < one =  1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */
>> < ln2 =  6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */
>> < huge=  1.00000000000000000000e+300;
>> <
>> < #ifdef __STDC__
>> <       double asinh(double x)
>> < #else
>> <       double asinh(x)
>> <       double x;
>> < #endif
>> < {
>> ---
>>>       static double compute(double x) {
>> 39c29
>> <           w = __ieee754_log(fabs(x))+ln2;
>> ---
>>>                       w = log(Math.abs(x))+ln2;
>> 41,42c31,32
>> <           t = fabs(x);
>> <           w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t));
>> ---
>>>                       t = Math.abs(x);
>>>                       w = log(2.0*t+one/(sqrt(x*x+one)+t));
>> 45c35
>> <           w =log1p(fabs(x)+t/(one+sqrt(one+t)));
>> ---
>>>                       w =log1p(Math.abs(x)+t/(one+sqrt(one+t)));
>> 47a38
>>>       }
>> 
>> Transliteration port vs more idiomatic port:
>> 
>> 
>> $ diff -w Asinh.translit.java Asinh.fdlibm.java
>> 6,9c6,12
>> < *  Based on
>> < *    asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ]
>> < *   we have
>> < *   asinh(x) := x  if  1+x*x=1,
>> ---
>>>  *
>>>  *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF
>>>  *      and sinh(asinh(x)) = x, -INF < x  < INF.
>>>  *      It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x  < INF.
>>>  *      1. Replace x by |x| as the function is odd.
>>>  *      2.
>>>  *          asinh(x) := x, if 1+x^2 = 1,
>> 12a16,22
>>>  *
>>>  *
>>>  *
>>>  * Special cases:
>>>  *      only asinh(0)=0 is exact for finite x.
>>>  *      asinh(NaN) is NaN
>>>  *      asinh(INF) is INF
>> 14,15c24
>> < private static final class Asinh {
>> <       private static final double one = 1.0;
>> ---
>>> static final class Asinh {
>> 24c33,35
>> <               if(ix>=0x7ff00000) return x+x;  /* x is inf or NaN */
>> ---
>>>               if(ix >= 0x7ff00000) {
>>>                       return x...
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8375285: Addressed reviewer's comments.

src/java.base/share/classes/java/lang/FdLibm.java line 3514:

> 3512:     /**
> 3513:      * Return the Inverse Hyperbolic Sine of x
> 3514:      *

This is inside a javadoc comment.
If you want structuring into paragraphs, you need to add `<p>` at the beginning of new paragraphs, except the 1st.

Alternatively, you could convert to a block comment. In a block comment you can use `<` rather than `&lt;`, but then all the `&...;` HTML named entities make no much sense.

src/java.base/share/classes/java/lang/FdLibm.java line 3520:

> 3518:      *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha, -&infin; &lt; alpha &lt; &infin;
> 3519:      *      and sinh(asinh(x)) = x, -&infin; &lt; x &lt; &infin;
> 3520:      *      It can be written as asinh(x) = ln(|x| + sqrt(x^2 + 1)), -&infin; &lt; x &lt; &infin;

Suggestion:

     *      It can be written as asinh(x) = sign(x) * ln(|x| + sqrt(x^2 + 1)), -&infin; &lt; x &lt; &infin;

src/java.base/share/classes/java/lang/FdLibm.java line 3547:

> 3545:                 return x + x;                       // x is inf or NaN
> 3546:             }
> 3547:             if (ix < 0x3e300000) {                   // |x| < 2**-28

Suggestion:

            if (ix < 0x3e30_0000) {                   // |x| < 2**-28

src/java.base/share/classes/java/lang/Math.java line 2763:

> 2761:     /**
> 2762:      * Returns the inverse hyperbolic sine of a {@code double} value.
> 2763:      * The inverse hyperbolic sine of <i>x</i> is defined to be a function such that

Suggestion:

     * The inverse hyperbolic sine of <i>x</i> is defined to be the function such that

Using "the" emphasises that the function is unique.

src/java.base/share/classes/java/lang/Math.java line 2765:

> 2763:      * The inverse hyperbolic sine of <i>x</i> is defined to be a function such that
> 2764:      *  asinh({@linkplain Math#sinh sinh(<i>x</i>)}) = <i>x</i> for any <i>x</i>.
> 2765:      *  Note that both range and domain of the exact asinh are unrestricted.

Suggestion:

     *  Note that both domain and range of the exact asinh are unrestricted.

I think that putting the domain first is more important for usage.

src/java.base/share/classes/java/lang/Math.java line 2773:

> 2771:      *
> 2772:      * <li>If the argument is infinity, then the result is
> 2773:      * negative infinity with the same sign as the argument.

Suggestion:

     * infinity with the same sign as the argument.

src/java.base/share/classes/java/lang/Math.java line 2777:

> 2775:      * <li>If the argument is NaN, then the result is NaN.
> 2776:      *
> 2777:      * <p>The computed result must be within 2.5 ulps of the exact result.

This paragraph should come _after_ the bulleted list.

src/java.base/share/classes/java/lang/StrictMath.java line 2194:

> 2192:      * @return  The inverse hyperbolic sine of {@code x}.
> 2193:      * @since 27
> 2194:      */

Same comments as for Math.

test/jdk/java/lang/Math/HyperbolicTests.java line 1413:

> 1411:      * Therefore,
> 1412:      *
> 1413:      * 1. For large values of x asinh(x) ~= signum(x)

I don't get this.
signum() is either 1, -1, or 0.

test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 2761:

> 2759: 
> 2760:     /**
> 2761:     * Return the Inverse Hyperbolic Sine of x

I suggest turning this into a block comment, and adjust the indentation by one space in the lines below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763380563
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763380747
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763380943
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763405124
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763405402
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763405924
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763409861
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763413777
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763430265
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763458993

From aturbanov at openjdk.org  Wed Feb  4 11:44:02 2026
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 4 Feb 2026 11:44:02 GMT
Subject: RFR: 8377116: Refactor java/util/zip TestNG tests to JUnit
In-Reply-To: <QPduW9IIUl5rdWQ4uTQpnO_2yqX8E2sZO12uTEE2oaE=.40f85d49-bac5-4b73-88d2-4ff597a6ba46@github.com>
References: <QPduW9IIUl5rdWQ4uTQpnO_2yqX8E2sZO12uTEE2oaE=.40f85d49-bac5-4b73-88d2-4ff597a6ba46@github.com>
Message-ID: <TRWdVEcWu54RR1BM6St_rDipF_02bHi6xFXS-4hEaTM=.f5e90c60-37b3-4cf0-847b-db5e86c3d609@github.com>

On Tue, 3 Feb 2026 22:09:58 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR consists of a conversion for the java/util/zip TestNG tests to JUnit. Changes are mainly automated. https://github.com/openjdk/jdk/commit/1aeb8a634b8f255853516015f4b39bd79dd94090 is required to resolve a failure since JUnit parameterized tests automatically close arguments that implement `AutoCloseable`.
> 
> Test stats before:
> Framework-based tests: 274 = 107 TestNG + 167 JUnit
> 
> Test stats after:
> Framework-based tests: 274 = 0 TestNG + 274 JUnit

test/jdk/java/util/zip/ZipFile/InvalidCommentLengthTest.java line 343:

> 341:      */
> 342:     @Test
> 343:     public void JarFileInValidCommentLengthTest()  {

Suggestion:

    public void JarFileInValidCommentLengthTest() {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29552#discussion_r2763577838

From aartemov at openjdk.org  Wed Feb  4 11:59:32 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 4 Feb 2026 11:59:32 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v8]
In-Reply-To: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
Message-ID: <p57-Mga85sxN41Hdd9JTLGNVazIrkfDjNtCIhz70-ME=.86050f09-06e0-4c6e-80ac-39794153f806@github.com>

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM asinh method.
> 
> Original C vs transliteration port:
> 
> 
> $ diff -w fdlib_asinh.c Asinh.translit.java
> 1c1,3
> < /* asinh(x)
> ---
>> /**
>> * Return the Inverse Hyperbolic Sine of x
>> *
> 2a5
>> *
> 10a14,17
>> private static final class Asinh {
>>       private static final double one = 1.0;
>>       private static final double ln2 = 6.93147180559945286227e-01;
>>       private static final double huge = 1.0e300;
> 12,29c19
> < #include "fdlibm.h"
> <
> < #ifdef __STDC__
> < static const double
> < #else
> < static double
> < #endif
> < one =  1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */
> < ln2 =  6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */
> < huge=  1.00000000000000000000e+300;
> <
> < #ifdef __STDC__
> <       double asinh(double x)
> < #else
> <       double asinh(x)
> <       double x;
> < #endif
> < {
> ---
>>       static double compute(double x) {
> 39c29
> <           w = __ieee754_log(fabs(x))+ln2;
> ---
>>                       w = log(Math.abs(x))+ln2;
> 41,42c31,32
> <           t = fabs(x);
> <           w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t));
> ---
>>                       t = Math.abs(x);
>>                       w = log(2.0*t+one/(sqrt(x*x+one)+t));
> 45c35
> <           w =log1p(fabs(x)+t/(one+sqrt(one+t)));
> ---
>>                       w =log1p(Math.abs(x)+t/(one+sqrt(one+t)));
> 47a38
>>       }
> 
> Transliteration port vs more idiomatic port:
> 
> 
> $ diff -w Asinh.translit.java Asinh.fdlibm.java
> 6,9c6,12
> < *  Based on
> < *    asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ]
> < *   we have
> < *   asinh(x) := x  if  1+x*x=1,
> ---
>>  *
>>  *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF
>>  *      and sinh(asinh(x)) = x, -INF < x  < INF.
>>  *      It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x  < INF.
>>  *      1. Replace x by |x| as the function is odd.
>>  *      2.
>>  *          asinh(x) := x, if 1+x^2 = 1,
> 12a16,22
>>  *
>>  *
>>  *
>>  * Special cases:
>>  *      only asinh(0)=0 is exact for finite x.
>>  *      asinh(NaN) is NaN
>>  *      asinh(INF) is INF
> 14,15c24
> < private static final class Asinh {
> <       private static final double one = 1.0;
> ---
>> static final class Asinh {
> 24c33,35
> <               if(ix>=0x7ff00000) return x+x;  /* x is inf or NaN */
> ---
>>               if(ix >= 0x7ff00000) {
>>                       return x + x;                       /* x is inf or NaN */
>>               }
> 26c37,39
> <                       if(huge+x>one) return x;    /* return x inexact except 0...

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

  8375285: Addressed reviewer's comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29273/files
  - new: https://git.openjdk.org/jdk/pull/29273/files/4f3a0acd..d8e231c7

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

  Stats: 27 lines in 5 files changed: 1 ins; 3 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/29273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29273/head:pull/29273

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

From aartemov at openjdk.org  Wed Feb  4 11:59:43 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 4 Feb 2026 11:59:43 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v7]
In-Reply-To: <ZxsLgv4UkoBPrPJeLUGboTDzj5eV66JNgqA9hvbGh1U=.e63c176e-be94-4475-aa6b-c63690c5625a@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <SLa8IJFaOz6AIb3MSfYTNyT_FWyBnDojbpC-rPNYI3E=.21b761f1-bbce-474e-a9d8-bb32f60b530f@github.com>
 <ZxsLgv4UkoBPrPJeLUGboTDzj5eV66JNgqA9hvbGh1U=.e63c176e-be94-4475-aa6b-c63690c5625a@github.com>
Message-ID: <mh3-dP7NY-1ZPkNndhiCi4H1X1P83kSN775ed0jTm_o=.3557dcfe-6b5c-4b39-9cf1-a17ab2c8cec0@github.com>

On Wed, 4 Feb 2026 10:50:00 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8375285: Addressed reviewer's comments.
>
> src/java.base/share/classes/java/lang/FdLibm.java line 3514:
> 
>> 3512:     /**
>> 3513:      * Return the Inverse Hyperbolic Sine of x
>> 3514:      *
> 
> This is inside a javadoc comment.
> If you want structuring into paragraphs, you need to add `<p>` at the beginning of new paragraphs, except the 1st.
> 
> Alternatively, you could convert to a block comment. In a block comment you can use `<` rather than `&lt;`, but then all the `&...;` HTML named entities make no much sense.

I do not see any other method in FdLibm.java having this type paragraph formatting in place.  I will keep it as it is.

> src/java.base/share/classes/java/lang/FdLibm.java line 3520:
> 
>> 3518:      *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha, -&infin; &lt; alpha &lt; &infin;
>> 3519:      *      and sinh(asinh(x)) = x, -&infin; &lt; x &lt; &infin;
>> 3520:      *      It can be written as asinh(x) = ln(|x| + sqrt(x^2 + 1)), -&infin; &lt; x &lt; &infin;
> 
> Suggestion:
> 
>      *      It can be written as asinh(x) = sign(x) * ln(|x| + sqrt(x^2 + 1)), -&infin; &lt; x &lt; &infin;

Thanks for spotting.

> src/java.base/share/classes/java/lang/FdLibm.java line 3547:
> 
>> 3545:                 return x + x;                       // x is inf or NaN
>> 3546:             }
>> 3547:             if (ix < 0x3e300000) {                   // |x| < 2**-28
> 
> Suggestion:
> 
>             if (ix < 0x3e30_0000) {                   // |x| < 2**-28

Yes, missed that one.

> src/java.base/share/classes/java/lang/Math.java line 2763:
> 
>> 2761:     /**
>> 2762:      * Returns the inverse hyperbolic sine of a {@code double} value.
>> 2763:      * The inverse hyperbolic sine of <i>x</i> is defined to be a function such that
> 
> Suggestion:
> 
>      * The inverse hyperbolic sine of <i>x</i> is defined to be the function such that
> 
> Using "the" emphasises that the function is unique.

Addressed.

> src/java.base/share/classes/java/lang/Math.java line 2765:
> 
>> 2763:      * The inverse hyperbolic sine of <i>x</i> is defined to be a function such that
>> 2764:      *  asinh({@linkplain Math#sinh sinh(<i>x</i>)}) = <i>x</i> for any <i>x</i>.
>> 2765:      *  Note that both range and domain of the exact asinh are unrestricted.
> 
> Suggestion:
> 
>      *  Note that both domain and range of the exact asinh are unrestricted.
> 
> I think that putting the domain first is more important for usage.

Yes, makes sense, addressed.

> src/java.base/share/classes/java/lang/Math.java line 2773:
> 
>> 2771:      *
>> 2772:      * <li>If the argument is infinity, then the result is
>> 2773:      * negative infinity with the same sign as the argument.
> 
> Suggestion:
> 
>      * infinity with the same sign as the argument.

That is a typo, thanks for spotting.

> src/java.base/share/classes/java/lang/Math.java line 2777:
> 
>> 2775:      * <li>If the argument is NaN, then the result is NaN.
>> 2776:      *
>> 2777:      * <p>The computed result must be within 2.5 ulps of the exact result.
> 
> This paragraph should come _after_ the bulleted list.

Moved out as suggested.

> src/java.base/share/classes/java/lang/StrictMath.java line 2194:
> 
>> 2192:      * @return  The inverse hyperbolic sine of {@code x}.
>> 2193:      * @since 27
>> 2194:      */
> 
> Same comments as for Math.

Addressed.

> test/jdk/java/lang/Math/HyperbolicTests.java line 1413:
> 
>> 1411:      * Therefore,
>> 1412:      *
>> 1413:      * 1. For large values of x asinh(x) ~= signum(x)
> 
> I don't get this.
> signum() is either 1, -1, or 0.

There is nothing wrong with the approx equality itself, but the whole statement is wrong, as the range is unrestricted. I removed this line.

> test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 2761:
> 
>> 2759: 
>> 2760:     /**
>> 2761:     * Return the Inverse Hyperbolic Sine of x
> 
> I suggest turning this into a block comment, and adjust the indentation by one space in the lines below.

I noticed that some methods in this file have doc-style comments, some have block comments. Addressed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763627144
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763627564
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763627901
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763628176
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763628507
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763628976
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763629790
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763630112
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763630703
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763631265

From duke at openjdk.org  Wed Feb  4 12:41:32 2026
From: duke at openjdk.org (Tatsunori Uchino)
Date: Wed, 4 Feb 2026 12:41:32 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v23]
In-Reply-To: <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
Message-ID: <SOaGMTY0_7qUDwbUhyXx1fuKFkP1NQvigq5gljLxPuA=.f0ead578-7107-4466-85ce-77c28982928d@github.com>

On Sun, 1 Feb 2026 12:55:29 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 two additional commits since the last revision:
> 
>  - Add comment
>  - Fix logic error

Can I commit test\jdk\java\nio\Buffer\build\tools\sp\Spp.class? It was generated by `genBasic.sh`. The other files were not changed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3847208289

From rgiulietti at openjdk.org  Wed Feb  4 13:37:01 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 4 Feb 2026 13:37:01 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v8]
In-Reply-To: <p57-Mga85sxN41Hdd9JTLGNVazIrkfDjNtCIhz70-ME=.86050f09-06e0-4c6e-80ac-39794153f806@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <p57-Mga85sxN41Hdd9JTLGNVazIrkfDjNtCIhz70-ME=.86050f09-06e0-4c6e-80ac-39794153f806@github.com>
Message-ID: <HTq4KPrH8lZTVHT6_D3Gi1gMTzernd90gAPzZVEJT5c=.953c4ce3-6ee4-4d4c-9036-92763471579d@github.com>

On Wed, 4 Feb 2026 11:59:32 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM asinh method.
>> 
>> Original C vs transliteration port:
>> 
>> 
>> $ diff -w fdlib_asinh.c Asinh.translit.java
>> 1c1,3
>> < /* asinh(x)
>> ---
>>> /**
>>> * Return the Inverse Hyperbolic Sine of x
>>> *
>> 2a5
>>> *
>> 10a14,17
>>> private static final class Asinh {
>>>       private static final double one = 1.0;
>>>       private static final double ln2 = 6.93147180559945286227e-01;
>>>       private static final double huge = 1.0e300;
>> 12,29c19
>> < #include "fdlibm.h"
>> <
>> < #ifdef __STDC__
>> < static const double
>> < #else
>> < static double
>> < #endif
>> < one =  1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */
>> < ln2 =  6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */
>> < huge=  1.00000000000000000000e+300;
>> <
>> < #ifdef __STDC__
>> <       double asinh(double x)
>> < #else
>> <       double asinh(x)
>> <       double x;
>> < #endif
>> < {
>> ---
>>>       static double compute(double x) {
>> 39c29
>> <           w = __ieee754_log(fabs(x))+ln2;
>> ---
>>>                       w = log(Math.abs(x))+ln2;
>> 41,42c31,32
>> <           t = fabs(x);
>> <           w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t));
>> ---
>>>                       t = Math.abs(x);
>>>                       w = log(2.0*t+one/(sqrt(x*x+one)+t));
>> 45c35
>> <           w =log1p(fabs(x)+t/(one+sqrt(one+t)));
>> ---
>>>                       w =log1p(Math.abs(x)+t/(one+sqrt(one+t)));
>> 47a38
>>>       }
>> 
>> Transliteration port vs more idiomatic port:
>> 
>> 
>> $ diff -w Asinh.translit.java Asinh.fdlibm.java
>> 6,9c6,12
>> < *  Based on
>> < *    asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ]
>> < *   we have
>> < *   asinh(x) := x  if  1+x*x=1,
>> ---
>>>  *
>>>  *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF
>>>  *      and sinh(asinh(x)) = x, -INF < x  < INF.
>>>  *      It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x  < INF.
>>>  *      1. Replace x by |x| as the function is odd.
>>>  *      2.
>>>  *          asinh(x) := x, if 1+x^2 = 1,
>> 12a16,22
>>>  *
>>>  *
>>>  *
>>>  * Special cases:
>>>  *      only asinh(0)=0 is exact for finite x.
>>>  *      asinh(NaN) is NaN
>>>  *      asinh(INF) is INF
>> 14,15c24
>> < private static final class Asinh {
>> <       private static final double one = 1.0;
>> ---
>>> static final class Asinh {
>> 24c33,35
>> <               if(ix>=0x7ff00000) return x+x;  /* x is inf or NaN */
>> ---
>>>               if(ix >= 0x7ff00000) {
>>>                       return x...
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8375285: Addressed reviewer's comments.

Hopefully the last nits.

src/java.base/share/classes/java/lang/FdLibm.java line 3531:

> 3529:      *
> 3530:      * Special cases:
> 3531:      *      only asinh(&plusmn;0))=&plusmn;0) is exact for finite x.

There are two `)` too much.

test/jdk/java/lang/Math/HyperbolicTests.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 4851625 4900189 4939441

Not sure if this requires the new bug ID.

test/jdk/java/lang/Math/HyperbolicTests.java line 1533:

> 1531: 
> 1532: 
> 1533:         for (int i = 0; i < testCases.length; i++) {

Why not enhanced `for`, like in the NaN loop below?

test/jdk/java/lang/Math/HyperbolicTests.java line 1712:

> 1710:     }
> 1711: 
> 1712:     public static int testAsinhCaseWithTolerance(double input,

This method is never invoked, IIUC.

test/jdk/java/lang/StrictMath/ExhaustingTests.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8301833 8302026 8301444 8302028 8302040 8302027 8304028

Bug ID? Not sure.

test/jdk/java/lang/StrictMath/HyperbolicTests.java line 29:

> 27: /*
> 28:  * @test
> 29:  * @bug 4851625 8301444

Not sure if this requires the new bug ID.

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

PR Review: https://git.openjdk.org/jdk/pull/29273#pullrequestreview-3751044142
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2764000347
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2764034158
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2764001683
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2764002126
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2764043243
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2764039946

From rgiulietti at openjdk.org  Wed Feb  4 13:37:03 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 4 Feb 2026 13:37:03 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v7]
In-Reply-To: <mh3-dP7NY-1ZPkNndhiCi4H1X1P83kSN775ed0jTm_o=.3557dcfe-6b5c-4b39-9cf1-a17ab2c8cec0@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <SLa8IJFaOz6AIb3MSfYTNyT_FWyBnDojbpC-rPNYI3E=.21b761f1-bbce-474e-a9d8-bb32f60b530f@github.com>
 <ZxsLgv4UkoBPrPJeLUGboTDzj5eV66JNgqA9hvbGh1U=.e63c176e-be94-4475-aa6b-c63690c5625a@github.com>
 <mh3-dP7NY-1ZPkNndhiCi4H1X1P83kSN775ed0jTm_o=.3557dcfe-6b5c-4b39-9cf1-a17ab2c8cec0@github.com>
Message-ID: <q9bmy6_EGmISQrXAyCAAmNfEui3v4qK9HuUPT0si8eM=.20c49f16-f0a3-496d-be3c-2a30c73d8744@github.com>

On Wed, 4 Feb 2026 11:53:53 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/FdLibm.java line 3514:
>> 
>>> 3512:     /**
>>> 3513:      * Return the Inverse Hyperbolic Sine of x
>>> 3514:      *
>> 
>> This is inside a javadoc comment.
>> If you want structuring into paragraphs, you need to add `<p>` at the beginning of new paragraphs, except the 1st.
>> 
>> Alternatively, you could convert to a block comment. In a block comment you can use `<` rather than `&lt;`, but then all the `&...;` HTML named entities make no much sense.
>
> I do not see any other method in FdLibm.java having this type paragraph formatting in place.  I will keep it as it is.

True, but IMO that doesn't mean new code can't do better ?.
The rendered javadoc comment looks ugly in the IDE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2763999862

From alanb at openjdk.org  Wed Feb  4 14:26:21 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Feb 2026 14:26:21 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v23]
In-Reply-To: <SOaGMTY0_7qUDwbUhyXx1fuKFkP1NQvigq5gljLxPuA=.f0ead578-7107-4466-85ce-77c28982928d@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
 <SOaGMTY0_7qUDwbUhyXx1fuKFkP1NQvigq5gljLxPuA=.f0ead578-7107-4466-85ce-77c28982928d@github.com>
Message-ID: <jfcrhHwvEXVpWPHuwJ1oSTui4NklsllenBOn_Lxg0rg=.d62f250d-974a-453e-9d1a-487f42e8651f@github.com>

On Wed, 4 Feb 2026 12:39:07 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> Can I commit test\jdk\java\nio\Buffer\build\tools\sp\Spp.class? It was generated by `genBasic.sh`. The other files were not changed.

Only updated .java files should be commit, not the class files (or the class files for the tool).

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3847765110

From dl at openjdk.org  Wed Feb  4 14:38:03 2026
From: dl at openjdk.org (Doug Lea)
Date: Wed, 4 Feb 2026 14:38:03 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v31]
In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
Message-ID: <YBoyP1MKQyLS-izG5Tl-TFZdRZVGW0VF1Q3sNnFia7w=.7610284c-7d80-4eff-90e8-cc60d2afd7ea@github.com>

> Changes signal filtering to avoid possible starvation

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

 - Merge branch 'openjdk:master' into JDK-8373118
 - reduce interference after stalls
 - Avoid yield, for performance test
 - Don't oversignal LIFO
 - Try out different approach
 - Simplify scan mode control by moving and reworking topLevelExec and throwing on trim
 - Another set of contend vs deactivate vs park tradeoffs
 - Fix missing undo
 - Merge branch 'openjdk:master' into JDK-8373118
 - Use explicit store fences or atomics
 - ... and 33 more: https://git.openjdk.org/jdk/compare/40833d95...7ae93ed7

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28797/files
  - new: https://git.openjdk.org/jdk/pull/28797/files/a7f1d63f..7ae93ed7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=29-30

  Stats: 99514 lines in 1723 files changed: 50037 ins; 26428 del; 23049 mod
  Patch: https://git.openjdk.org/jdk/pull/28797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28797/head:pull/28797

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

From rriggs at openjdk.org  Wed Feb  4 14:44:56 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 4 Feb 2026 14:44:56 GMT
Subject: RFR: 8375585: Test java/lang/ProcessBuilder/PipelineLeaksFD.java
 failed [v4]
In-Reply-To: <RcWyeLjeptkC1ZUDvTukbnTXkeCPIOJtseYAcfk3jA8=.41f33014-ff91-431c-83a1-4595edb05669@github.com>
References: <RcWyeLjeptkC1ZUDvTukbnTXkeCPIOJtseYAcfk3jA8=.41f33014-ff91-431c-83a1-4595edb05669@github.com>
Message-ID: <Ci4eVbCCSEMkWEcEpXYBS7YVH1zinI7_Yl_oxUpuEYY=.40010794-41e3-4ec2-9215-44bc1a8a2ad8@github.com>

> Revised test to explicitly compare file descriptor info only from parent and child.
> If additional fd's are present in the child, it is hard to know their origin but they do not necessarily indicate a bug in Process launch.
>  
> Remove from the problem list.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge
 - Removed use of count.
 - Refactor checks of child pipe use against parent use.
   Removed simple counts of names as they were unreliable.
 - 8375585: Test java/lang/ProcessBuilder/PipelineLeaksFD.java failed
   Revised test to explicitly compare file descriptor info only from parent and child
   If additional fd's are present in the child, it is hard to know their origin
   but they do not necessarily indicate a bug in Process launch.

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

Changes: https://git.openjdk.org/jdk/pull/29530/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29530&range=03
  Stats: 84 lines in 3 files changed: 41 ins; 15 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/29530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29530/head:pull/29530

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

From lancea at openjdk.org  Wed Feb  4 16:01:58 2026
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 4 Feb 2026 16:01:58 GMT
Subject: RFR: 8377116: Refactor java/util/zip TestNG tests to JUnit
In-Reply-To: <QPduW9IIUl5rdWQ4uTQpnO_2yqX8E2sZO12uTEE2oaE=.40f85d49-bac5-4b73-88d2-4ff597a6ba46@github.com>
References: <QPduW9IIUl5rdWQ4uTQpnO_2yqX8E2sZO12uTEE2oaE=.40f85d49-bac5-4b73-88d2-4ff597a6ba46@github.com>
Message-ID: <k7Bj2RRs9MZskhW9EosboniBPqAu_rGI6gIqwmhxq9Y=.c60a5775-e55f-493b-a6e9-e096450e1f97@github.com>

On Tue, 3 Feb 2026 22:09:58 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR consists of a conversion for the java/util/zip TestNG tests to JUnit. Changes are mainly automated. https://github.com/openjdk/jdk/commit/1aeb8a634b8f255853516015f4b39bd79dd94090 is required to resolve a failure since JUnit parameterized tests automatically close arguments that implement `AutoCloseable`.
> 
> Test stats before:
> Framework-based tests: 274 = 107 TestNG + 167 JUnit
> 
> Test stats after:
> Framework-based tests: 274 = 0 TestNG + 274 JUnit

Thank you for starting the migration of the zip, jar, and zipfs tests 

A few comments on initial pass

test/jdk/java/util/zip/DeflaterDictionaryTests.java line 24:

> 22:  */
> 23: 
> 24: 

Please update the copyright date

test/jdk/java/util/zip/DeflaterDictionaryTests.java line 69:

> 67:      * @return invalid offset values
> 68:      */
> 69:     protected static IntStream invalidDictionaryOffsets() {

Please update comment to remove DataProvider

test/jdk/java/util/zip/DeflaterDictionaryTests.java line 112:

> 110:                     inflater.getAdler(), resultLength);
> 111: 
> 112:             Assertions.assertEquals(resultLength, SRC_DATA.length());

Please import the methods as done in other tests

test/jdk/java/util/zip/GZIP/GZIPOutputStreamHeaderTest.java line 25:

> 23: 
> 24: 
> 25: import org.junit.jupiter.api.Assertions;

Can we import the specific methods to be consistent with the other tests

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

PR Review: https://git.openjdk.org/jdk/pull/29552#pullrequestreview-3751760455
PR Review Comment: https://git.openjdk.org/jdk/pull/29552#discussion_r2764713283
PR Review Comment: https://git.openjdk.org/jdk/pull/29552#discussion_r2764725246
PR Review Comment: https://git.openjdk.org/jdk/pull/29552#discussion_r2764734375
PR Review Comment: https://git.openjdk.org/jdk/pull/29552#discussion_r2764625412

From rriggs at openjdk.org  Wed Feb  4 16:09:02 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 4 Feb 2026 16:09:02 GMT
Subject: RFR: 8375585: Test java/lang/ProcessBuilder/PipelineLeaksFD.java
 failed [v4]
In-Reply-To: <Ci4eVbCCSEMkWEcEpXYBS7YVH1zinI7_Yl_oxUpuEYY=.40010794-41e3-4ec2-9215-44bc1a8a2ad8@github.com>
References: <RcWyeLjeptkC1ZUDvTukbnTXkeCPIOJtseYAcfk3jA8=.41f33014-ff91-431c-83a1-4595edb05669@github.com>
 <Ci4eVbCCSEMkWEcEpXYBS7YVH1zinI7_Yl_oxUpuEYY=.40010794-41e3-4ec2-9215-44bc1a8a2ad8@github.com>
Message-ID: <uVanAtWpTJWpnzJEU8rUbkmYfWyG_oP4tZPzk2bd710=.4e235029-da94-4387-86a5-f3ee39c864d0@github.com>

On Wed, 4 Feb 2026 14:44:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Revised test to explicitly compare file descriptor info only from parent and child.
>> If additional fd's are present in the child, it is hard to know their origin but they do not necessarily indicate a bug in Process launch.
>>  
>> Remove from the problem list.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge
>  - Removed use of count.
>  - Refactor checks of child pipe use against parent use.
>    Removed simple counts of names as they were unreliable.
>  - 8375585: Test java/lang/ProcessBuilder/PipelineLeaksFD.java failed
>    Revised test to explicitly compare file descriptor info only from parent and child
>    If additional fd's are present in the child, it is hard to know their origin
>    but they do not necessarily indicate a bug in Process launch.

The merge and retest in the CI were successful, and a re-approval is needed.  Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/29530#issuecomment-3848332517

From naoto at openjdk.org  Wed Feb  4 16:58:27 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 4 Feb 2026 16:58:27 GMT
Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually
 blocking [v8]
In-Reply-To: <VzTaqxMVJQQZDOG9xLi8w_ec7vDkQOYWCcJQkx8w3Ks=.0690d70f-09aa-4e35-99ba-9c03f6fc4d6f@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
 <VzTaqxMVJQQZDOG9xLi8w_ec7vDkQOYWCcJQkx8w3Ks=.0690d70f-09aa-4e35-99ba-9c03f6fc4d6f@github.com>
Message-ID: <SGUes8mGM9qaxzEsUhq3Q_Ke9KWvYYZuOh8Wnm3NyIg=.9482a2df-e807-4dab-ab36-e591d6f513a6@github.com>

On Tue, 3 Feb 2026 20:15:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restores the original race condition

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/29493#issuecomment-3848583305

From naoto at openjdk.org  Wed Feb  4 16:58:30 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 4 Feb 2026 16:58:30 GMT
Subject: Integrated: 8340830: Console.readLine() and Console.printf() are
 mutually blocking
In-Reply-To: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
References: <wnhUQpQ39VMuxt_N8OUrG7BgIe-XH8R4AwRwUa8MtWY=.7218397c-160a-4d89-a63d-2df324a9373b@github.com>
Message-ID: <8b1MCIwQAErU29rehcb9f5FNlNMPoweq-qOblEiAfLE=.74eca29a-978a-48d2-af26-c083125afd5f@github.com>

On Thu, 29 Jan 2026 21:08:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant.

This pull request has now been integrated.

Changeset: 79229193
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/792291937f7403c9acf6c5eacf284c26c2a2857b
Stats:     326 lines in 4 files changed: 173 ins; 102 del; 51 mod

8340830: Console.readLine() and Console.printf() are mutually blocking

Reviewed-by: jlu, jpai, rriggs, vyazici

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

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

From sherman at openjdk.org  Wed Feb  4 17:57:59 2026
From: sherman at openjdk.org (Xueming Shen)
Date: Wed, 4 Feb 2026 17:57:59 GMT
Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass
 them to intrinsic entries [v7]
In-Reply-To: <kDaABPfdYICCDElAjcNrY1MR61aIQO58SdxFCgZfVRY=.de99cd78-43ef-4664-bd6c-641ed75d3173@github.com>
References: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
 <kDaABPfdYICCDElAjcNrY1MR61aIQO58SdxFCgZfVRY=.de99cd78-43ef-4664-bd6c-641ed75d3173@github.com>
Message-ID: <cXFcCTYCchi0X9ptjSiCfChtWpjJywNUIgLGqkpH7dM=.e674c270-9463-42d3-a8b4-4f0c68e35cfc@github.com>

On Tue, 3 Feb 2026 03:31:52 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support.
>> 
>> Patch add new lane type constants and pass them to vector intrinsic entry points.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolution

Testing tier1,tier2 & tier3: looks good.
bash jib.sh mach5 -- remote-build-and-test --job tier1,tier2,tier3 --id-tag pr-29481-with-hotspot
https://mach5.us.oracle.com/mdash/jobs/xuemingshen-pr-29481-with-hotspot-20260203-1712-40954590

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

PR Comment: https://git.openjdk.org/jdk/pull/29481#issuecomment-3848896208

From qamai at openjdk.org  Wed Feb  4 18:16:17 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 4 Feb 2026 18:16:17 GMT
Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass
 them to intrinsic entries [v7]
In-Reply-To: <kDaABPfdYICCDElAjcNrY1MR61aIQO58SdxFCgZfVRY=.de99cd78-43ef-4664-bd6c-641ed75d3173@github.com>
References: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
 <kDaABPfdYICCDElAjcNrY1MR61aIQO58SdxFCgZfVRY=.de99cd78-43ef-4664-bd6c-641ed75d3173@github.com>
Message-ID: <tcISFbisSIq_FajuTtz6BFDYcg6O03FZzIIW_jpCnaE=.a4860776-b84d-45c1-9cd2-79bc28bf4cf8@github.com>

On Tue, 3 Feb 2026 03:31:52 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support.
>> 
>> Patch add new lane type constants and pass them to vector intrinsic entry points.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolution

src/hotspot/share/prims/vectorSupport.hpp line 141:

> 139: 
> 140:   // Values in this enum correspond to the jdk.incubator.vector.LaneType ordinal values.
> 141:   enum LaneType {

Please specify the underlying type of this enum: `enum LaneType : int`. Otherwise, this will not work:

    VectorSupport::LaneType vltype = static_cast<VectorSupport::LaneType>(laneType->get_con());

It is because casting an integer to an unscoped enum is UB if `laneType->get_con()` does not fit into the range of the enum values.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2765349355

From pchilanomate at openjdk.org  Wed Feb  4 18:57:23 2026
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Feb 2026 18:57:23 GMT
Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for
 all cases [v4]
In-Reply-To: <RlKpHz3GaSmQpSjV0X7J16qaHE4VEbiuqayztSMIpy4=.c823d3bd-5388-49de-b034-4800dec34049@github.com>
References: <sbp120wZjbJcEpyWDT9It7wFl_zU1kXNiHz7QMkd6RA=.46fa522d-104a-4c6f-a18f-cb0f8f37cad4@github.com>
 <RlKpHz3GaSmQpSjV0X7J16qaHE4VEbiuqayztSMIpy4=.c823d3bd-5388-49de-b034-4800dec34049@github.com>
Message-ID: <yMiThnML6iRbPPoIrX2BtSOS7V1Yy4oSQkVOjigGC68=.b8997e11-6220-44f2-94dc-a8f5a14b0ec6@github.com>

On Wed, 4 Feb 2026 08:40:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace.
>> 
>> A summary of the changes:
>> 
>> - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state
>> - Thread::getStackTrace is changed to use async_get_stack_trace for all cases
>> - The SUSPENDED substate in VirtualThread is removed
>> - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in
>> - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace
>> 
>> The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait.
>> 
>> A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required.
>> 
>> Testing: tier1-5.  The changes has been already been tested in the loom repo for a few months.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8376568
>  - Merge branch 'master' into JDK-8376568
>  - Review feedback
>  - Improve asserts
>  - Cleanup
>  - Merge branch 'master' into Thread.getStackTrace
>  - Initial commit

Marked as reviewed by pchilanomate (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29461#pullrequestreview-3752799129

From jlu at openjdk.org  Wed Feb  4 18:58:44 2026
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 4 Feb 2026 18:58:44 GMT
Subject: RFR: 8377116: Refactor java/util/zip TestNG tests to JUnit [v2]
In-Reply-To: <QPduW9IIUl5rdWQ4uTQpnO_2yqX8E2sZO12uTEE2oaE=.40f85d49-bac5-4b73-88d2-4ff597a6ba46@github.com>
References: <QPduW9IIUl5rdWQ4uTQpnO_2yqX8E2sZO12uTEE2oaE=.40f85d49-bac5-4b73-88d2-4ff597a6ba46@github.com>
Message-ID: <4tl2MyOvU9l-XjBRlt-SePmy-XmV6jhibBA91nW6PVc=.39fa9675-3c91-403f-8c03-981e61c489cf@github.com>

> This PR consists of a conversion for the java/util/zip TestNG tests to JUnit. Changes are mainly automated. https://github.com/openjdk/jdk/commit/1aeb8a634b8f255853516015f4b39bd79dd94090 is required to resolve a failure since JUnit parameterized tests automatically close arguments that implement `AutoCloseable`.
> 
> Test stats before:
> Framework-based tests: 274 = 107 TestNG + 167 JUnit
> 
> Test stats after:
> Framework-based tests: 274 = 0 TestNG + 274 JUnit

Justin Lu has updated the pull request incrementally with three additional commits since the last revision:

 - Fixing other 'DataProvider' occurrences in JUnit tests under java/util/zip
 - Correct previous incorrect placement of actual/expected in assertions (Chen)
 - Use static imports everywhere + fix 'DataProvider' in comments (Alan, Lance)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29552/files
  - new: https://git.openjdk.org/jdk/pull/29552/files/2d14b660..fc5f5cc4

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

  Stats: 45 lines in 8 files changed: 5 ins; 4 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/29552.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29552/head:pull/29552

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

From jlu at openjdk.org  Wed Feb  4 18:58:45 2026
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 4 Feb 2026 18:58:45 GMT
Subject: RFR: 8377116: Refactor java/util/zip TestNG tests to JUnit [v2]
In-Reply-To: <fsBvO90fdY65D0v2ArcX7FC8wnl8Pq8RFXmTPqU_W-Q=.078e482d-7ed8-4e75-ae51-b73d8a7209b5@github.com>
References: <QPduW9IIUl5rdWQ4uTQpnO_2yqX8E2sZO12uTEE2oaE=.40f85d49-bac5-4b73-88d2-4ff597a6ba46@github.com>
 <fsBvO90fdY65D0v2ArcX7FC8wnl8Pq8RFXmTPqU_W-Q=.078e482d-7ed8-4e75-ae51-b73d8a7209b5@github.com>
Message-ID: <COChtZJgQOejz1LVuBDKYN4LxZuek5jNMb6pnucwzCc=.ec5c70a2-4fbb-486c-9181-f90089d448a3@github.com>

On Wed, 4 Feb 2026 04:04:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fixing other 'DataProvider' occurrences in JUnit tests under java/util/zip
>>  - Correct previous incorrect placement of actual/expected in assertions (Chen)
>>  - Use static imports everywhere + fix 'DataProvider' in comments (Alan, Lance)
>
> test/jdk/java/util/zip/DeflaterDictionaryTests.java line 113:
> 
>> 111: 
>> 112:             Assertions.assertEquals(resultLength, SRC_DATA.length());
>> 113:             Assertions.assertArrayEquals(Arrays.copyOf(result, resultLength), input);
> 
> I think we should restore the original order here - maybe someone used testng the junit way. Same below.

Thanks for spotting these incorrect ordering placements. Addressed in https://github.com/openjdk/jdk/pull/29552/commits/879b286da9ec08e3a3211fba42d5f8757478d224.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29552#discussion_r2765518712

From jlu at openjdk.org  Wed Feb  4 18:58:47 2026
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 4 Feb 2026 18:58:47 GMT
Subject: RFR: 8377116: Refactor java/util/zip TestNG tests to JUnit [v2]
In-Reply-To: <k7Bj2RRs9MZskhW9EosboniBPqAu_rGI6gIqwmhxq9Y=.c60a5775-e55f-493b-a6e9-e096450e1f97@github.com>
References: <QPduW9IIUl5rdWQ4uTQpnO_2yqX8E2sZO12uTEE2oaE=.40f85d49-bac5-4b73-88d2-4ff597a6ba46@github.com>
 <k7Bj2RRs9MZskhW9EosboniBPqAu_rGI6gIqwmhxq9Y=.c60a5775-e55f-493b-a6e9-e096450e1f97@github.com>
Message-ID: <LYPxl6fWRn5-ve4lU8kKpOk2KQ42fpJtjTSKvFJhZHk=.e3fe3ec4-8bfd-4957-a662-f0bb73355d06@github.com>

On Wed, 4 Feb 2026 15:34:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fixing other 'DataProvider' occurrences in JUnit tests under java/util/zip
>>  - Correct previous incorrect placement of actual/expected in assertions (Chen)
>>  - Use static imports everywhere + fix 'DataProvider' in comments (Alan, Lance)
>
> test/jdk/java/util/zip/GZIP/GZIPOutputStreamHeaderTest.java line 25:
> 
>> 23: 
>> 24: 
>> 25: import org.junit.jupiter.api.Assertions;
> 
> Can we import the specific methods to be consistent with the other tests

https://github.com/openjdk/jdk/pull/29552/commits/1fae2628d5bcfa9915a80c33060aca71060d7607 standardizes the imports and cleans up 'DataProvider' in the comments as you and Alan pointed out. https://github.com/openjdk/jdk/pull/29552/commits/fc5f5cc449b93a50a0e14c39d0ef28f01404026c also addresses other instances of 'DataProvider' (outside of the initial scope of files changed).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29552#discussion_r2765528459

From smarks at openjdk.org  Wed Feb  4 19:34:10 2026
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 4 Feb 2026 19:34:10 GMT
Subject: RFR: 8371656: HashMap.putAll() optimizations [v3]
In-Reply-To: <qhzibjtuAR2eqo3zVKsUuq1hVOE8pDmvGidnvyIRKhs=.8e143c26-cf0f-48c3-ac93-0ebde5c475e5@github.com>
References: <L9LdywP8aeyIW9SVHLEsRSUmuaa2vWWQyMW9pTrLtHA=.363bd16c-febb-4028-96b9-a01cdd0d86a2@github.com>
 <ueLHOkfYfe15Ur0RmZDF7j93vGs1x0w48Zib1mZ4rF0=.bba5969c-4504-4921-a6e7-0a1a39395f9b@github.com>
 <qhzibjtuAR2eqo3zVKsUuq1hVOE8pDmvGidnvyIRKhs=.8e143c26-cf0f-48c3-ac93-0ebde5c475e5@github.com>
Message-ID: <vS9t9OeNOR04IZ6kfefrchkEHDI8GPmcqh0xwou2COU=.36eee3e2-521a-46ff-a209-3d9f5f6c1845@github.com>

On Tue, 9 Dec 2025 16:38:44 GMT, jengebr <duke at openjdk.org> wrote:

>> jengebr has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into putMapEntriesOptimizations
>>  - Unit test revisions
>>  - Bug fix & unit test
>>  - fixing whitespace
>>  - Optimizing HashMap.putAll() and .<init> for HashMap and C$UM
>
> @stuart-marks would you mind reviewing this one?  It's conceptually similar to the ArrayList modifications, but applied to different classes and most details differ.  I incorporated lessons about MOAT so that part should be cleaner.

@jengebr Oops! Sorry, you had asked me to review this but I dropped the ball over the holidays. If you'd like me to review it, please reopen.

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

PR Comment: https://git.openjdk.org/jdk/pull/28243#issuecomment-3849345890

From lancea at openjdk.org  Wed Feb  4 19:58:43 2026
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 4 Feb 2026 19:58:43 GMT
Subject: RFR: 8377116: Refactor java/util/zip TestNG tests to JUnit [v2]
In-Reply-To: <4tl2MyOvU9l-XjBRlt-SePmy-XmV6jhibBA91nW6PVc=.39fa9675-3c91-403f-8c03-981e61c489cf@github.com>
References: <QPduW9IIUl5rdWQ4uTQpnO_2yqX8E2sZO12uTEE2oaE=.40f85d49-bac5-4b73-88d2-4ff597a6ba46@github.com>
 <4tl2MyOvU9l-XjBRlt-SePmy-XmV6jhibBA91nW6PVc=.39fa9675-3c91-403f-8c03-981e61c489cf@github.com>
Message-ID: <4z2RxCBLaL5tJEMtiqhHSobtPfZVWmlLSCRMRhBU6jo=.f7b62f56-33b5-4cb7-b42a-41740a4bcdc7@github.com>

On Wed, 4 Feb 2026 18:58:44 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR consists of a conversion for the java/util/zip TestNG tests to JUnit. Changes are mainly automated. https://github.com/openjdk/jdk/commit/1aeb8a634b8f255853516015f4b39bd79dd94090 is required to resolve a failure since JUnit parameterized tests automatically close arguments that implement `AutoCloseable`.
>> 
>> Test stats before:
>> Framework-based tests: 274 = 107 TestNG + 167 JUnit
>> 
>> Test stats after:
>> Framework-based tests: 274 = 0 TestNG + 274 JUnit
>
> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fixing other 'DataProvider' occurrences in JUnit tests under java/util/zip
>  - Correct previous incorrect placement of actual/expected in assertions (Chen)
>  - Use static imports everywhere + fix 'DataProvider' in comments (Alan, Lance)

Thank you Justin.  The changes look good overall

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29552#pullrequestreview-3753063408

From almatvee at openjdk.org  Wed Feb  4 20:18:37 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 4 Feb 2026 20:18:37 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <2IrPPIp3XsPRZCmVCR7M8uLeu9kwWBknuDI45KV4-XU=.0819a030-4918-44fb-a8fd-dc25ce34ea38@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
 <NEeBqEpKFRvjQg8rs2ropHOlKqpW_U6UpWbexU3p4Qg=.bf7bf267-2c59-44a0-9987-97b3bbabae59@github.com>
 <YK-Ugiw4bfPm4RQlBzu47oxqvArpgn_9j_NZI-jIbzY=.23e52b9c-41cb-4f28-8791-9712dd6f2fb1@github.com>
 <2IrPPIp3XsPRZCmVCR7M8uLeu9kwWBknuDI45KV4-XU=.0819a030-4918-44fb-a8fd-dc25ce34ea38@github.com>
Message-ID: <FWm_RN0vyyejMSAJhKT1X4byORcBJtNmDM2jJVHKE4E=.d7fd0453-93ac-4c51-965b-a01f4f171188@github.com>

On Wed, 4 Feb 2026 03:35:55 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> For some reason `JAVA_VERSION` is set to quoted string and `getProperty()` will return `"27"` instead of `27`. I think `"` is not truly part of version string and `replaceAll()` removes it. I do not think that removing leading and trailing `"` should be platform specific.
>
> Please add a comment explaining this.
> We also need a test case where the property value is not enclosed in double quotes.
> 
> Makes me wonder: is java.util.Properties the correct choice for reading the "release" file?

I do not see why using `java.util.Properties` to read "release" file is bad idea. "release" file is key-value file. `java.util.Properties` does not remove leading and trailing quotes based on documentation. I updated unit test to cover quoted and unquoted values. Including empty value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2765815486

From almatvee at openjdk.org  Wed Feb  4 20:36:03 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 4 Feb 2026 20:36:03 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <fTPf5tbuIWqMtWUFDU60LDr6_P74FBqIrYPAoQi8hmg=.1b8cdca6-7ce6-4482-b23b-878bdc30cc36@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
 <NEeBqEpKFRvjQg8rs2ropHOlKqpW_U6UpWbexU3p4Qg=.bf7bf267-2c59-44a0-9987-97b3bbabae59@github.com>
 <rPwNzwDI8_kFTbpnicsh3XxoxzZ8TM-3ri0Rc8HikNg=.c4e94445-08a8-40dc-ae51-66970b9daf61@github.com>
 <fTPf5tbuIWqMtWUFDU60LDr6_P74FBqIrYPAoQi8hmg=.1b8cdca6-7ce6-4482-b23b-878bdc30cc36@github.com>
Message-ID: <KR6T2tjlWT8M5-gs5C7VgQH5vTQdgyznwd2WJO8V4yY=.7eeab39d-43d6-4d14-a88b-fe80c863427b@github.com>

On Wed, 4 Feb 2026 03:48:23 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> This function is being called 3 times already. I think having platform specific code in it is better, then duplicating:
>> 
>> RuntimeImageUtils.getReleaseFilePath(MacBundle.fromPath(cookedRuntime).map(MacBundle::homeDir).orElse(cookedRuntime));
>> 
>> I do like idea of using `MacBundle.fromPath()`.
>
> The code that finds the JDK image directory in a random path is a separate function.
> The function that returns a path to the "release" file in the JDK image should take a path to the JDK image directory.
> 
> If we need a convenience function that does both things, we should implement it on top of these two functions.

I will just use two function.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2765868489

From asemenyuk at openjdk.org  Wed Feb  4 20:49:45 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 4 Feb 2026 20:49:45 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <FWm_RN0vyyejMSAJhKT1X4byORcBJtNmDM2jJVHKE4E=.d7fd0453-93ac-4c51-965b-a01f4f171188@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
 <NEeBqEpKFRvjQg8rs2ropHOlKqpW_U6UpWbexU3p4Qg=.bf7bf267-2c59-44a0-9987-97b3bbabae59@github.com>
 <YK-Ugiw4bfPm4RQlBzu47oxqvArpgn_9j_NZI-jIbzY=.23e52b9c-41cb-4f28-8791-9712dd6f2fb1@github.com>
 <2IrPPIp3XsPRZCmVCR7M8uLeu9kwWBknuDI45KV4-XU=.0819a030-4918-44fb-a8fd-dc25ce34ea38@github.com>
 <FWm_RN0vyyejMSAJhKT1X4byORcBJtNmDM2jJVHKE4E=.d7fd0453-93ac-4c51-965b-a01f4f171188@github.com>
Message-ID: <-VFm35WewL1id7H0UURydqFBKQ1bTinsTjDKwYVDgK8=.f5a7a77e-24b3-4852-a5fc-39cdbc108806@github.com>

On Wed, 4 Feb 2026 20:15:53 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Please add a comment explaining this.
>> We also need a test case where the property value is not enclosed in double quotes.
>> 
>> Makes me wonder: is java.util.Properties the correct choice for reading the "release" file?
>
> I do not see why using `java.util.Properties` to read "release" file is bad idea. "release" file is key-value file. `java.util.Properties` does not remove leading and trailing quotes based on documentation. I updated unit test to cover quoted and unquoted values. Including empty value.

I didn't say it is a bad idea; I questioned the choice of the tool for reading the "release" file. Maybe there is a class specifically targeted for reading this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2765915035

From duke at openjdk.org  Wed Feb  4 21:05:45 2026
From: duke at openjdk.org (jengebr)
Date: Wed, 4 Feb 2026 21:05:45 GMT
Subject: RFR: 8371656: HashMap.putAll() optimizations [v3]
In-Reply-To: <vS9t9OeNOR04IZ6kfefrchkEHDI8GPmcqh0xwou2COU=.36eee3e2-521a-46ff-a209-3d9f5f6c1845@github.com>
References: <L9LdywP8aeyIW9SVHLEsRSUmuaa2vWWQyMW9pTrLtHA=.363bd16c-febb-4028-96b9-a01cdd0d86a2@github.com>
 <ueLHOkfYfe15Ur0RmZDF7j93vGs1x0w48Zib1mZ4rF0=.bba5969c-4504-4921-a6e7-0a1a39395f9b@github.com>
 <qhzibjtuAR2eqo3zVKsUuq1hVOE8pDmvGidnvyIRKhs=.8e143c26-cf0f-48c3-ac93-0ebde5c475e5@github.com>
 <vS9t9OeNOR04IZ6kfefrchkEHDI8GPmcqh0xwou2COU=.36eee3e2-521a-46ff-a209-3d9f5f6c1845@github.com>
Message-ID: <hCnu4iBX3D78JvbguP7DRjJzcIVLMb3ejXi9JqVEqmA=.35196844-258e-4024-ace3-14d025c700ef@github.com>

On Wed, 4 Feb 2026 19:31:10 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> @stuart-marks would you mind reviewing this one?  It's conceptually similar to the ArrayList modifications, but applied to different classes and most details differ.  I incorporated lessons about MOAT so that part should be cleaner.
>
> @jengebr Oops! Sorry, you had asked me to review this but I dropped the ball over the holidays. If you'd like me to review it, please reopen.

@stuart-marks  thanks for the followup!  I hope 2026 has been good so far!

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

PR Comment: https://git.openjdk.org/jdk/pull/28243#issuecomment-3849726314

From forax at openjdk.org  Wed Feb  4 21:12:28 2026
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 4 Feb 2026 21:12:28 GMT
Subject: RFR: 8371656: HashMap.putAll() optimizations [v3]
In-Reply-To: <ueLHOkfYfe15Ur0RmZDF7j93vGs1x0w48Zib1mZ4rF0=.bba5969c-4504-4921-a6e7-0a1a39395f9b@github.com>
References: <L9LdywP8aeyIW9SVHLEsRSUmuaa2vWWQyMW9pTrLtHA=.363bd16c-febb-4028-96b9-a01cdd0d86a2@github.com>
 <ueLHOkfYfe15Ur0RmZDF7j93vGs1x0w48Zib1mZ4rF0=.bba5969c-4504-4921-a6e7-0a1a39395f9b@github.com>
Message-ID: <g3TjdIsFb1rPWELfUbyonfFEoNC5RRhfWFVL2TcQRk8=.de57ae82-8e40-4925-bf9b-c75aa901d722@github.com>

On Thu, 4 Dec 2025 14:59:33 GMT, jengebr <duke at openjdk.org> wrote:

>> # HashMap.putAll() optimizations: Eliminating Megamorphic Call Site Bottlenecks
>> 
>> ## Summary
>> 
>> This PR addresses performance bottlenecks in `HashMap.putMapEntries()` by implementing direct optimizations for specific input types: `j.u.HashMap` and `j.u.Collections$UnmodifiableMap`. The optimizations target `HashMap(Map)` constructor and `putAll()` operations based on the real-world megamorphic behavior identified in [JDK-8368292](https://bugs.openjdk.org/browse/JDK-8368292), delivering significant performance improvements when multiple `Map` subtypes are used.
>> 
>> ## Problem Context
>> 
>> ### Megamorphic Call Site Overhead in Map Iteration
>> `HashMap.putMapEntries()` currently uses a generic approach that suffers from megamorphic call site overhead when applications perform bulk creation or population of HashMaps from various source map types:
>> 
>> 1. `m.entrySet()` becomes megamorphic across different map implementations
>> 2. `entrySet().iterator()` creates different iterator types
>> 3. `entry.getKey()` and `entry.getValue()` calls vary by map type
>> 4. Individual `putVal()` calls for each entry
>> 
>> When the source is `Collections$UnmodifiableMap`, the problem is compounded by megamorphic wrappers around the already-megamorphic iteration methods. In cases where the unwrapped map is also a HashMap, both the wrapper overhead and the iteration overhead can be eliminated with a single optimization.
>> 
>> ## Optimized Methods
>> 
>> ### HashMap
>> - **`putMapEntries(Map<? extends K, ? extends V> m, boolean evict)`**: Added fast paths for UnmodifiableMap unwrapping and HashMap-to-HashMap copying
>> - **`putMapEntries(HashMap<? extends K, ? extends V> src, boolean evict)`**: copies HashMap-to-HashMap via direct Node processing.  Avoids polymorphic issues and eliminates redundant calls to HashMap.hash().
>> 
>> ## Implementation Details
>> 
>> ### HashMap-to-HashMap Fast Path
>> Eliminates megamorphic iteration by targeting internal Node structure - and also reuses the pre-calculated hash code, thus avoiding megamorphic calls to Object.hashCode() and the sometimes-expensive recalculation (depending on key type).  This also eliminates direct reads from the key, thus reducing the set of objects accessed.
>> 
>> ### UnmodifiableMap Unwrapping
>> Detects UnmodifiableMap instances and accesses the underlying map directly via the `m` field, eliminating wrapper-induced megamorphic call sites. UnmodifiableMap visibility changed from `private` to package-private to enable this...
>
> jengebr has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into putMapEntriesOptimizations
>  - Unit test revisions
>  - Bug fix & unit test
>  - fixing whitespace
>  - Optimizing HashMap.putAll() and .<init> for HashMap and C$UM

src/java.base/share/classes/java/util/HashMap.java line 496:

> 494:     }
> 495: 
> 496:     @SuppressWarnings({"unchecked"})

please remove

src/java.base/share/classes/java/util/HashMap.java line 516:

> 514:      */
> 515:     final void putMapEntries(Map<? extends K, ? extends V> m, boolean evict) {
> 516:         if (m.getClass() == Collections.UnmodifiableMap.class) {

I would address that issue in a separate bug.

src/java.base/share/classes/java/util/HashMap.java line 538:

> 536: 
> 537:             if (m.getClass() == HashMap.class) {
> 538:                 @SuppressWarnings("unchecked")

remove the @SupressWarning and add the ? extends to the cast below, this is a safe cast

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28243#discussion_r2765980529
PR Review Comment: https://git.openjdk.org/jdk/pull/28243#discussion_r2765983153
PR Review Comment: https://git.openjdk.org/jdk/pull/28243#discussion_r2765987296

From forax at openjdk.org  Wed Feb  4 21:15:36 2026
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 4 Feb 2026 21:15:36 GMT
Subject: RFR: 8371656: HashMap.putAll() optimizations [v3]
In-Reply-To: <ueLHOkfYfe15Ur0RmZDF7j93vGs1x0w48Zib1mZ4rF0=.bba5969c-4504-4921-a6e7-0a1a39395f9b@github.com>
References: <L9LdywP8aeyIW9SVHLEsRSUmuaa2vWWQyMW9pTrLtHA=.363bd16c-febb-4028-96b9-a01cdd0d86a2@github.com>
 <ueLHOkfYfe15Ur0RmZDF7j93vGs1x0w48Zib1mZ4rF0=.bba5969c-4504-4921-a6e7-0a1a39395f9b@github.com>
Message-ID: <byqRINZX0yVBgMMkZ0BASwq5jq-Cja_JlzJhIlBaQc4=.84064dbe-0164-4044-b61d-b9f8ddbf6715@github.com>

On Thu, 4 Dec 2025 14:59:33 GMT, jengebr <duke at openjdk.org> wrote:

>> # HashMap.putAll() optimizations: Eliminating Megamorphic Call Site Bottlenecks
>> 
>> ## Summary
>> 
>> This PR addresses performance bottlenecks in `HashMap.putMapEntries()` by implementing direct optimizations for specific input types: `j.u.HashMap` and `j.u.Collections$UnmodifiableMap`. The optimizations target `HashMap(Map)` constructor and `putAll()` operations based on the real-world megamorphic behavior identified in [JDK-8368292](https://bugs.openjdk.org/browse/JDK-8368292), delivering significant performance improvements when multiple `Map` subtypes are used.
>> 
>> ## Problem Context
>> 
>> ### Megamorphic Call Site Overhead in Map Iteration
>> `HashMap.putMapEntries()` currently uses a generic approach that suffers from megamorphic call site overhead when applications perform bulk creation or population of HashMaps from various source map types:
>> 
>> 1. `m.entrySet()` becomes megamorphic across different map implementations
>> 2. `entrySet().iterator()` creates different iterator types
>> 3. `entry.getKey()` and `entry.getValue()` calls vary by map type
>> 4. Individual `putVal()` calls for each entry
>> 
>> When the source is `Collections$UnmodifiableMap`, the problem is compounded by megamorphic wrappers around the already-megamorphic iteration methods. In cases where the unwrapped map is also a HashMap, both the wrapper overhead and the iteration overhead can be eliminated with a single optimization.
>> 
>> ## Optimized Methods
>> 
>> ### HashMap
>> - **`putMapEntries(Map<? extends K, ? extends V> m, boolean evict)`**: Added fast paths for UnmodifiableMap unwrapping and HashMap-to-HashMap copying
>> - **`putMapEntries(HashMap<? extends K, ? extends V> src, boolean evict)`**: copies HashMap-to-HashMap via direct Node processing.  Avoids polymorphic issues and eliminates redundant calls to HashMap.hash().
>> 
>> ## Implementation Details
>> 
>> ### HashMap-to-HashMap Fast Path
>> Eliminates megamorphic iteration by targeting internal Node structure - and also reuses the pre-calculated hash code, thus avoiding megamorphic calls to Object.hashCode() and the sometimes-expensive recalculation (depending on key type).  This also eliminates direct reads from the key, thus reducing the set of objects accessed.
>> 
>> ### UnmodifiableMap Unwrapping
>> Detects UnmodifiableMap instances and accesses the underlying map directly via the `m` field, eliminating wrapper-induced megamorphic call sites. UnmodifiableMap visibility changed from `private` to package-private to enable this...
>
> jengebr has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into putMapEntriesOptimizations
>  - Unit test revisions
>  - Bug fix & unit test
>  - fixing whitespace
>  - Optimizing HashMap.putAll() and .<init> for HashMap and C$UM

src/java.base/share/classes/java/util/HashMap.java line 541:

> 539:                 HashMap<K, V> hashMap = (HashMap<K, V>) m;
> 540:                 putMapEntries(hashMap, evict);
> 541:             } else {

I would add a return here and avoid the "else" because this is an optimization, the nominal case (below) should be aligned on the left.

so instead of
if (...) { ... } else { ... }
use
if (...) { ... return; }
...

to emphasis that this is an optimization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28243#discussion_r2765998998

From asemenyuk at openjdk.org  Wed Feb  4 21:16:36 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 4 Feb 2026 21:16:36 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v6]
In-Reply-To: <-VFm35WewL1id7H0UURydqFBKQ1bTinsTjDKwYVDgK8=.f5a7a77e-24b3-4852-a5fc-39cdbc108806@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <yW0lJDT7Pj68yulS8GIoOvsqlxSRetPKWXXIknqg530=.d1930d85-2920-466c-ada7-575b0d395227@github.com>
 <NEeBqEpKFRvjQg8rs2ropHOlKqpW_U6UpWbexU3p4Qg=.bf7bf267-2c59-44a0-9987-97b3bbabae59@github.com>
 <YK-Ugiw4bfPm4RQlBzu47oxqvArpgn_9j_NZI-jIbzY=.23e52b9c-41cb-4f28-8791-9712dd6f2fb1@github.com>
 <2IrPPIp3XsPRZCmVCR7M8uLeu9kwWBknuDI45KV4-XU=.0819a030-4918-44fb-a8fd-dc25ce34ea38@github.com>
 <FWm_RN0vyyejMSAJhKT1X4byORcBJtNmDM2jJVHKE4E=.d7fd0453-93ac-4c51-965b-a01f4f171188@github.com>
 <-VFm35WewL1id7H0UURydqFBKQ1bTinsTjDKwYVDgK8=.f5a7a77e-24b3-4852-a5fc-39cdbc108806@github.com>
Message-ID: <xv6Vlqp45oLxPGMTHWpjURaW0HnCu6AmpbDtxbkWpmk=.81d2f649-6751-4c8d-850a-a22e5ad8bf22@github.com>

On Wed, 4 Feb 2026 20:47:14 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> I do not see why using `java.util.Properties` to read "release" file is bad idea. "release" file is key-value file. `java.util.Properties` does not remove leading and trailing quotes based on documentation. I updated unit test to cover quoted and unquoted values. Including empty value.
>
> I didn't say it is a bad idea; I questioned the choice of the tool for reading the "release" file. What if there is a class specifically targeted for reading this file?
> 
> I found the code in jlink that reads/writes the "release" file:
> https://github.com/openjdk/jdk/blob/949370ab0e701cfcc68cb84dd0f91e5db41f4f45/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ReleaseInfoPlugin.java#L111
> 
> It uses `java.util.Properties` and encloses the JDK version in double quotes. So the implementation of the RuntimeVersionReader is correct. We just need it documented and reference the ReleaseInfoPlugin class.

I also suggest changing the return type of the `RuntimeVersionReader#readVersion()` from `String/Optional<String>` to `Runtime.Version/Optional<Runtime.Version>`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2766003020

From pchilanomate at openjdk.org  Wed Feb  4 23:20:17 2026
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Feb 2026 23:20:17 GMT
Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for
 all cases [v4]
In-Reply-To: <RlKpHz3GaSmQpSjV0X7J16qaHE4VEbiuqayztSMIpy4=.c823d3bd-5388-49de-b034-4800dec34049@github.com>
References: <sbp120wZjbJcEpyWDT9It7wFl_zU1kXNiHz7QMkd6RA=.46fa522d-104a-4c6f-a18f-cb0f8f37cad4@github.com>
 <RlKpHz3GaSmQpSjV0X7J16qaHE4VEbiuqayztSMIpy4=.c823d3bd-5388-49de-b034-4800dec34049@github.com>
Message-ID: <NcFgH6YSpAbfcy-2E3oERKOh-TOupf-0Do6ROHVQEY0=.aa09d50c-361f-49fc-8d43-6e23a359c1bd@github.com>

On Wed, 4 Feb 2026 08:40:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace.
>> 
>> A summary of the changes:
>> 
>> - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state
>> - Thread::getStackTrace is changed to use async_get_stack_trace for all cases
>> - The SUSPENDED substate in VirtualThread is removed
>> - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in
>> - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace
>> 
>> The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait.
>> 
>> A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required.
>> 
>> Testing: tier1-5.  The changes has been already been tested in the loom repo for a few months.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8376568
>  - Merge branch 'master' into JDK-8376568
>  - Review feedback
>  - Improve asserts
>  - Cleanup
>  - Merge branch 'master' into Thread.getStackTrace
>  - Initial commit

src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 63:

> 61:      */
> 62:     static ThreadSnapshot of(Thread thread) {
> 63:         ThreadSnapshot snapshot = thread.isAlive() ? create(thread) : null;

Looking at the implementation of `Thread.isAlive` for platform threads I'm confused now. It checks `eetop != 0`, but we set it [here](https://github.com/openjdk/jdk/blob/949370ab0e701cfcc68cb84dd0f91e5db41f4f45/src/hotspot/share/runtime/javaThread.cpp#L1732), before we change the state to RUNNABLE [here](https://github.com/openjdk/jdk/blob/949370ab0e701cfcc68cb84dd0f91e5db41f4f45/src/hotspot/share/runtime/thread.cpp#L408). So I'm wondering if we could hit the assert added in the last update in `ThreadSnapshotFactory::get_thread_snapshot`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2766377403

From almatvee at openjdk.org  Thu Feb  5 01:13:53 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 5 Feb 2026 01:13:53 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v8]
In-Reply-To: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
Message-ID: <_iQR2R5zHnQZ0GzAr0X0w6ZOEeYollmvsIAB11fynvE=.f770c958-2f21-4300-a122-845acbfb7fe4@github.com>

> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
> - Added test to cover added functionality.
> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.

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

  8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v7]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29260/files
  - new: https://git.openjdk.org/jdk/pull/29260/files/113b367d..aaafb4c3

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

  Stats: 287 lines in 14 files changed: 130 ins; 40 del; 117 mod
  Patch: https://git.openjdk.org/jdk/pull/29260.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29260/head:pull/29260

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

From almatvee at openjdk.org  Thu Feb  5 01:17:03 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 5 Feb 2026 01:17:03 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v7]
In-Reply-To: <ty3RpRbisGr8rMQUCRTiT6OMPNOIfrV1td1s_OYw1aw=.572c9d7b-1b5e-4c49-8a17-da96c658b193@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <ty3RpRbisGr8rMQUCRTiT6OMPNOIfrV1td1s_OYw1aw=.572c9d7b-1b5e-4c49-8a17-da96c658b193@github.com>
Message-ID: <WQGP9PAt7s15S8kEShUu26LF-wsf243VJTi_phAakiY=.cafdf718-4630-43b1-9420-523074fc7b0f@github.com>

On Tue, 3 Feb 2026 02:52:33 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
>> - Added test to cover added functionality.
>> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.
>
> Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8357404
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]
>  - merge with upstream
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v5]
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v4]
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v3]
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2]
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified

8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v7]
- Fixed all review comments.
- Version normalization will be done in all cases if version is not provided via command line.
- Version normalization will be done only if it is not valid platform version. Before we always normalized to 3 components on macOS and 4 on Windows. For example valid macOS version 1.0 will be normalized to 1.0.0. Now 1.0 will not be normalized on macOS.
- Fixed `ModulePathTest3` to use "valid" runtime bundle, since `MacBundle` is used on bundles from now on and perform better check, then just "Contents/Home".

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

PR Comment: https://git.openjdk.org/jdk/pull/29260#issuecomment-3850543346

From xgong at openjdk.org  Thu Feb  5 01:18:58 2026
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 5 Feb 2026 01:18:58 GMT
Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for
 unsigned min/max reduction operations [v5]
In-Reply-To: <SbpbEN5HJpm8AaXs-K3czwJPgxj59bb_vwNKhZM9q4o=.abd23cad-9248-471c-9aa8-3d88f21abe20@github.com>
References: <Q2wrStWVzJWL-6b6lxC3eCQv465aVRUdX5Kr95rT5bE=.38082a7b-70c9-4731-8d80-a8927b87f435@github.com>
 <SbpbEN5HJpm8AaXs-K3czwJPgxj59bb_vwNKhZM9q4o=.abd23cad-9248-471c-9aa8-3d88f21abe20@github.com>
Message-ID: <Srk2Rp2rHeETnFRX69cw60axF8NFfL8-wt2ULq2BwSI=.5bc0106c-0c43-4e69-907c-38b82bd89a83@github.com>

On Wed, 4 Feb 2026 02:38:18 GMT, Eric Fang <erfang at openjdk.org> wrote:

>> This patch adds intrinsic support for UMIN and UMAX reduction operations in the Vector API on AArch64, enabling direct hardware instruction mapping for better performance.
>> 
>> Changes:
>> --------
>> 
>> 1. C2 mid-end:
>>    - Added UMinReductionVNode and UMaxReductionVNode
>> 
>> 2. AArch64 Backend:
>>    - Added uminp/umaxp/sve_uminv/sve_umaxv instructions
>>    - Updated match rules for all vector sizes and element types
>>    - Both NEON and SVE implementation are supported
>> 
>> 3. Test:
>>    - Added UMIN_REDUCTION_V and UMAX_REDUCTION_V to IRNode.java
>>    - Added assembly tests in aarch64-asmtest.py for new instructions
>>    - Added a JTReg test file VectorUMinMaxReductionTest.java
>> 
>> Different configurations were tested on aarch64 and x86 machines, and all tests passed.
>> 
>> Test results of JMH benchmarks from the panama-vector project:
>> --------
>> 
>> On a Nvidia Grace machine with 128-bit SVE:
>> 
>> Benchmark                       Unit    Before  Error   After           Error   Uplift
>> Byte128Vector.UMAXLanes         ops/ms  411.60  42.18   25226.51        33.92   61.29
>> Byte128Vector.UMAXMaskedLanes   ops/ms  558.56  85.12   25182.90        28.74   45.09
>> Byte128Vector.UMINLanes         ops/ms  645.58  780.76  28396.29        103.11  43.99
>> Byte128Vector.UMINMaskedLanes   ops/ms  621.09  718.27  26122.62        42.68   42.06
>> Byte64Vector.UMAXLanes          ops/ms  296.33  34.44   14357.74        15.95   48.45
>> Byte64Vector.UMAXMaskedLanes    ops/ms  376.54  44.01   14269.24        21.41   37.90
>> Byte64Vector.UMINLanes          ops/ms  373.45  426.51  15425.36        66.20   41.31
>> Byte64Vector.UMINMaskedLanes    ops/ms  353.32  346.87  14201.37        13.79   40.19
>> Int128Vector.UMAXLanes          ops/ms  174.79  192.51  9906.07         286.93  56.67
>> Int128Vector.UMAXMaskedLanes    ops/ms  157.23  206.68  10246.77        11.44   65.17
>> Int64Vector.UMAXLanes           ops/ms  95.30   126.49  4719.30         98.57   49.52
>> Int64Vector.UMAXMaskedLanes     ops/ms  88.19   87.44   4693.18         19.76   53.22
>> Long128Vector.UMAXLanes         ops/ms  80.62   97.82   5064.01         35.52   62.82
>> Long128Vector.UMAXMaskedLanes   ops/ms  78.15   102.91  5028.24         8.74    64.34
>> Long64Vector.UMAXLanes          ops/ms  47.56   62.01   46.76           52.28   0.98
>> Long64Vector.UMAXMaskedLanes    ops/ms  45.44   46.76   45.79           42.91   1.01
>> Short128Vector.UMAXLanes        ops/ms  316.65  410.30  14814.82        23.65   46.79
>> ...
>
> Eric Fang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add JMH benchmark VectorUMinUMaxReductionBenchmark.java
>   
>   Also refined the helper functions.

LGTM! Thanks for your work!

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

Marked as reviewed by xgong (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28693#pullrequestreview-3754056702

From pchilanomate at openjdk.org  Thu Feb  5 02:32:40 2026
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 5 Feb 2026 02:32:40 GMT
Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for
 all cases [v4]
In-Reply-To: <NcFgH6YSpAbfcy-2E3oERKOh-TOupf-0Do6ROHVQEY0=.aa09d50c-361f-49fc-8d43-6e23a359c1bd@github.com>
References: <sbp120wZjbJcEpyWDT9It7wFl_zU1kXNiHz7QMkd6RA=.46fa522d-104a-4c6f-a18f-cb0f8f37cad4@github.com>
 <RlKpHz3GaSmQpSjV0X7J16qaHE4VEbiuqayztSMIpy4=.c823d3bd-5388-49de-b034-4800dec34049@github.com>
 <NcFgH6YSpAbfcy-2E3oERKOh-TOupf-0Do6ROHVQEY0=.aa09d50c-361f-49fc-8d43-6e23a359c1bd@github.com>
Message-ID: <quHtOIN5Ry6kyQmXUJ1Nnkji-nKDHpp0yVwZM-77QF8=.16f692ed-94ed-4156-a2bf-ef5bbda3895e@github.com>

On Wed, 4 Feb 2026 23:17:46 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8376568
>>  - Merge branch 'master' into JDK-8376568
>>  - Review feedback
>>  - Improve asserts
>>  - Cleanup
>>  - Merge branch 'master' into Thread.getStackTrace
>>  - Initial commit
>
> src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 63:
> 
>> 61:      */
>> 62:     static ThreadSnapshot of(Thread thread) {
>> 63:         ThreadSnapshot snapshot = thread.isAlive() ? create(thread) : null;
> 
> Looking at the implementation of `Thread.isAlive` for platform threads I'm confused now. It checks `eetop != 0`, but we set it [here](https://github.com/openjdk/jdk/blob/949370ab0e701cfcc68cb84dd0f91e5db41f4f45/src/hotspot/share/runtime/javaThread.cpp#L1732), before we change the state to RUNNABLE [here](https://github.com/openjdk/jdk/blob/949370ab0e701cfcc68cb84dd0f91e5db41f4f45/src/hotspot/share/runtime/thread.cpp#L408). So I'm wondering if we could hit the assert added in the last update in `ThreadSnapshotFactory::get_thread_snapshot`.

Never mind, the `GetThreadSnapshotHandshakeClosure` handshake will not procede until the thread is started and becomes safepoint safe, which happens after the state is set to RUNNABLE. The attached case is also fine for the same reason.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2766777490

From almatvee at openjdk.org  Thu Feb  5 02:52:59 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 5 Feb 2026 02:52:59 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v9]
In-Reply-To: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
Message-ID: <C-8YiKlI0uge38gLDeQRdo7lsr2HBF7PcP0sIkLXLog=.1f55a466-228b-46cc-b444-0bfb21653f9e@github.com>

> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
> - Added test to cover added functionality.
> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.

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

  8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v8]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29260/files
  - new: https://git.openjdk.org/jdk/pull/29260/files/aaafb4c3..17707867

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

  Stats: 10 lines in 2 files changed: 8 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29260.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29260/head:pull/29260

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

From almatvee at openjdk.org  Thu Feb  5 02:55:27 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 5 Feb 2026 02:55:27 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v8]
In-Reply-To: <_iQR2R5zHnQZ0GzAr0X0w6ZOEeYollmvsIAB11fynvE=.f770c958-2f21-4300-a122-845acbfb7fe4@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <_iQR2R5zHnQZ0GzAr0X0w6ZOEeYollmvsIAB11fynvE=.f770c958-2f21-4300-a122-845acbfb7fe4@github.com>
Message-ID: <5pnMSMI8o5v_k4dESA_vXHae2xs9nM-CM-bFWOGNfyg=.9472d162-8010-4245-af16-6c4826c65c49@github.com>

On Thu, 5 Feb 2026 01:13:53 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
>> - Added test to cover added functionality.
>> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v7]

8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v8]
- Removed Linux "17.21.3+foo" case, since it will not be read by `RuntimeVersionReader`.
- Fixed `NoMPathRuntimeTest` for same reason as `ModulePathTest3`.

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

PR Comment: https://git.openjdk.org/jdk/pull/29260#issuecomment-3850783132

From jbhateja at openjdk.org  Thu Feb  5 04:33:29 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 5 Feb 2026 04:33:29 GMT
Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass
 them to intrinsic entries [v8]
In-Reply-To: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
References: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
Message-ID: <kXCEBHjl-u9q6izibtgQl_PFXQVETxKU_plfo3EXozQ=.9b38c603-7053-4934-98de-80c7b99851fd@github.com>

> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support.
> 
> Patch add new lane type constants and pass them to vector intrinsic entry points.
> 
> All existing Vector API jtreg test are passing with the patch.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

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

  Review comment resolution

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29481/files
  - new: https://git.openjdk.org/jdk/pull/29481/files/c1935efc..4f7d671e

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

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

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

From jbhateja at openjdk.org  Thu Feb  5 04:33:33 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 5 Feb 2026 04:33:33 GMT
Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass
 them to intrinsic entries [v7]
In-Reply-To: <tcISFbisSIq_FajuTtz6BFDYcg6O03FZzIIW_jpCnaE=.a4860776-b84d-45c1-9cd2-79bc28bf4cf8@github.com>
References: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
 <kDaABPfdYICCDElAjcNrY1MR61aIQO58SdxFCgZfVRY=.de99cd78-43ef-4664-bd6c-641ed75d3173@github.com>
 <tcISFbisSIq_FajuTtz6BFDYcg6O03FZzIIW_jpCnaE=.a4860776-b84d-45c1-9cd2-79bc28bf4cf8@github.com>
Message-ID: <Vc0z8xp-bUxwDVEflCnCd98tQNHHCcWxDrajLldWQjQ=.988a77cf-ffbb-4907-9155-ce351a70e572@github.com>

On Wed, 4 Feb 2026 18:13:08 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolution
>
> src/hotspot/share/prims/vectorSupport.hpp line 141:
> 
>> 139: 
>> 140:   // Values in this enum correspond to the jdk.incubator.vector.LaneType ordinal values.
>> 141:   enum LaneType {
> 
> Please specify the underlying type of this enum: `enum LaneType : int`. Otherwise, this will not work:
> 
>     VectorSupport::LaneType vltype = static_cast<VectorSupport::LaneType>(laneType->get_con());
> 
> It is because casting an integer to an unscoped enum is UB if `laneType->get_con()` does not fit into the range of the enum values.

Thanks @merykitty , addressed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2767032912

From qamai at openjdk.org  Thu Feb  5 05:09:29 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 5 Feb 2026 05:09:29 GMT
Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass
 them to intrinsic entries [v8]
In-Reply-To: <kXCEBHjl-u9q6izibtgQl_PFXQVETxKU_plfo3EXozQ=.9b38c603-7053-4934-98de-80c7b99851fd@github.com>
References: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
 <kXCEBHjl-u9q6izibtgQl_PFXQVETxKU_plfo3EXozQ=.9b38c603-7053-4934-98de-80c7b99851fd@github.com>
Message-ID: <lkU9FIi6-6FgBg8qEYcx9int_nKhiOMMdawGGosc4Bw=.f7e7f6bf-1652-42bf-a370-d7db63eccce6@github.com>

On Thu, 5 Feb 2026 04:33:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support.
>> 
>> Patch add new lane type constants and pass them to vector intrinsic entry points.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment resolution

Thanks, hotspot changes look good to me

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

Marked as reviewed by qamai (Committer).

PR Review: https://git.openjdk.org/jdk/pull/29481#pullrequestreview-3754621036

From erfang at openjdk.org  Thu Feb  5 05:27:47 2026
From: erfang at openjdk.org (Eric Fang)
Date: Thu, 5 Feb 2026 05:27:47 GMT
Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for
 unsigned min/max reduction operations [v5]
In-Reply-To: <SbpbEN5HJpm8AaXs-K3czwJPgxj59bb_vwNKhZM9q4o=.abd23cad-9248-471c-9aa8-3d88f21abe20@github.com>
References: <Q2wrStWVzJWL-6b6lxC3eCQv465aVRUdX5Kr95rT5bE=.38082a7b-70c9-4731-8d80-a8927b87f435@github.com>
 <SbpbEN5HJpm8AaXs-K3czwJPgxj59bb_vwNKhZM9q4o=.abd23cad-9248-471c-9aa8-3d88f21abe20@github.com>
Message-ID: <_Wk5gkvleJTOKYsI23tA4zACZTGIZ6YQwlvBSszeZnw=.1e8d47c4-bed9-448d-8164-2f91f890cd47@github.com>

On Wed, 4 Feb 2026 02:38:18 GMT, Eric Fang <erfang at openjdk.org> wrote:

>> This patch adds intrinsic support for UMIN and UMAX reduction operations in the Vector API on AArch64, enabling direct hardware instruction mapping for better performance.
>> 
>> Changes:
>> --------
>> 
>> 1. C2 mid-end:
>>    - Added UMinReductionVNode and UMaxReductionVNode
>> 
>> 2. AArch64 Backend:
>>    - Added uminp/umaxp/sve_uminv/sve_umaxv instructions
>>    - Updated match rules for all vector sizes and element types
>>    - Both NEON and SVE implementation are supported
>> 
>> 3. Test:
>>    - Added UMIN_REDUCTION_V and UMAX_REDUCTION_V to IRNode.java
>>    - Added assembly tests in aarch64-asmtest.py for new instructions
>>    - Added a JTReg test file VectorUMinMaxReductionTest.java
>> 
>> Different configurations were tested on aarch64 and x86 machines, and all tests passed.
>> 
>> Test results of JMH benchmarks from the panama-vector project:
>> --------
>> 
>> On a Nvidia Grace machine with 128-bit SVE:
>> 
>> Benchmark                       Unit    Before  Error   After           Error   Uplift
>> Byte128Vector.UMAXLanes         ops/ms  411.60  42.18   25226.51        33.92   61.29
>> Byte128Vector.UMAXMaskedLanes   ops/ms  558.56  85.12   25182.90        28.74   45.09
>> Byte128Vector.UMINLanes         ops/ms  645.58  780.76  28396.29        103.11  43.99
>> Byte128Vector.UMINMaskedLanes   ops/ms  621.09  718.27  26122.62        42.68   42.06
>> Byte64Vector.UMAXLanes          ops/ms  296.33  34.44   14357.74        15.95   48.45
>> Byte64Vector.UMAXMaskedLanes    ops/ms  376.54  44.01   14269.24        21.41   37.90
>> Byte64Vector.UMINLanes          ops/ms  373.45  426.51  15425.36        66.20   41.31
>> Byte64Vector.UMINMaskedLanes    ops/ms  353.32  346.87  14201.37        13.79   40.19
>> Int128Vector.UMAXLanes          ops/ms  174.79  192.51  9906.07         286.93  56.67
>> Int128Vector.UMAXMaskedLanes    ops/ms  157.23  206.68  10246.77        11.44   65.17
>> Int64Vector.UMAXLanes           ops/ms  95.30   126.49  4719.30         98.57   49.52
>> Int64Vector.UMAXMaskedLanes     ops/ms  88.19   87.44   4693.18         19.76   53.22
>> Long128Vector.UMAXLanes         ops/ms  80.62   97.82   5064.01         35.52   62.82
>> Long128Vector.UMAXMaskedLanes   ops/ms  78.15   102.91  5028.24         8.74    64.34
>> Long64Vector.UMAXLanes          ops/ms  47.56   62.01   46.76           52.28   0.98
>> Long64Vector.UMAXMaskedLanes    ops/ms  45.44   46.76   45.79           42.91   1.01
>> Short128Vector.UMAXLanes        ops/ms  316.65  410.30  14814.82        23.65   46.79
>> ...
>
> Eric Fang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add JMH benchmark VectorUMinUMaxReductionBenchmark.java
>   
>   Also refined the helper functions.

Thanks for your review !

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

PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3851155843

From duke at openjdk.org  Thu Feb  5 05:27:48 2026
From: duke at openjdk.org (duke)
Date: Thu, 5 Feb 2026 05:27:48 GMT
Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for
 unsigned min/max reduction operations [v5]
In-Reply-To: <SbpbEN5HJpm8AaXs-K3czwJPgxj59bb_vwNKhZM9q4o=.abd23cad-9248-471c-9aa8-3d88f21abe20@github.com>
References: <Q2wrStWVzJWL-6b6lxC3eCQv465aVRUdX5Kr95rT5bE=.38082a7b-70c9-4731-8d80-a8927b87f435@github.com>
 <SbpbEN5HJpm8AaXs-K3czwJPgxj59bb_vwNKhZM9q4o=.abd23cad-9248-471c-9aa8-3d88f21abe20@github.com>
Message-ID: <6YA1FhrdQbFS-BT-gtldsi79-j2xvjq-PBJmqMELoAM=.9e106a03-8d91-400c-bb3e-1dfc9fe63a8a@github.com>

On Wed, 4 Feb 2026 02:38:18 GMT, Eric Fang <erfang at openjdk.org> wrote:

>> This patch adds intrinsic support for UMIN and UMAX reduction operations in the Vector API on AArch64, enabling direct hardware instruction mapping for better performance.
>> 
>> Changes:
>> --------
>> 
>> 1. C2 mid-end:
>>    - Added UMinReductionVNode and UMaxReductionVNode
>> 
>> 2. AArch64 Backend:
>>    - Added uminp/umaxp/sve_uminv/sve_umaxv instructions
>>    - Updated match rules for all vector sizes and element types
>>    - Both NEON and SVE implementation are supported
>> 
>> 3. Test:
>>    - Added UMIN_REDUCTION_V and UMAX_REDUCTION_V to IRNode.java
>>    - Added assembly tests in aarch64-asmtest.py for new instructions
>>    - Added a JTReg test file VectorUMinMaxReductionTest.java
>> 
>> Different configurations were tested on aarch64 and x86 machines, and all tests passed.
>> 
>> Test results of JMH benchmarks from the panama-vector project:
>> --------
>> 
>> On a Nvidia Grace machine with 128-bit SVE:
>> 
>> Benchmark                       Unit    Before  Error   After           Error   Uplift
>> Byte128Vector.UMAXLanes         ops/ms  411.60  42.18   25226.51        33.92   61.29
>> Byte128Vector.UMAXMaskedLanes   ops/ms  558.56  85.12   25182.90        28.74   45.09
>> Byte128Vector.UMINLanes         ops/ms  645.58  780.76  28396.29        103.11  43.99
>> Byte128Vector.UMINMaskedLanes   ops/ms  621.09  718.27  26122.62        42.68   42.06
>> Byte64Vector.UMAXLanes          ops/ms  296.33  34.44   14357.74        15.95   48.45
>> Byte64Vector.UMAXMaskedLanes    ops/ms  376.54  44.01   14269.24        21.41   37.90
>> Byte64Vector.UMINLanes          ops/ms  373.45  426.51  15425.36        66.20   41.31
>> Byte64Vector.UMINMaskedLanes    ops/ms  353.32  346.87  14201.37        13.79   40.19
>> Int128Vector.UMAXLanes          ops/ms  174.79  192.51  9906.07         286.93  56.67
>> Int128Vector.UMAXMaskedLanes    ops/ms  157.23  206.68  10246.77        11.44   65.17
>> Int64Vector.UMAXLanes           ops/ms  95.30   126.49  4719.30         98.57   49.52
>> Int64Vector.UMAXMaskedLanes     ops/ms  88.19   87.44   4693.18         19.76   53.22
>> Long128Vector.UMAXLanes         ops/ms  80.62   97.82   5064.01         35.52   62.82
>> Long128Vector.UMAXMaskedLanes   ops/ms  78.15   102.91  5028.24         8.74    64.34
>> Long64Vector.UMAXLanes          ops/ms  47.56   62.01   46.76           52.28   0.98
>> Long64Vector.UMAXMaskedLanes    ops/ms  45.44   46.76   45.79           42.91   1.01
>> Short128Vector.UMAXLanes        ops/ms  316.65  410.30  14814.82        23.65   46.79
>> ...
>
> Eric Fang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add JMH benchmark VectorUMinUMaxReductionBenchmark.java
>   
>   Also refined the helper functions.

@erifan 
Your change (at version 234b4d905605ca10ae5be04caa642b5c2e3a4730) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3851162154

From duke at openjdk.org  Thu Feb  5 05:51:47 2026
From: duke at openjdk.org (Harshit470250)
Date: Thu, 5 Feb 2026 05:51:47 GMT
Subject: RFR: 8377035: [s390x] Disable JSR166 test cases which uses virtual
 threads
Message-ID: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>

ReentrantReadWriteLock20Test.java is failing on s390 due to virtual threads which are not yet implemented on s390. 
SynchronousQueue20Test.java also uses virtual thread so I am also disabling it.

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

Commit messages:
 - remove whitespace
 - remove virtual thread testcases
 - remove JSR166TestCase.java from ProblemList
 - ProblemList JSR166TestCase.java

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

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

From chagedorn at openjdk.org  Thu Feb  5 06:37:32 2026
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 5 Feb 2026 06:37:32 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics [v12]
In-Reply-To: <2_bA8sRgRlbc279Aia0oD9gPBn8bcD5kLP3RnA4Xl4Q=.deaeaaf0-27a1-40f8-81f3-c8283c4d9529@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <2_bA8sRgRlbc279Aia0oD9gPBn8bcD5kLP3RnA4Xl4Q=.deaeaaf0-27a1-40f8-81f3-c8283c4d9529@github.com>
Message-ID: <iMZBuHGVwxAbYvDpdKJWyrOwpLc5tc0QrHhNDixaKlI=.c94eaa8e-8d9c-454b-9401-b0311e79b917@github.com>

On Mon, 2 Feb 2026 14:03:00 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> ## Issue
>> 
>> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
>> 
>> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
>> 
>> ## Causes
>> 
>> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
>> 
>> ## Fix
>> 
>> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
>> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
>> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
>> 
>> # Testing
>> 
>> * Tier 1-3+
>> * 2 JTReg tests added
>>   * `TestRangeCheck.java` as regression test for the reported issue
>>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion
>
> Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - JDK-8374582: remove empty line
>  - JDK-8374582: add constant dump

Thanks for the updates Damon, looks good to me, too!

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

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3754821230

From jbhateja at openjdk.org  Thu Feb  5 07:24:09 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 5 Feb 2026 07:24:09 GMT
Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass
 them to intrinsic entries [v8]
In-Reply-To: <lkU9FIi6-6FgBg8qEYcx9int_nKhiOMMdawGGosc4Bw=.f7e7f6bf-1652-42bf-a370-d7db63eccce6@github.com>
References: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
 <kXCEBHjl-u9q6izibtgQl_PFXQVETxKU_plfo3EXozQ=.9b38c603-7053-4934-98de-80c7b99851fd@github.com>
 <lkU9FIi6-6FgBg8qEYcx9int_nKhiOMMdawGGosc4Bw=.f7e7f6bf-1652-42bf-a370-d7db63eccce6@github.com>
Message-ID: <MOPVI3dScBKtM6iSENH31pYjVDDrgjWGAOTKNhPxJbk=.4683db6f-2c35-412a-a58a-94d801aab436@github.com>

On Thu, 5 Feb 2026 05:06:19 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment resolution
>
> Thanks, hotspot changes look good to me

Thanks @merykitty , Hi @PaulSandoz , please re-approve.

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

PR Comment: https://git.openjdk.org/jdk/pull/29481#issuecomment-3851499002

From erfang at openjdk.org  Thu Feb  5 08:05:38 2026
From: erfang at openjdk.org (Eric Fang)
Date: Thu, 5 Feb 2026 08:05:38 GMT
Subject: Integrated: 8372980: [VectorAPI] AArch64: Add intrinsic support for
 unsigned min/max reduction operations
In-Reply-To: <Q2wrStWVzJWL-6b6lxC3eCQv465aVRUdX5Kr95rT5bE=.38082a7b-70c9-4731-8d80-a8927b87f435@github.com>
References: <Q2wrStWVzJWL-6b6lxC3eCQv465aVRUdX5Kr95rT5bE=.38082a7b-70c9-4731-8d80-a8927b87f435@github.com>
Message-ID: <RVeR1dWw2S-2260ojrwlspucchacfwTq_aVFn_N-1ts=.5f5f71f2-02ae-4e47-b74f-410aff1ace8c@github.com>

On Mon, 8 Dec 2025 03:29:03 GMT, Eric Fang <erfang at openjdk.org> wrote:

> This patch adds intrinsic support for UMIN and UMAX reduction operations in the Vector API on AArch64, enabling direct hardware instruction mapping for better performance.
> 
> Changes:
> --------
> 
> 1. C2 mid-end:
>    - Added UMinReductionVNode and UMaxReductionVNode
> 
> 2. AArch64 Backend:
>    - Added uminp/umaxp/sve_uminv/sve_umaxv instructions
>    - Updated match rules for all vector sizes and element types
>    - Both NEON and SVE implementation are supported
> 
> 3. Test:
>    - Added UMIN_REDUCTION_V and UMAX_REDUCTION_V to IRNode.java
>    - Added assembly tests in aarch64-asmtest.py for new instructions
>    - Added a JTReg test file VectorUMinMaxReductionTest.java
> 
> Different configurations were tested on aarch64 and x86 machines, and all tests passed.
> 
> Test results of JMH benchmarks from the panama-vector project:
> --------
> 
> On a Nvidia Grace machine with 128-bit SVE:
> 
> Benchmark                       Unit    Before  Error   After           Error   Uplift
> Byte128Vector.UMAXLanes         ops/ms  411.60  42.18   25226.51        33.92   61.29
> Byte128Vector.UMAXMaskedLanes   ops/ms  558.56  85.12   25182.90        28.74   45.09
> Byte128Vector.UMINLanes         ops/ms  645.58  780.76  28396.29        103.11  43.99
> Byte128Vector.UMINMaskedLanes   ops/ms  621.09  718.27  26122.62        42.68   42.06
> Byte64Vector.UMAXLanes          ops/ms  296.33  34.44   14357.74        15.95   48.45
> Byte64Vector.UMAXMaskedLanes    ops/ms  376.54  44.01   14269.24        21.41   37.90
> Byte64Vector.UMINLanes          ops/ms  373.45  426.51  15425.36        66.20   41.31
> Byte64Vector.UMINMaskedLanes    ops/ms  353.32  346.87  14201.37        13.79   40.19
> Int128Vector.UMAXLanes          ops/ms  174.79  192.51  9906.07         286.93  56.67
> Int128Vector.UMAXMaskedLanes    ops/ms  157.23  206.68  10246.77        11.44   65.17
> Int64Vector.UMAXLanes           ops/ms  95.30   126.49  4719.30         98.57   49.52
> Int64Vector.UMAXMaskedLanes     ops/ms  88.19   87.44   4693.18         19.76   53.22
> Long128Vector.UMAXLanes         ops/ms  80.62   97.82   5064.01         35.52   62.82
> Long128Vector.UMAXMaskedLanes   ops/ms  78.15   102.91  5028.24         8.74    64.34
> Long64Vector.UMAXLanes          ops/ms  47.56   62.01   46.76           52.28   0.98
> Long64Vector.UMAXMaskedLanes    ops/ms  45.44   46.76   45.79           42.91   1.01
> Short128Vector.UMAXLanes        ops/ms  316.65  410.30  14814.82        23.65   46.79
> Short128Vector.UMAXMaskedLanes  ops/ms  308.90  351.78  15155.26        31.03   49.06
> Sh...

This pull request has now been integrated.

Changeset: d0e97307
Author:    Eric Fang <erfang at openjdk.org>
Committer: Xiaohong Gong <xgong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d0e97307836c49291f24ae7cb1c2e9319b986f8c
Stats:     1372 lines in 14 files changed: 954 ins; 14 del; 404 mod

8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations

Co-authored-by: Andrew Haley <aph at openjdk.org>
Reviewed-by: aph, xgong

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

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

From alanb at openjdk.org  Thu Feb  5 08:47:10 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Feb 2026 08:47:10 GMT
Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for
 all cases [v4]
In-Reply-To: <quHtOIN5Ry6kyQmXUJ1Nnkji-nKDHpp0yVwZM-77QF8=.16f692ed-94ed-4156-a2bf-ef5bbda3895e@github.com>
References: <sbp120wZjbJcEpyWDT9It7wFl_zU1kXNiHz7QMkd6RA=.46fa522d-104a-4c6f-a18f-cb0f8f37cad4@github.com>
 <RlKpHz3GaSmQpSjV0X7J16qaHE4VEbiuqayztSMIpy4=.c823d3bd-5388-49de-b034-4800dec34049@github.com>
 <NcFgH6YSpAbfcy-2E3oERKOh-TOupf-0Do6ROHVQEY0=.aa09d50c-361f-49fc-8d43-6e23a359c1bd@github.com>
 <quHtOIN5Ry6kyQmXUJ1Nnkji-nKDHpp0yVwZM-77QF8=.16f692ed-94ed-4156-a2bf-ef5bbda3895e@github.com>
Message-ID: <jfwjWBt9Gr6508HF01bJpyj4H8jj1HRZWb_ysmJTEJs=.f48da13a-52c8-49a3-af0d-0b7f6b70535d@github.com>

On Thu, 5 Feb 2026 02:29:53 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 63:
>> 
>>> 61:      */
>>> 62:     static ThreadSnapshot of(Thread thread) {
>>> 63:         ThreadSnapshot snapshot = thread.isAlive() ? create(thread) : null;
>> 
>> Looking at the implementation of `Thread.isAlive` for platform threads I'm confused now. It checks `eetop != 0`, but we set it [here](https://github.com/openjdk/jdk/blob/949370ab0e701cfcc68cb84dd0f91e5db41f4f45/src/hotspot/share/runtime/javaThread.cpp#L1732), before we change the state to RUNNABLE [here](https://github.com/openjdk/jdk/blob/949370ab0e701cfcc68cb84dd0f91e5db41f4f45/src/hotspot/share/runtime/thread.cpp#L408). So I'm wondering if we could hit the assert added in the last update in `ThreadSnapshotFactory::get_thread_snapshot`.
>
> Never mind, the `GetThreadSnapshotHandshakeClosure` handshake will not procede until the thread is started and becomes safepoint safe, which happens after the state is set to RUNNABLE. The attached case is also fine for a similar reason.

Thanks for the thorough analysis.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2767772222

From aartemov at openjdk.org  Thu Feb  5 08:51:10 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 5 Feb 2026 08:51:10 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v9]
In-Reply-To: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
Message-ID: <sBVlHSDyh6khWSX0nGj_OwhQqp2Ap3KF1shY4u2vuaI=.15594e70-4dac-4e15-a234-fb11fa441cb2@github.com>

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM asinh method.
> 
> Original C vs transliteration port:
> 
> 
> $ diff -w fdlib_asinh.c Asinh.translit.java
> 1c1,3
> < /* asinh(x)
> ---
>> /**
>> * Return the Inverse Hyperbolic Sine of x
>> *
> 2a5
>> *
> 10a14,17
>> private static final class Asinh {
>>       private static final double one = 1.0;
>>       private static final double ln2 = 6.93147180559945286227e-01;
>>       private static final double huge = 1.0e300;
> 12,29c19
> < #include "fdlibm.h"
> <
> < #ifdef __STDC__
> < static const double
> < #else
> < static double
> < #endif
> < one =  1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */
> < ln2 =  6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */
> < huge=  1.00000000000000000000e+300;
> <
> < #ifdef __STDC__
> <       double asinh(double x)
> < #else
> <       double asinh(x)
> <       double x;
> < #endif
> < {
> ---
>>       static double compute(double x) {
> 39c29
> <           w = __ieee754_log(fabs(x))+ln2;
> ---
>>                       w = log(Math.abs(x))+ln2;
> 41,42c31,32
> <           t = fabs(x);
> <           w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t));
> ---
>>                       t = Math.abs(x);
>>                       w = log(2.0*t+one/(sqrt(x*x+one)+t));
> 45c35
> <           w =log1p(fabs(x)+t/(one+sqrt(one+t)));
> ---
>>                       w =log1p(Math.abs(x)+t/(one+sqrt(one+t)));
> 47a38
>>       }
> 
> Transliteration port vs more idiomatic port:
> 
> 
> $ diff -w Asinh.translit.java Asinh.fdlibm.java
> 6,9c6,12
> < *  Based on
> < *    asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ]
> < *   we have
> < *   asinh(x) := x  if  1+x*x=1,
> ---
>>  *
>>  *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF
>>  *      and sinh(asinh(x)) = x, -INF < x  < INF.
>>  *      It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x  < INF.
>>  *      1. Replace x by |x| as the function is odd.
>>  *      2.
>>  *          asinh(x) := x, if 1+x^2 = 1,
> 12a16,22
>>  *
>>  *
>>  *
>>  * Special cases:
>>  *      only asinh(0)=0 is exact for finite x.
>>  *      asinh(NaN) is NaN
>>  *      asinh(INF) is INF
> 14,15c24
> < private static final class Asinh {
> <       private static final double one = 1.0;
> ---
>> static final class Asinh {
> 24c33,35
> <               if(ix>=0x7ff00000) return x+x;  /* x is inf or NaN */
> ---
>>               if(ix >= 0x7ff00000) {
>>                       return x + x;                       /* x is inf or NaN */
>>               }
> 26c37,39
> <                       if(huge+x>one) return x;    /* return x inexact except 0...

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

  8375285: Addressed reviewer's comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29273/files
  - new: https://git.openjdk.org/jdk/pull/29273/files/d8e231c7..7c48fec0

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

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

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

From aartemov at openjdk.org  Thu Feb  5 08:51:18 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 5 Feb 2026 08:51:18 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v8]
In-Reply-To: <HTq4KPrH8lZTVHT6_D3Gi1gMTzernd90gAPzZVEJT5c=.953c4ce3-6ee4-4d4c-9036-92763471579d@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <p57-Mga85sxN41Hdd9JTLGNVazIrkfDjNtCIhz70-ME=.86050f09-06e0-4c6e-80ac-39794153f806@github.com>
 <HTq4KPrH8lZTVHT6_D3Gi1gMTzernd90gAPzZVEJT5c=.953c4ce3-6ee4-4d4c-9036-92763471579d@github.com>
Message-ID: <Zgjlew-K02IYZ-EjoENRQzL8higlLSBGQ3Pr7VzA4CA=.2251ba23-b851-410e-900f-8a9f5a6bd1d7@github.com>

On Wed, 4 Feb 2026 13:22:16 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8375285: Addressed reviewer's comments.
>
> src/java.base/share/classes/java/lang/FdLibm.java line 3531:
> 
>> 3529:      *
>> 3530:      * Special cases:
>> 3531:      *      only asinh(&plusmn;0))=&plusmn;0) is exact for finite x.
> 
> There are two `)` too much.

Fixed.

> test/jdk/java/lang/Math/HyperbolicTests.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 4851625 4900189 4939441
> 
> Not sure if this requires the new bug ID.

I think since we have a issue per method, it is not worth having 3 extra bug ids here.

> test/jdk/java/lang/Math/HyperbolicTests.java line 1533:
> 
>> 1531: 
>> 1532: 
>> 1533:         for (int i = 0; i < testCases.length; i++) {
> 
> Why not enhanced `for`, like in the NaN loop below?

No particular reason, I looked at other tests, some use enhanced for loop, some do not. I changed to enhanced, it's a bit more easy to read.

> test/jdk/java/lang/Math/HyperbolicTests.java line 1712:
> 
>> 1710:     }
>> 1711: 
>> 1712:     public static int testAsinhCaseWithTolerance(double input,
> 
> This method is never invoked, IIUC.

Yes, I see the same for existing methods like `sinh`, `cosh`, `tanh`. Should such methods there be removed then?

> test/jdk/java/lang/StrictMath/ExhaustingTests.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 8301833 8302026 8301444 8302028 8302040 8302027 8304028
> 
> Bug ID? Not sure.

I don't think we need to add anything, see above.

> test/jdk/java/lang/StrictMath/HyperbolicTests.java line 29:
> 
>> 27: /*
>> 28:  * @test
>> 29:  * @bug 4851625 8301444
> 
> Not sure if this requires the new bug ID.

I don't think we need to add anything, see above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2767772829
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2767775949
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2767773917
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2767775285
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2767776514
PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2767776196

From dlong at openjdk.org  Thu Feb  5 08:59:31 2026
From: dlong at openjdk.org (Dean Long)
Date: Thu, 5 Feb 2026 08:59:31 GMT
Subject: RFR: 8350208: CTW: GraphKit::add_safepoint_edges asserts
 "not enough operands for reexecution"
Message-ID: <5h_buc-zClEr5vmVarvoUoafTnOHOAo3lTp7npWhkfc=.23a4eba9-8574-4b93-b858-7664f6c30a27@github.com>

This is an alternative solution to https://github.com/openjdk/jdk/pull/28597.  Thanks @merykitty for the test.

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

Commit messages:
 - update copyright year
 - alternative solution, call maybe_add_safepoint before push_ex_oop
 - Set jvms()->_reexecute to false during Parse::catch_inline_exceptions

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

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

From erfang at openjdk.org  Thu Feb  5 09:08:53 2026
From: erfang at openjdk.org (Eric Fang)
Date: Thu, 5 Feb 2026 09:08:53 GMT
Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in
 specific patterns [v10]
In-Reply-To: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
References: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
Message-ID: <_quPIapU_CUjz2J3W-s_3qOjV37ikujROE-CHeEcSZY=.ee511f07-d3dd-4b43-998f-1898167d9297@github.com>

> `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common.
> 
> If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example:
> 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)`
> 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`.
> 
> In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast.
> 
> The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`.
> 
> The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain.
> 
> Current optimizations related to `VectorMaskCastNode` include:
> 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760.
> 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242.
> 
> This PR does the following optimizations:
> 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct.
> 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vector, it remains unchanged as long as th...

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

  Refine the JTReg tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28313/files
  - new: https://git.openjdk.org/jdk/pull/28313/files/f53d330f..39992383

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

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

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

From erfang at openjdk.org  Thu Feb  5 09:08:55 2026
From: erfang at openjdk.org (Eric Fang)
Date: Thu, 5 Feb 2026 09:08:55 GMT
Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in
 specific patterns [v9]
In-Reply-To: <aGK8--tkPgEyCGoZqg_IPeWle3AAJJ2bmu5l-lKWjOo=.4ad97f35-ec82-48ed-894e-4a6b3b0e8de3@github.com>
References: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
 <aGK8--tkPgEyCGoZqg_IPeWle3AAJJ2bmu5l-lKWjOo=.4ad97f35-ec82-48ed-894e-4a6b3b0e8de3@github.com>
Message-ID: <Dz6V_1r8SemFDb0AN7UaD82gq1xYp5JxATqJgpTGL_g=.9a299a4f-1bc9-4663-acac-4b76f08fca0f@github.com>

On Wed, 28 Jan 2026 01:49:52 GMT, Eric Fang <erfang at openjdk.org> wrote:

>> `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common.
>> 
>> If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example:
>> 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)`
>> 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`.
>> 
>> In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast.
>> 
>> The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`.
>> 
>> The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain.
>> 
>> Current optimizations related to `VectorMaskCastNode` include:
>> 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760.
>> 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242.
>> 
>> This PR does the following optimizations:
>> 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct.
>> 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vect...
>
> Eric Fang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add clearer comments to VectorMaskCastIdentityTest.java

Hi @XiaohongGong thanks for your suggestions and I have addressed your comments, would you mind taking another look, thanks~

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

PR Comment: https://git.openjdk.org/jdk/pull/28313#issuecomment-3852083942

From xgong at openjdk.org  Thu Feb  5 09:59:50 2026
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 5 Feb 2026 09:59:50 GMT
Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in
 specific patterns [v10]
In-Reply-To: <_quPIapU_CUjz2J3W-s_3qOjV37ikujROE-CHeEcSZY=.ee511f07-d3dd-4b43-998f-1898167d9297@github.com>
References: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
 <_quPIapU_CUjz2J3W-s_3qOjV37ikujROE-CHeEcSZY=.ee511f07-d3dd-4b43-998f-1898167d9297@github.com>
Message-ID: <iSDSmMdNz8uAy8XTX1Lm98KCKL2Q3jJYP9Wx2L5rEUo=.85d5bd2e-894e-41a1-abdd-4ac4d14b2feb@github.com>

On Thu, 5 Feb 2026 09:08:53 GMT, Eric Fang <erfang at openjdk.org> wrote:

>> `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common.
>> 
>> If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example:
>> 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)`
>> 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`.
>> 
>> In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast.
>> 
>> The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`.
>> 
>> The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain.
>> 
>> Current optimizations related to `VectorMaskCastNode` include:
>> 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760.
>> 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242.
>> 
>> This PR does the following optimizations:
>> 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct.
>> 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vect...
>
> Eric Fang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine the JTReg tests

LGTM! Thanks for the update!

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

Marked as reviewed by xgong (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28313#pullrequestreview-3755758934

From alanb at openjdk.org  Thu Feb  5 10:03:37 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Feb 2026 10:03:37 GMT
Subject: RFR: 8377035: [s390x] Disable JSR166 test cases which uses virtual
 threads
In-Reply-To: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
References: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
Message-ID: <-qhqNtZUEWlKuAwHgQ62iE5un5x0r5O-0Rche1YLzKo=.9e5688cb-56d7-48b4-a8d7-6e1b22807f61@github.com>

On Wed, 4 Feb 2026 06:40:38 GMT, Harshit470250 <duke at openjdk.org> wrote:

>  failing on s390 due to virtual threads which are not yet implemented on s390.

In other tests we use `@requires vm.continuations` to ensure the test is only selected when the VM has the support. You are looking to skip a small subset of the j.u.concurrent tests so I see how you got here. It could use the WB API to filter on whether VMContinuations is true or false but that would be disruptive to the test in that it would need setup and run with -XX:+WhiteBoxAPI. As a short term "fix" then using !Platform.isS390x() should be okay (this is preferred to use the os.name property).

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

PR Comment: https://git.openjdk.org/jdk/pull/29555#issuecomment-3852446429

From sspitsyn at openjdk.org  Thu Feb  5 10:47:11 2026
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 5 Feb 2026 10:47:11 GMT
Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for
 all cases [v4]
In-Reply-To: <RlKpHz3GaSmQpSjV0X7J16qaHE4VEbiuqayztSMIpy4=.c823d3bd-5388-49de-b034-4800dec34049@github.com>
References: <sbp120wZjbJcEpyWDT9It7wFl_zU1kXNiHz7QMkd6RA=.46fa522d-104a-4c6f-a18f-cb0f8f37cad4@github.com>
 <RlKpHz3GaSmQpSjV0X7J16qaHE4VEbiuqayztSMIpy4=.c823d3bd-5388-49de-b034-4800dec34049@github.com>
Message-ID: <f-pCYqS3XjYMiPqZAfn7ozyF-6Q0H1szmeFnTPADH1g=.7d753037-1112-4397-9d32-5144d549fb75@github.com>

On Wed, 4 Feb 2026 08:40:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace.
>> 
>> A summary of the changes:
>> 
>> - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state
>> - Thread::getStackTrace is changed to use async_get_stack_trace for all cases
>> - The SUSPENDED substate in VirtualThread is removed
>> - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in
>> - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace
>> 
>> The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait.
>> 
>> A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required.
>> 
>> Testing: tier1-5.  The changes has been already been tested in the loom repo for a few months.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8376568
>  - Merge branch 'master' into JDK-8376568
>  - Review feedback
>  - Improve asserts
>  - Cleanup
>  - Merge branch 'master' into Thread.getStackTrace
>  - Initial commit

Most of new tests need a copyright year update.

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

PR Comment: https://git.openjdk.org/jdk/pull/29461#issuecomment-3852720530

From alanb at openjdk.org  Thu Feb  5 11:07:02 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Feb 2026 11:07:02 GMT
Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for
 all cases [v4]
In-Reply-To: <f-pCYqS3XjYMiPqZAfn7ozyF-6Q0H1szmeFnTPADH1g=.7d753037-1112-4397-9d32-5144d549fb75@github.com>
References: <sbp120wZjbJcEpyWDT9It7wFl_zU1kXNiHz7QMkd6RA=.46fa522d-104a-4c6f-a18f-cb0f8f37cad4@github.com>
 <RlKpHz3GaSmQpSjV0X7J16qaHE4VEbiuqayztSMIpy4=.c823d3bd-5388-49de-b034-4800dec34049@github.com>
 <f-pCYqS3XjYMiPqZAfn7ozyF-6Q0H1szmeFnTPADH1g=.7d753037-1112-4397-9d32-5144d549fb75@github.com>
Message-ID: <Z8UkzU7v2KfOM23H8E71DGtiUnB9ZA5E_YoLATvwWDc=.53ee4bbf-d751-418f-b0e1-f828a3ce1c02@github.com>

On Thu, 5 Feb 2026 10:44:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Most of new tests need a copyright year update.

The tests are in the repo since 2025, not changed in 2026 so I didn't bump the copyright year.

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

PR Comment: https://git.openjdk.org/jdk/pull/29461#issuecomment-3852852215

From sspitsyn at openjdk.org  Thu Feb  5 11:12:41 2026
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 5 Feb 2026 11:12:41 GMT
Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for
 all cases [v4]
In-Reply-To: <RlKpHz3GaSmQpSjV0X7J16qaHE4VEbiuqayztSMIpy4=.c823d3bd-5388-49de-b034-4800dec34049@github.com>
References: <sbp120wZjbJcEpyWDT9It7wFl_zU1kXNiHz7QMkd6RA=.46fa522d-104a-4c6f-a18f-cb0f8f37cad4@github.com>
 <RlKpHz3GaSmQpSjV0X7J16qaHE4VEbiuqayztSMIpy4=.c823d3bd-5388-49de-b034-4800dec34049@github.com>
Message-ID: <owJSGCovv6Qdupt3KFoSyq8kvo8binOk8cmP8vtopEk=.bea010b9-a3d8-4c73-997f-3c9852b2178d@github.com>

On Wed, 4 Feb 2026 08:40:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace.
>> 
>> A summary of the changes:
>> 
>> - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state
>> - Thread::getStackTrace is changed to use async_get_stack_trace for all cases
>> - The SUSPENDED substate in VirtualThread is removed
>> - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in
>> - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace
>> 
>> The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait.
>> 
>> A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required.
>> 
>> Testing: tier1-5.  The changes has been already been tested in the loom repo for a few months.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8376568
>  - Merge branch 'master' into JDK-8376568
>  - Review feedback
>  - Improve asserts
>  - Cleanup
>  - Merge branch 'master' into Thread.getStackTrace
>  - Initial commit

Good cleanup and simplifications.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29461#pullrequestreview-3756268557

From duke at openjdk.org  Thu Feb  5 11:50:08 2026
From: duke at openjdk.org (Yi Wu)
Date: Thu, 5 Feb 2026 11:50:08 GMT
Subject: RFR: 8366444: Add support for add/mul reduction operations for
 Float16 [v5]
In-Reply-To: <k7HtHh9tHsN_9GpnP_iu1HgANKVgwE27V9W7pcK3T9Q=.bdfb3b0f-7a6d-4ed3-8076-d792179cdc36@github.com>
References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com>
 <KROTUb6gjcZCTDVdgdaGlgSUP0mAOWnTiKeG1xrfzD4=.b09865ae-4183-44bb-a707-f36db7190066@github.com>
 <HD6s7lEufhGRjcgpGjcLY398Z_KYRH4a0p6hJbOyKUk=.641e3791-f992-4911-b370-49eb2b68a35c@github.com>
 <k7HtHh9tHsN_9GpnP_iu1HgANKVgwE27V9W7pcK3T9Q=.bdfb3b0f-7a6d-4ed3-8076-d792179cdc36@github.com>
Message-ID: <1oKQ1Ced7kkLEhOUtqYChq6ztBJ3Jsy-poFPAob00xM=.fbaa99df-7f53-4d05-b4d6-0a9f1f584291@github.com>

On Mon, 26 Jan 2026 16:51:56 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1940:
>> 
>>> 1938:       }
>>> 1939:   BLOCK_COMMENT("} neon_reduce_add_fp16");
>>> 1940: }
>> 
>> Given that the reduction order is sequential: why do you see any speedup in your benchmarks, comparing scalar to vector performance? How do you explain it? I'm just curious ;)
>
> Also: why not allow a vector with only 2 elements? Is there some restriction here?

Short answer: the speedup is not from parallelizing the reduction chain; it?s from lower overhead and vector loads. On NEON (Neoverse N1) the reduction was scalar fadd chain, but we now load FP16s in vectors, which cuts load count and loop overhead. That alone can improve throughput even when the dependence chain is unchanged.

Before (scalar loads + scalar mov + scalar fadd chain):

ldrsh w13, [x11, #16]
mov   v18.h[0], w13
ldrsh w13, [x11, #18]
mov   v19.h[0], w13
...
fadd  h16, h20, h18
fadd  h18, h21, h16
fadd  h16, h22, h18
fadd  h18, h23, h16
fadd  h16, h17, h18

After (vector loads + scalar ext + scalar fadd):

ldr q17, [x15, #16]
ldr q19, [x15, #32]
...
fadd h18, h16, h17
ext  v26.8b,  v17.8b,  v17.8b,  #2
fadd h18, h18, h26
ext  v26.8b,  v17.8b,  v17.8b,  #4
fadd h18, h18, h26
...


(Bhavana-Kilambi is on leave right now, so I?m taking this over. I will update the test shortly. However, I will be on leave as well starting next week for 2.5 weeks.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2768689930

From vklang at openjdk.org  Thu Feb  5 12:20:23 2026
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 5 Feb 2026 12:20:23 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v31]
In-Reply-To: <YBoyP1MKQyLS-izG5Tl-TFZdRZVGW0VF1Q3sNnFia7w=.7610284c-7d80-4eff-90e8-cc60d2afd7ea@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
 <YBoyP1MKQyLS-izG5Tl-TFZdRZVGW0VF1Q3sNnFia7w=.7610284c-7d80-4eff-90e8-cc60d2afd7ea@github.com>
Message-ID: <GOdFqzqsuH3UugAQQh9MHYmjlxmljX-YGFBAQMG6rh0=.6045b428-853a-43a0-894b-ee8162683a76@github.com>

On Wed, 4 Feb 2026 14:38:03 GMT, Doug Lea <dl at openjdk.org> wrote:

>> Changes signal filtering to avoid possible starvation
>
> 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 43 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8373118
>  - reduce interference after stalls
>  - Avoid yield, for performance test
>  - Don't oversignal LIFO
>  - Try out different approach
>  - Simplify scan mode control by moving and reworking topLevelExec and throwing on trim
>  - Another set of contend vs deactivate vs park tradeoffs
>  - Fix missing undo
>  - Merge branch 'openjdk:master' into JDK-8373118
>  - Use explicit store fences or atomics
>  - ... and 33 more: https://git.openjdk.org/jdk/compare/460535d9...7ae93ed7

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1988:

> 1986:                                 ran = 1;
> 1987:                                 ++taken;
> 1988:                                 if (propagate && U.getReferenceAcquire(a, np) != null)

At this point, it might even make sense to fold the propagate logic into the if-clause itself. Something like:


                                ran = 1;
                                ++taken;
                                if ((rnt != null) &&
                                    (ps < 0 ||
                                     ((qid & 1) == 0 &&
                                      (fifo != 0 || taken == 1))) && U.getReferenceAcquire(a, np) != null)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2768875722

From vklang at openjdk.org  Thu Feb  5 12:23:43 2026
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 5 Feb 2026 12:23:43 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v31]
In-Reply-To: <YBoyP1MKQyLS-izG5Tl-TFZdRZVGW0VF1Q3sNnFia7w=.7610284c-7d80-4eff-90e8-cc60d2afd7ea@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
 <YBoyP1MKQyLS-izG5Tl-TFZdRZVGW0VF1Q3sNnFia7w=.7610284c-7d80-4eff-90e8-cc60d2afd7ea@github.com>
Message-ID: <CYXpBmnqlv3GVLEKwxgIh3mAQY53aD2wFQXs5VPDvIY=.0e9824c1-6c92-4412-8a27-1a4745316e04@github.com>

On Wed, 4 Feb 2026 14:38:03 GMT, Doug Lea <dl at openjdk.org> wrote:

>> Changes signal filtering to avoid possible starvation
>
> 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 43 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8373118
>  - reduce interference after stalls
>  - Avoid yield, for performance test
>  - Don't oversignal LIFO
>  - Try out different approach
>  - Simplify scan mode control by moving and reworking topLevelExec and throwing on trim
>  - Another set of contend vs deactivate vs park tradeoffs
>  - Fix missing undo
>  - Merge branch 'openjdk:master' into JDK-8373118
>  - Use explicit store fences or atomics
>  - ... and 33 more: https://git.openjdk.org/jdk/compare/04656767...7ae93ed7

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2030:

> 2028:                 int phase = U.getInt(w, WorkQueue.PHASE);
> 2029:                 long sp = (phase + NEXTIDLE) & LMASK, pc = ctl;
> 2030:                 U.putInt(w, WorkQueue.PHASE, phase | IDLE);

So the idea here is to potentially delay the store?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2768887155

From vklang at openjdk.org  Thu Feb  5 12:28:11 2026
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 5 Feb 2026 12:28:11 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v31]
In-Reply-To: <YBoyP1MKQyLS-izG5Tl-TFZdRZVGW0VF1Q3sNnFia7w=.7610284c-7d80-4eff-90e8-cc60d2afd7ea@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
 <YBoyP1MKQyLS-izG5Tl-TFZdRZVGW0VF1Q3sNnFia7w=.7610284c-7d80-4eff-90e8-cc60d2afd7ea@github.com>
Message-ID: <c_MUcLQgoNTbXq_FjHgQVcj2WLGyK3FbTzRjh1fdPdE=.55599123-7879-45c5-90f7-7e322f515723@github.com>

On Wed, 4 Feb 2026 14:38:03 GMT, Doug Lea <dl at openjdk.org> wrote:

>> Changes signal filtering to avoid possible starvation
>
> 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 43 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8373118
>  - reduce interference after stalls
>  - Avoid yield, for performance test
>  - Don't oversignal LIFO
>  - Try out different approach
>  - Simplify scan mode control by moving and reworking topLevelExec and throwing on trim
>  - Another set of contend vs deactivate vs park tradeoffs
>  - Fix missing undo
>  - Merge branch 'openjdk:master' into JDK-8373118
>  - Use explicit store fences or atomics
>  - ... and 33 more: https://git.openjdk.org/jdk/compare/40f1886a...7ae93ed7

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2811:

> 2809:                     if (q.base == b && t != null &&
> 2810:                         U.compareAndSetReference(a, k, t, null)) {
> 2811:                         q.base = b + 1;

Doesn't this mean that this write might end up not safely published? ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2768904069

From mablakatov at openjdk.org  Thu Feb  5 13:27:24 2026
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Thu, 5 Feb 2026 13:27:24 GMT
Subject: RFR: 8366444: Add support for add/mul reduction operations for
 Float16 [v5]
In-Reply-To: <k7HtHh9tHsN_9GpnP_iu1HgANKVgwE27V9W7pcK3T9Q=.bdfb3b0f-7a6d-4ed3-8076-d792179cdc36@github.com>
References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com>
 <KROTUb6gjcZCTDVdgdaGlgSUP0mAOWnTiKeG1xrfzD4=.b09865ae-4183-44bb-a707-f36db7190066@github.com>
 <HD6s7lEufhGRjcgpGjcLY398Z_KYRH4a0p6hJbOyKUk=.641e3791-f992-4911-b370-49eb2b68a35c@github.com>
 <k7HtHh9tHsN_9GpnP_iu1HgANKVgwE27V9W7pcK3T9Q=.bdfb3b0f-7a6d-4ed3-8076-d792179cdc36@github.com>
Message-ID: <eKh_0ntLU9EWPfI0MMQ5-Zi3-Q-u8TvhtaQ3P6oRNlg=.539a8e09-d16e-42b5-8124-8a587476a7b8@github.com>

On Mon, 26 Jan 2026 16:51:56 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1940:
>> 
>>> 1938:       }
>>> 1939:   BLOCK_COMMENT("} neon_reduce_add_fp16");
>>> 1940: }
>> 
>> Given that the reduction order is sequential: why do you see any speedup in your benchmarks, comparing scalar to vector performance? How do you explain it? I'm just curious ;)
>
> Also: why not allow a vector with only 2 elements? Is there some restriction here?

Hi @eme64 . That's probably not the only contributing factor but there's a significant difference in latency if we compare a sequence of scalar `addf` to the SVE F16 `fadda` instruction. According to [Neoverse V1](https://developer.arm.com/documentation/109897/latest/) and [Neoverse V2](https://developer.arm.com/documentation/109898/latest/) SWOGs, `fadda` has an execution latency of 19 and 10 cycles for 16 and 8 elements-long vector registers respectively. Scalar `fadd` has an execution latency of 2 cycles, which sums up to 32 and 16 cycles for 16 and 8 values respectively. I hope this explanation makes sense and helps.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2769152062

From rgiulietti at openjdk.org  Thu Feb  5 13:33:09 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 5 Feb 2026 13:33:09 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v8]
In-Reply-To: <Zgjlew-K02IYZ-EjoENRQzL8higlLSBGQ3Pr7VzA4CA=.2251ba23-b851-410e-900f-8a9f5a6bd1d7@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <p57-Mga85sxN41Hdd9JTLGNVazIrkfDjNtCIhz70-ME=.86050f09-06e0-4c6e-80ac-39794153f806@github.com>
 <HTq4KPrH8lZTVHT6_D3Gi1gMTzernd90gAPzZVEJT5c=.953c4ce3-6ee4-4d4c-9036-92763471579d@github.com>
 <Zgjlew-K02IYZ-EjoENRQzL8higlLSBGQ3Pr7VzA4CA=.2251ba23-b851-410e-900f-8a9f5a6bd1d7@github.com>
Message-ID: <0w6KoryTq1Rb_a-q9eAULoFrGDLN-Jd_N12W-XwA5ns=.91e55f80-2bc0-44e2-be03-52c0cd1d8d07@github.com>

On Thu, 5 Feb 2026 08:44:54 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> test/jdk/java/lang/Math/HyperbolicTests.java line 1712:
>> 
>>> 1710:     }
>>> 1711: 
>>> 1712:     public static int testAsinhCaseWithTolerance(double input,
>> 
>> This method is never invoked, IIUC.
>
> Yes, I see the same for existing methods like `sinh`, `cosh`, `tanh`. Should such methods there be removed then?

@jddarcy What is the purpose of such methods that do not seem to be invoked?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2769179697

From rgiulietti at openjdk.org  Thu Feb  5 13:36:45 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 5 Feb 2026 13:36:45 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v8]
In-Reply-To: <Zgjlew-K02IYZ-EjoENRQzL8higlLSBGQ3Pr7VzA4CA=.2251ba23-b851-410e-900f-8a9f5a6bd1d7@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <p57-Mga85sxN41Hdd9JTLGNVazIrkfDjNtCIhz70-ME=.86050f09-06e0-4c6e-80ac-39794153f806@github.com>
 <HTq4KPrH8lZTVHT6_D3Gi1gMTzernd90gAPzZVEJT5c=.953c4ce3-6ee4-4d4c-9036-92763471579d@github.com>
 <Zgjlew-K02IYZ-EjoENRQzL8higlLSBGQ3Pr7VzA4CA=.2251ba23-b851-410e-900f-8a9f5a6bd1d7@github.com>
Message-ID: <pUJlymFMJ0vvLzpxNaqofFlj19izI_0G6RlLYsRWoOo=.4e352be7-c5c0-473c-a892-982a554e72fe@github.com>

On Thu, 5 Feb 2026 08:45:06 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> test/jdk/java/lang/Math/HyperbolicTests.java line 26:
>> 
>>> 24: /*
>>> 25:  * @test
>>> 26:  * @bug 4851625 4900189 4939441
>> 
>> Not sure if this requires the new bug ID.
>
> I think since we have a issue per method, it is not worth having 3 extra bug ids here.

@jddarcy Should we add the umbrella 8331354 in the `@bug` lists?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2769201087

From alanb at openjdk.org  Thu Feb  5 13:46:02 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Feb 2026 13:46:02 GMT
Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for
 all cases [v4]
In-Reply-To: <RlKpHz3GaSmQpSjV0X7J16qaHE4VEbiuqayztSMIpy4=.c823d3bd-5388-49de-b034-4800dec34049@github.com>
References: <sbp120wZjbJcEpyWDT9It7wFl_zU1kXNiHz7QMkd6RA=.46fa522d-104a-4c6f-a18f-cb0f8f37cad4@github.com>
 <RlKpHz3GaSmQpSjV0X7J16qaHE4VEbiuqayztSMIpy4=.c823d3bd-5388-49de-b034-4800dec34049@github.com>
Message-ID: <KkIeC46QaMaDx1OYOkOh-ziDAL-vcWtl834t9VMj0k4=.f8386ff6-c383-43cb-9636-c485821ad4a6@github.com>

On Wed, 4 Feb 2026 08:40:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace.
>> 
>> A summary of the changes:
>> 
>> - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state
>> - Thread::getStackTrace is changed to use async_get_stack_trace for all cases
>> - The SUSPENDED substate in VirtualThread is removed
>> - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in
>> - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace
>> 
>> The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait.
>> 
>> A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required.
>> 
>> Testing: tier1-5.  The changes has been already been tested in the loom repo for a few months.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8376568
>  - Merge branch 'master' into JDK-8376568
>  - Review feedback
>  - Improve asserts
>  - Cleanup
>  - Merge branch 'master' into Thread.getStackTrace
>  - Initial commit

Thanks for the reviews and comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/29461#issuecomment-3853761047

From alanb at openjdk.org  Thu Feb  5 13:49:36 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Feb 2026 13:49:36 GMT
Subject: Integrated: 8376568: Change Thread::getStackTrace to use handshake op
 for all cases
In-Reply-To: <sbp120wZjbJcEpyWDT9It7wFl_zU1kXNiHz7QMkd6RA=.46fa522d-104a-4c6f-a18f-cb0f8f37cad4@github.com>
References: <sbp120wZjbJcEpyWDT9It7wFl_zU1kXNiHz7QMkd6RA=.46fa522d-104a-4c6f-a18f-cb0f8f37cad4@github.com>
Message-ID: <K3eEirWiXfRvS6EdhmxlLtjOn_DMExTRBDFavOrRn1Y=.e4366344-a5fb-4d85-928e-058dc1226c57@github.com>

On Wed, 28 Jan 2026 09:35:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace.
> 
> A summary of the changes:
> 
> - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state
> - Thread::getStackTrace is changed to use async_get_stack_trace for all cases
> - The SUSPENDED substate in VirtualThread is removed
> - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in
> - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace
> 
> The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait.
> 
> A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required.
> 
> Testing: tier1-5.  The changes has been already been tested in the loom repo for a few months.

This pull request has now been integrated.

Changeset: ac6e8d48
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac6e8d481a20b40e136263c0e0c075bd138677ab
Stats:     669 lines in 21 files changed: 445 ins; 168 del; 56 mod

8376568: Change Thread::getStackTrace to use handshake op for all cases

Reviewed-by: pchilanomate, sspitsyn

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

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

From cushon at openjdk.org  Thu Feb  5 14:07:33 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 5 Feb 2026 14:07:33 GMT
Subject: RFR: 8377245: AbstractMemorySegmentImpl#getString with length should
 be @ForceInline
Message-ID: <gvLsEyIsYlOV1SFxFRkAgoKzqQBedErupUudjZr-JTU=.8ac2bb73-adbd-43bb-bcf4-4e1cfa6404ae@github.com>

Please consider this change to add `@ForceInline` to the `MemorySegment#getString` overload added in JDK-8369564. The other pre-existing `#getString` methods already have `@ForceInline` annotations.

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

Commit messages:
 - 8377245: AbstractMemorySegmentImpl#getString with length should be @ForceInline

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

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

From epeter at openjdk.org  Thu Feb  5 14:29:42 2026
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 5 Feb 2026 14:29:42 GMT
Subject: RFR: 8366444: Add support for add/mul reduction operations for
 Float16 [v5]
In-Reply-To: <eKh_0ntLU9EWPfI0MMQ5-Zi3-Q-u8TvhtaQ3P6oRNlg=.539a8e09-d16e-42b5-8124-8a587476a7b8@github.com>
References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com>
 <KROTUb6gjcZCTDVdgdaGlgSUP0mAOWnTiKeG1xrfzD4=.b09865ae-4183-44bb-a707-f36db7190066@github.com>
 <HD6s7lEufhGRjcgpGjcLY398Z_KYRH4a0p6hJbOyKUk=.641e3791-f992-4911-b370-49eb2b68a35c@github.com>
 <k7HtHh9tHsN_9GpnP_iu1HgANKVgwE27V9W7pcK3T9Q=.bdfb3b0f-7a6d-4ed3-8076-d792179cdc36@github.com>
 <eKh_0ntLU9EWPfI0MMQ5-Zi3-Q-u8TvhtaQ3P6oRNlg=.539a8e09-d16e-42b5-8124-8a587476a7b8@github.com>
Message-ID: <zVbXxjjYoEdce4bl8nLa8tD_q1tY-gg1sXP7WXiDYS0=.94c40a5a-0410-484d-9bd8-b2e25bad86b1@github.com>

On Thu, 5 Feb 2026 13:24:30 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> wrote:

>> Also: why not allow a vector with only 2 elements? Is there some restriction here?
>
> Hi @eme64 . That's probably not the only contributing factor but there's a significant difference in latency if we compare a sequence of scalar `addf` to the SVE F16 `fadda` instruction. According to [Neoverse V1](https://developer.arm.com/documentation/109897/latest/) and [Neoverse V2](https://developer.arm.com/documentation/109898/latest/) SWOGs, `fadda` has an execution latency of 19 and 10 cycles for 16 and 8 elements-long vector registers respectively. Scalar `fadd` has an execution latency of 2 cycles, which sums up to 32 and 16 cycles for 16 and 8 values respectively. I hope this explanation makes sense and helps.

Ok, sounds good. Thanks for the explanations! I'll be on leave next week as well, so no hurry :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2769460390

From duke at openjdk.org  Thu Feb  5 14:48:13 2026
From: duke at openjdk.org (David Beaumont)
Date: Thu, 5 Feb 2026 14:48:13 GMT
Subject: RFR: 8377244: Update ModuleReaderTest to JUnit prior to making changes
Message-ID: <XPP-Psp7yG4gvvoaP6cAVgm4ArmyIUKURH7DmZ45L3c=.08d517ec-2710-4c6b-b74b-903d876e8749@github.com>

Updated legacy TestNG asserts to JUnit and added useful context to help debugging when assertions fail.

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

Commit messages:
 - Update test to JUnit

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

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

From duke at openjdk.org  Thu Feb  5 14:48:15 2026
From: duke at openjdk.org (David Beaumont)
Date: Thu, 5 Feb 2026 14:48:15 GMT
Subject: RFR: 8377244: Update ModuleReaderTest to JUnit prior to making
 changes
In-Reply-To: <XPP-Psp7yG4gvvoaP6cAVgm4ArmyIUKURH7DmZ45L3c=.08d517ec-2710-4c6b-b74b-903d876e8749@github.com>
References: <XPP-Psp7yG4gvvoaP6cAVgm4ArmyIUKURH7DmZ45L3c=.08d517ec-2710-4c6b-b74b-903d876e8749@github.com>
Message-ID: <3ySNaeBzQmPPzw-7oacQLhZ8ecrtkQoceEyvAAHe87w=.410931ed-6290-4513-bfd8-9de0a7e3e17c@github.com>

On Thu, 5 Feb 2026 14:39:51 GMT, David Beaumont <duke at openjdk.org> wrote:

> Updated legacy TestNG asserts to JUnit and added useful context to help debugging when assertions fail.

test/jdk/java/lang/module/ModuleReader/ModuleReaderTest.java line 192:

> 190:                 ouri.ifPresent(uri -> {
> 191:                     if (name.endsWith("/"))
> 192:                         assertTrue(uri.toString().endsWith("/"),

The assertions here are basically duplicated further down too.
They are, to all intents and purposes identical, and could be factored out if desired.

test/jdk/java/lang/module/ModuleReader/ModuleReaderTest.java line 214:

> 212:         assertThrows(IOException.class, () -> reader.open(BASE_RESOURCES[0]));
> 213:         assertThrows(IOException.class, () -> reader.read(BASE_RESOURCES[0]));
> 214:         assertThrows(IOException.class, reader::list);

Added seemingly missing case (present below, but not in this version).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29588#discussion_r2769547202
PR Review Comment: https://git.openjdk.org/jdk/pull/29588#discussion_r2769540083

From rriggs at openjdk.org  Thu Feb  5 15:23:10 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 5 Feb 2026 15:23:10 GMT
Subject: RFR: 8377244: Update ModuleReaderTest to JUnit prior to making
 changes
In-Reply-To: <XPP-Psp7yG4gvvoaP6cAVgm4ArmyIUKURH7DmZ45L3c=.08d517ec-2710-4c6b-b74b-903d876e8749@github.com>
References: <XPP-Psp7yG4gvvoaP6cAVgm4ArmyIUKURH7DmZ45L3c=.08d517ec-2710-4c6b-b74b-903d876e8749@github.com>
Message-ID: <BMZO6gaelCE8b2YrokwNK3TgoVhkb0g1cK2uj0WE_F8=.fee120f7-3b60-4c17-8e92-9ad655708191@github.com>

On Thu, 5 Feb 2026 14:39:51 GMT, David Beaumont <duke at openjdk.org> wrote:

> Updated legacy TestNG asserts to JUnit and added useful context to help debugging when assertions fail.

Looks good

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29588#pullrequestreview-3757778542

From afarley at openjdk.org  Thu Feb  5 15:27:03 2026
From: afarley at openjdk.org (Adam Farley)
Date: Thu, 5 Feb 2026 15:27:03 GMT
Subject: RFR: 8376188: Win8365790Test is missing @build
 jtreg.SkippedException
In-Reply-To: <nvD4zR6UT8RduqcBA6bGi4e1lGzMvrRdhZcfxdRTLJs=.6cb87b7a-d249-4ed0-9aa6-6e9fd1f2e9d3@github.com>
References: <nvD4zR6UT8RduqcBA6bGi4e1lGzMvrRdhZcfxdRTLJs=.6cb87b7a-d249-4ed0-9aa6-6e9fd1f2e9d3@github.com>
Message-ID: <jCngolFoIdj-u7WIFkpK9mYW31GwdioPK_oz9p5onuE=.c59b4ea3-7000-4eab-b4fe-3bf407b52bd2@github.com>

On Mon, 26 Jan 2026 13:28:27 GMT, Adam Farley <afarley at openjdk.org> wrote:

> This change ensures that the class "jtreg/SkippedException" can be found and used by the test while running with versions of jtreg that are under 7.5.1+1.
> 
> 
> This has been tested elsewhere and seems to work well.
> Test configs:
> - JDK17 - jtreg 7.3.1+1
> - JDK25 - jtreg 7.5.1+1 
> 
> https://bugs.openjdk.org/browse/JDK-8376188

Based on the conversation above, this issue only appears to be relevant to JDK17u and JDK21u.

While the same test code is *present* in later versions of the JDK, they specify a minimum jtreg version that doesn't show this problem.

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

PR Comment: https://git.openjdk.org/jdk/pull/29416#issuecomment-3854364120

From afarley at openjdk.org  Thu Feb  5 15:27:04 2026
From: afarley at openjdk.org (Adam Farley)
Date: Thu, 5 Feb 2026 15:27:04 GMT
Subject: Withdrawn: 8376188: Win8365790Test is missing @build
 jtreg.SkippedException
In-Reply-To: <nvD4zR6UT8RduqcBA6bGi4e1lGzMvrRdhZcfxdRTLJs=.6cb87b7a-d249-4ed0-9aa6-6e9fd1f2e9d3@github.com>
References: <nvD4zR6UT8RduqcBA6bGi4e1lGzMvrRdhZcfxdRTLJs=.6cb87b7a-d249-4ed0-9aa6-6e9fd1f2e9d3@github.com>
Message-ID: <hA4N9OOxqT1nywWHxyI0M3dgKKgatzlKhzaSrYhAgR4=.9f8a3cf6-006e-4bb1-8c3e-f71a19596c55@github.com>

On Mon, 26 Jan 2026 13:28:27 GMT, Adam Farley <afarley at openjdk.org> wrote:

> This change ensures that the class "jtreg/SkippedException" can be found and used by the test while running with versions of jtreg that are under 7.5.1+1.
> 
> 
> This has been tested elsewhere and seems to work well.
> Test configs:
> - JDK17 - jtreg 7.3.1+1
> - JDK25 - jtreg 7.5.1+1 
> 
> https://bugs.openjdk.org/browse/JDK-8376188

This pull request has been closed without being integrated.

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

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

From jpai at openjdk.org  Thu Feb  5 16:14:57 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 5 Feb 2026 16:14:57 GMT
Subject: RFR: 8375585: Test java/lang/ProcessBuilder/PipelineLeaksFD.java
 failed [v4]
In-Reply-To: <Ci4eVbCCSEMkWEcEpXYBS7YVH1zinI7_Yl_oxUpuEYY=.40010794-41e3-4ec2-9215-44bc1a8a2ad8@github.com>
References: <RcWyeLjeptkC1ZUDvTukbnTXkeCPIOJtseYAcfk3jA8=.41f33014-ff91-431c-83a1-4595edb05669@github.com>
 <Ci4eVbCCSEMkWEcEpXYBS7YVH1zinI7_Yl_oxUpuEYY=.40010794-41e3-4ec2-9215-44bc1a8a2ad8@github.com>
Message-ID: <I0fbYBcOW5RrF8wNJQ9UOgVuAPmr8pspxoEYDDeLELs=.67ceba34-07f1-4eef-8014-4bff4887c9ce@github.com>

On Wed, 4 Feb 2026 14:44:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Revised test to explicitly compare file descriptor info only from parent and child.
>> If additional fd's are present in the child, it is hard to know their origin but they do not necessarily indicate a bug in Process launch.
>>  
>> Remove from the problem list.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge
>  - Removed use of count.
>  - Refactor checks of child pipe use against parent use.
>    Removed simple counts of names as they were unreliable.
>  - 8375585: Test java/lang/ProcessBuilder/PipelineLeaksFD.java failed
>    Revised test to explicitly compare file descriptor info only from parent and child
>    If additional fd's are present in the child, it is hard to know their origin
>    but they do not necessarily indicate a bug in Process launch.

Looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29530#pullrequestreview-3758076861

From duke at openjdk.org  Thu Feb  5 16:25:51 2026
From: duke at openjdk.org (duke)
Date: Thu, 5 Feb 2026 16:25:51 GMT
Subject: RFR: 8377244: Update ModuleReaderTest to JUnit prior to making
 changes
In-Reply-To: <XPP-Psp7yG4gvvoaP6cAVgm4ArmyIUKURH7DmZ45L3c=.08d517ec-2710-4c6b-b74b-903d876e8749@github.com>
References: <XPP-Psp7yG4gvvoaP6cAVgm4ArmyIUKURH7DmZ45L3c=.08d517ec-2710-4c6b-b74b-903d876e8749@github.com>
Message-ID: <GxhrIQg_8dzBJZjSXTUsgv2BGl_FLbRZfpPC6HY5SYk=.d684638f-d142-4085-a62c-c0a7562a4b57@github.com>

On Thu, 5 Feb 2026 14:39:51 GMT, David Beaumont <duke at openjdk.org> wrote:

> Updated legacy TestNG asserts to JUnit and added useful context to help debugging when assertions fail.

@david-beaumont 
Your change (at version c3706f04eb4ac6e99dc8d24717e83d56ebfb1533) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/29588#issuecomment-3854743208

From psandoz at openjdk.org  Thu Feb  5 16:46:12 2026
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 5 Feb 2026 16:46:12 GMT
Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass
 them to intrinsic entries [v8]
In-Reply-To: <kXCEBHjl-u9q6izibtgQl_PFXQVETxKU_plfo3EXozQ=.9b38c603-7053-4934-98de-80c7b99851fd@github.com>
References: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
 <kXCEBHjl-u9q6izibtgQl_PFXQVETxKU_plfo3EXozQ=.9b38c603-7053-4934-98de-80c7b99851fd@github.com>
Message-ID: <s0-_-ihqUcPc6TDo5hDEg8AnPc0B6NEQBqHkHqBz1Eo=.6fb3568d-cb42-4d0f-b52e-71c1ec51a87d@github.com>

On Thu, 5 Feb 2026 04:33:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support.
>> 
>> Patch add new lane type constants and pass them to vector intrinsic entry points.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment resolution

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29481#pullrequestreview-3758240891

From asemenyuk at openjdk.org  Thu Feb  5 17:26:14 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 5 Feb 2026 17:26:14 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v9]
In-Reply-To: <C-8YiKlI0uge38gLDeQRdo7lsr2HBF7PcP0sIkLXLog=.1f55a466-228b-46cc-b444-0bfb21653f9e@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <C-8YiKlI0uge38gLDeQRdo7lsr2HBF7PcP0sIkLXLog=.1f55a466-228b-46cc-b444-0bfb21653f9e@github.com>
Message-ID: <tQbyPxMApNvyu3AUHKl4nbQKYWkoE1ddcosJ9vtq7pg=.e92ce8ca-6579-4e56-9369-581915d40ecb@github.com>

On Thu, 5 Feb 2026 02:52:59 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
>> - Added test to cover added functionality.
>> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v8]

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacFromOptions.java line 237:

> 235:                 return normalizeVersion(version);
> 236:             };
> 237:             app = ApplicationBuilder.normalizeVersion(app, app.version(), versionNormalizer);

Let javac do the work:

 ApplicationBuilder.normalizeVersion(app, app.version(), MacFromOptions::normalizeVersion);

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacFromOptions.java line 367:

> 365:             return ver.toComponentsString();
> 366:         }
> 367:     }

Why branching?

It can be as simple as:

DottedVersion.lazy(version).trim(3).pad(3).toComponentsString()


The same comment applies to other locations where `trim()` and `pad()` are used.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/DottedVersion.java line 253:

> 251: 
> 252:         return this;
> 253:     }

These methods should not modify the instance. They should create and return a copy instead. Besides, the implementation doesn't update the `value` field, so the `toString()` method would return the same string as before any of these methods is called.

The `value` field was OK until the new methods were added; now it is a problem. I suggest getting rid of it.

Attached refactored variant of the class with `trim()` and `pad()` methods implemented so that they don't modify the instance. Passes all tests.

[DottedVersion.patch](https://github.com/user-attachments/files/25105160/DottedVersion.patch)

src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/DottedVersion.java line 263:

> 261:     }
> 262: 
> 263:     private BigInteger[] components;

The "final" was on purpose. It made the instances R/O. This change makes them mutable and not thread-safe.

test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/model/DottedVersionTest.java line 42:

> 40: public class DottedVersionTest {
> 41: 
> 42:     public record TestConfig(String input,

`TestConfig` is used to test the `DottedVersion.greedy()` and `DottedVersion.lazy()` methods, which construct a DottedVersion instance from a string.

`DottedVersion.trim()` and `DottedVersion.pad()` are instance methods. That said, `TestConfig` doesn't fit to test them.

test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/model/DottedVersionTest.java line 163:

> 161:         ));
> 162:         return data;
> 163:     }

Missing coverage:
 - how the suffix is carried
 - toString()


The below fills goverage gaps for the `trim()` method (with the assumpion the `trim()` method doesn't modify the instance, but instead returns a modified copy):

    @ParameterizedTest
    @MethodSource
    public void test_trim(DottedVersion ver, String expectedStr, int limit) {
        var expected = DottedVersion.lazy(expectedStr);
        var actual = ver.trim(limit);
        assertEquals(expected, actual);
        if (limit >= ver.getComponents().length) {
            assertSame(ver, actual);
        } else {
            assertNotSame(ver, actual);
        }
        assertEquals(expectedStr, actual.toString());
    }

    @ParameterizedTest
    @MethodSource
    public void test_trim_negative(DottedVersion ver, int limit) {
        assertThrowsExactly(IllegalArgumentException.class, () -> {
            ver.trim(limit);
        });
    }

    private static Stream<Arguments> test_trim() {

        var testCases = new ArrayList<Arguments>();

        for (var suffix : List.of("", ".foo")) {
            testCases.addAll(List.of(
                    Arguments.of("1.02.3" + suffix, "" + suffix, 0),
                    Arguments.of("1.02.3" + suffix, "1" + suffix, 1),
                    Arguments.of("1.02.3" + suffix, "1.02" + suffix, 2),
                    Arguments.of("1.02.3" + suffix, "1.02.3" + suffix, 3),
                    Arguments.of("1.02.3" + suffix, "1.02.3" + suffix, 4)
            ));
        }

        return testCases.stream().map(DottedVersionTest::mapFirstStringToDottedVersion);
    }

    private static Stream<Arguments> test_trim_negative() {
        return Stream.of(
                Arguments.of("10.5.foo", -1)
        ).map(DottedVersionTest::mapFirstStringToDottedVersion);
    }

    private static Arguments mapFirstStringToDottedVersion(Arguments v) {
        var objs = v.get();
        objs[0] = DottedVersion.lazy((String)objs[0]);
        return Arguments.of(objs);
    }

test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/RuntimeVersionReaderTest.java line 50:

> 48:         "27.1.2, false",
> 49:         "27.1.2-ea, true",
> 50:         "27.1.2-ea, false"

Can we remove redundant `quoteVesrion` parameter and simplify it to:

@CsvSource({
        ""27.1.2"",
        "27.1.2",
        ""27.1.2-ea"",
        "27.1.2-ea"
})

?

test/jdk/tools/jpackage/share/NoMPathRuntimeTest.java line 99:

> 97:                 Files.createDirectories(workDir.resolve("Contents/MacOS"));
> 98:             }
> 99:         }

I don't understand the comment. Why is this change?

test/jdk/tools/jpackage/share/RuntimePackageTest.java line 148:

> 146:     @Parameter(value = {"17.21.3-ea", "17.21.3"}, ifOS = MACOS)
> 147:     @Parameter(value = {"17.21.3-ea", "17.21.3.0"}, ifOS = WINDOWS)
> 148:     public static void testReleaseFileVersion(String version, String normalizedVersion) {

We need a test case(s) when the "release" has an invalid JDK version to verify jpackage will ignore it. Something like:

@Parameter(value = {"foo", "1.0"})
@Parameter(value = {"", "1.0"})
@Parameter(value = {"17.21.3-foo", "1.0"})

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2770290107
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2770281987
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2770246352
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2770225139
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2770201577
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2770221902
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2769832525
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2769800430
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2769819521

From naoto at openjdk.org  Thu Feb  5 17:35:37 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Feb 2026 17:35:37 GMT
Subject: RFR: 8377013: TimeZone.getDefault() returns obsolete id on Windows
 (Asia/Calcutta)
Message-ID: <PMPp8Dq_aPJspR1mTJWBnZOvlsl_aRxf69oYFVSgK1I=.347739c4-b0f9-4d6f-82bc-55d5c356d798@github.com>

Fixing the Windows default time zones returned from `TimeZone.getDefault()` for some regions. On Windows, it uses their own regions for time zones that aren't 1-1 match to IANA's TZ database. Thus a mapping table is created as `conf/tzmappings` on Windows Java runtime. It is derived from CLDR's `windowsZones.xml` but it uses the obsolete IANA ids for their compatibility reasons. The fix is to replace the CLDR's old ids to the latest IANA ids for those regions.
Since it is hard to provide an automated test, as it involves the modification of the Windows' default time zone, regression test is not provided. Instead the fix is manually confirmed using the JIRA issue's example. Since this is a change in behavior, I will file a corresponding CSR/RN.

Here is the diff of the generated `conf/tzmappings` for reference:

@@ -13,7 +13,7 @@
 Arabian Standard Time:ZZ:Etc/GMT-4:
 Arabian Standard Time:001:Asia/Dubai:
 Arabic Standard Time:001:Asia/Baghdad:
-Argentina Standard Time:001:America/Buenos_Aires:
+Argentina Standard Time:001:America/Argentina/Buenos_Aires:
 Astrakhan Standard Time:001:Europe/Astrakhan:
 Atlantic Standard Time:BM:Atlantic/Bermuda:
 Atlantic Standard Time:GL:America/Thule:
@@ -58,7 +58,7 @@
 Central European Standard Time:MK:Europe/Skopje:
 Central European Standard Time:001:Europe/Warsaw:
 Central Pacific Standard Time:AQ:Antarctica/Casey:
-Central Pacific Standard Time:FM:Pacific/Ponape:
+Central Pacific Standard Time:FM:Pacific/Pohnpei:
 Central Pacific Standard Time:NC:Pacific/Noumea:
 Central Pacific Standard Time:VU:Pacific/Efate:
 Central Pacific Standard Time:ZZ:Etc/GMT-11:
@@ -75,7 +75,7 @@
 Dateline Standard Time:001:Etc/GMT+12:
 E. Africa Standard Time:AQ:Antarctica/Syowa:
 E. Africa Standard Time:DJ:Africa/Djibouti:
-E. Africa Standard Time:ER:Africa/Asmera:
+E. Africa Standard Time:ER:Africa/Asmara:
 E. Africa Standard Time:ET:Africa/Addis_Ababa:
 E. Africa Standard Time:KM:Indian/Comoro:
 E. Africa Standard Time:MG:Indian/Antananarivo:
@@ -101,10 +101,10 @@
 FLE Standard Time:FI:Europe/Helsinki:
 FLE Standard Time:LT:Europe/Vilnius:
 FLE Standard Time:LV:Europe/Riga:
-FLE Standard Time:001:Europe/Kiev:
+FLE Standard Time:001:Europe/Kyiv:
 Fiji Standard Time:001:Pacific/Fiji:
 GMT Standard Time:ES:Atlantic/Canary:
-GMT Standard Time:FO:Atlantic/Faeroe:
+GMT Standard Time:FO:Atlantic/Faroe:
 GMT Standard Time:GG:Europe/Guernsey:
 GMT Standard Time:IE:Europe/Dublin:
 GMT Standard Time:IM:Europe/Isle_of_Man:
@@ -115,7 +115,7 @@
 GTB Standard Time:GR:Europe/Athens:
 GTB Standard Time:001:Europe/Bucharest:
 Georgian Standard Time:001:Asia/Tbilisi:
-Greenland Standard Time:001:America/Godthab:
+Greenland Standard Time:001:America/Nuuk:
 Greenwich Standard Time:BF:Africa/Ouagadougou:
 Greenwich Standard Time:CI:Africa/Abidjan:
 Greenwich Standard Time:GH:Africa/Accra:
@@ -136,7 +136,7 @@
 Hawaiian Standard Time:PF:Pacific/Tahiti:
 Hawaiian Standard Time:ZZ:Etc/GMT+10:
 Hawaiian Standard Time:001:Pacific/Honolulu:
-India Standard Time:001:Asia/Calcutta:
+India Standard Time:001:Asia/Kolkata:
 Iran Standard Time:001:Asia/Tehran:
 Israel Standard Time:001:Asia/Jerusalem:
 Jordan Standard Time:001:Asia/Amman:
@@ -161,10 +161,10 @@
 Mountain Standard Time:001:America/Denver:
 Mountain Standard Time (Mexico):001:America/Mazatlan:
 Myanmar Standard Time:CC:Indian/Cocos:
-Myanmar Standard Time:001:Asia/Rangoon:
+Myanmar Standard Time:001:Asia/Yangon:
 N. Central Asia Standard Time:001:Asia/Novosibirsk:
 Namibia Standard Time:001:Africa/Windhoek:
-Nepal Standard Time:001:Asia/Katmandu:
+Nepal Standard Time:001:Asia/Kathmandu:
 New Zealand Standard Time:AQ:Antarctica/McMurdo:
 New Zealand Standard Time:001:Pacific/Auckland:
 Newfoundland Standard Time:001:America/St_Johns:
@@ -196,7 +196,7 @@
 SA Eastern Standard Time:ZZ:Etc/GMT+3:
 SA Eastern Standard Time:001:America/Cayenne:
 SA Pacific Standard Time:BR:America/Rio_Branco:
-SA Pacific Standard Time:CA:America/Coral_Harbour:
+SA Pacific Standard Time:CA:America/Atikokan:
 SA Pacific Standard Time:EC:America/Guayaquil:
 SA Pacific Standard Time:JM:America/Jamaica:
 SA Pacific Standard Time:KY:America/Cayman:
@@ -236,7 +236,7 @@
 SE Asia Standard Time:ID:Asia/Jakarta:
 SE Asia Standard Time:KH:Asia/Phnom_Penh:
 SE Asia Standard Time:LA:Asia/Vientiane:
-SE Asia Standard Time:VN:Asia/Saigon:
+SE Asia Standard Time:VN:Asia/Ho_Chi_Minh:
 SE Asia Standard Time:ZZ:Etc/GMT-7:
 SE Asia Standard Time:001:Asia/Bangkok:
 Saint Pierre Standard Time:001:America/Miquelon:
@@ -279,7 +279,7 @@
 Transbaikal Standard Time:001:Asia/Chita:
 Turkey Standard Time:001:Europe/Istanbul:
 Turks And Caicos Standard Time:001:America/Grand_Turk:
-US Eastern Standard Time:001:America/Indianapolis:
+US Eastern Standard Time:001:America/Indiana/Indianapolis:
 US Mountain Standard Time:CA:America/Creston:
 US Mountain Standard Time:MX:America/Hermosillo:
 US Mountain Standard Time:ZZ:Etc/GMT+7:
@@ -292,7 +292,7 @@
 UTC+12:UM:Pacific/Wake:
 UTC+12:WF:Pacific/Wallis:
 UTC+12:001:Etc/GMT-12:
-UTC+13:KI:Pacific/Enderbury:
+UTC+13:KI:Pacific/Kanton:
 UTC+13:TK:Pacific/Fakaofo:
 UTC+13:001:Etc/GMT-13:
 UTC-02:BR:America/Noronha:
@@ -352,7 +352,7 @@
 West Asia Standard Time:001:Asia/Tashkent:
 West Bank Standard Time:001:Asia/Hebron:
 West Pacific Standard Time:AQ:Antarctica/DumontDUrville:
-West Pacific Standard Time:FM:Pacific/Truk:
+West Pacific Standard Time:FM:Pacific/Chuuk:
 West Pacific Standard Time:GU:Pacific/Guam:
 West Pacific Standard Time:MP:Pacific/Saipan:
 West Pacific Standard Time:ZZ:Etc/GMT-10:

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

Commit messages:
 - initial commit

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

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

From rriggs at openjdk.org  Thu Feb  5 17:44:01 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 5 Feb 2026 17:44:01 GMT
Subject: Integrated: 8375585: Test
 java/lang/ProcessBuilder/PipelineLeaksFD.java failed
In-Reply-To: <RcWyeLjeptkC1ZUDvTukbnTXkeCPIOJtseYAcfk3jA8=.41f33014-ff91-431c-83a1-4595edb05669@github.com>
References: <RcWyeLjeptkC1ZUDvTukbnTXkeCPIOJtseYAcfk3jA8=.41f33014-ff91-431c-83a1-4595edb05669@github.com>
Message-ID: <ewBzvoNfQioMZk44k0lbVinH48ggEaPobzI0RgZDBtU=.81d67f5e-fdf9-4d80-a1c1-96905856fd09@github.com>

On Mon, 2 Feb 2026 19:37:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Revised test to explicitly compare file descriptor info only from parent and child.
> If additional fd's are present in the child, it is hard to know their origin but they do not necessarily indicate a bug in Process launch.
>  
> Remove from the problem list.

This pull request has now been integrated.

Changeset: 22e1f68a
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/22e1f68a259f2932afdb861cd4977fbe000f131f
Stats:     84 lines in 3 files changed: 41 ins; 15 del; 28 mod

8375585: Test java/lang/ProcessBuilder/PipelineLeaksFD.java failed

Reviewed-by: jpai, syan

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

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

From duke at openjdk.org  Thu Feb  5 17:47:26 2026
From: duke at openjdk.org (David Beaumont)
Date: Thu, 5 Feb 2026 17:47:26 GMT
Subject: Integrated: 8377244: Update ModuleReaderTest to JUnit prior to making
 changes
In-Reply-To: <XPP-Psp7yG4gvvoaP6cAVgm4ArmyIUKURH7DmZ45L3c=.08d517ec-2710-4c6b-b74b-903d876e8749@github.com>
References: <XPP-Psp7yG4gvvoaP6cAVgm4ArmyIUKURH7DmZ45L3c=.08d517ec-2710-4c6b-b74b-903d876e8749@github.com>
Message-ID: <o5WpJxqYjXss5FD-19k8D38x6jSvxEKDLB501AQumc0=.deefab2d-9a46-48bf-ae1e-3c9e6f2bf964@github.com>

On Thu, 5 Feb 2026 14:39:51 GMT, David Beaumont <duke at openjdk.org> wrote:

> Updated legacy TestNG asserts to JUnit and added useful context to help debugging when assertions fail.

This pull request has now been integrated.

Changeset: 4e6cf8f5
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e6cf8f5611b6f1ae1d18b01e95216d9bf43ee5a
Stats:     105 lines in 1 file changed: 6 ins; 55 del; 44 mod

8377244: Update ModuleReaderTest to JUnit prior to making changes

Reviewed-by: rriggs

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

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

From jlu at openjdk.org  Thu Feb  5 19:00:05 2026
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 5 Feb 2026 19:00:05 GMT
Subject: Integrated: 8377116: Refactor java/util/zip TestNG tests to JUnit
In-Reply-To: <QPduW9IIUl5rdWQ4uTQpnO_2yqX8E2sZO12uTEE2oaE=.40f85d49-bac5-4b73-88d2-4ff597a6ba46@github.com>
References: <QPduW9IIUl5rdWQ4uTQpnO_2yqX8E2sZO12uTEE2oaE=.40f85d49-bac5-4b73-88d2-4ff597a6ba46@github.com>
Message-ID: <YFLS0PpifkReQNdkrO8vddETaqUkTxR62VdYh56ddOg=.e803e2e8-a77a-43d6-a770-2048d19278b5@github.com>

On Tue, 3 Feb 2026 22:09:58 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR consists of a conversion for the java/util/zip TestNG tests to JUnit. Changes are mainly automated. https://github.com/openjdk/jdk/commit/1aeb8a634b8f255853516015f4b39bd79dd94090 is required to resolve a failure since JUnit parameterized tests automatically close arguments that implement `AutoCloseable`.
> 
> Test stats before:
> Framework-based tests: 274 = 107 TestNG + 167 JUnit
> 
> Test stats after:
> Framework-based tests: 274 = 0 TestNG + 274 JUnit

This pull request has now been integrated.

Changeset: 99be94e3
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/99be94e38f69f9c64d9142e44acc22f5689b26f1
Stats:     372 lines in 12 files changed: 76 ins; 42 del; 254 mod

8377116: Refactor java/util/zip TestNG tests to JUnit

Reviewed-by: lancea

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

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

From jlu at openjdk.org  Thu Feb  5 22:53:05 2026
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 5 Feb 2026 22:53:05 GMT
Subject: RFR: 8377013: TimeZone.getDefault() returns obsolete id on Windows
 (Asia/Calcutta)
In-Reply-To: <vyGu9GS7-w8xQiaM51-i2WVLvSWWxiU909NiqyuUZUQ=.cd65372d-a23f-41e8-afe6-ea4f66306d06@github.com>
References: <PMPp8Dq_aPJspR1mTJWBnZOvlsl_aRxf69oYFVSgK1I=.347739c4-b0f9-4d6f-82bc-55d5c356d798@github.com>
 <vyGu9GS7-w8xQiaM51-i2WVLvSWWxiU909NiqyuUZUQ=.cd65372d-a23f-41e8-afe6-ea4f66306d06@github.com>
Message-ID: <JwKVvFPVCUyZDHSxh05rIdlAs35W1uGDB5C-p3dxsA0=.5a5e1ea2-4352-4a24-9348-296e56b0215c@github.com>

On Thu, 5 Feb 2026 22:32:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Fixing the Windows default time zones returned from `TimeZone.getDefault()` for some regions. On Windows, it uses their own regions for time zones that aren't 1-1 match to IANA's TZ database. Thus a mapping table is created as `conf/tzmappings` on Windows Java runtime. It is derived from CLDR's `windowsZones.xml` but it uses the obsolete IANA ids for their compatibility reasons. The fix is to replace the CLDR's old ids to the latest IANA ids for those regions.
>> Since it is hard to provide an automated test, as it involves the modification of the Windows' default time zone, regression test is not provided. Instead the fix is manually confirmed using the JIRA issue's example. Since this is a change in behavior, I will file a corresponding CSR/RN.
>> 
>> Here is the diff of the generated `conf/tzmappings` for reference:
>> 
>> @@ -13,7 +13,7 @@
>>  Arabian Standard Time:ZZ:Etc/GMT-4:
>>  Arabian Standard Time:001:Asia/Dubai:
>>  Arabic Standard Time:001:Asia/Baghdad:
>> -Argentina Standard Time:001:America/Buenos_Aires:
>> +Argentina Standard Time:001:America/Argentina/Buenos_Aires:
>>  Astrakhan Standard Time:001:Europe/Astrakhan:
>>  Atlantic Standard Time:BM:Atlantic/Bermuda:
>>  Atlantic Standard Time:GL:America/Thule:
>> @@ -58,7 +58,7 @@
>>  Central European Standard Time:MK:Europe/Skopje:
>>  Central European Standard Time:001:Europe/Warsaw:
>>  Central Pacific Standard Time:AQ:Antarctica/Casey:
>> -Central Pacific Standard Time:FM:Pacific/Ponape:
>> +Central Pacific Standard Time:FM:Pacific/Pohnpei:
>>  Central Pacific Standard Time:NC:Pacific/Noumea:
>>  Central Pacific Standard Time:VU:Pacific/Efate:
>>  Central Pacific Standard Time:ZZ:Etc/GMT-11:
>> @@ -75,7 +75,7 @@
>>  Dateline Standard Time:001:Etc/GMT+12:
>>  E. Africa Standard Time:AQ:Antarctica/Syowa:
>>  E. Africa Standard Time:DJ:Africa/Djibouti:
>> -E. Africa Standard Time:ER:Africa/Asmera:
>> +E. Africa Standard Time:ER:Africa/Asmara:
>>  E. Africa Standard Time:ET:Africa/Addis_Ababa:
>>  E. Africa Standard Time:KM:Indian/Comoro:
>>  E. Africa Standard Time:MG:Indian/Antananarivo:
>> @@ -101,10 +101,10 @@
>>  FLE Standard Time:FI:Europe/Helsinki:
>>  FLE Standard Time:LT:Europe/Vilnius:
>>  FLE Standard Time:LV:Europe/Riga:
>> -FLE Standard Time:001:Europe/Kiev:
>> +FLE Standard Time:001:Europe/Kyiv:
>>  Fiji Standard Time:001:Pacific/Fiji:
>>  GMT Standard Time:ES:Atlantic/Canary:
>> -GMT Standard Time:FO:Atlantic/Faeroe:
>> +GMT Standard Time:FO:Atlantic/Faroe:
>>  GMT Standard Time:GG:Europe/Guernsey:
>>  GMT Standard Time...
>
> make/jdk/src/classes/build/tools/cldrconverter/TimeZoneParseHandler.java line 45:
> 
>> 43: class TimeZoneParseHandler extends AbstractLDMLHandler<Object> {
>> 44:     private static final String PREF_PREFIX = "preferred:";
>> 45:     private final Map<String, String> ianaAliasMap = HashMap.newHashMap(32);
> 
> To give a sense of understanding, I recommend adding a comment indicating that the size of the `ianaAliasMap` can be estimated from the number of `iana` attributes present in _timezone.xml_. Including the CLDR version in this comment would help with locating and updating the size when CLDR data is upgraded in the JDK.

Separately, the size of the map seems to be 45 (and 26 when adding the identity check I noted below).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29591#discussion_r2771444477

From jlu at openjdk.org  Thu Feb  5 22:53:04 2026
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 5 Feb 2026 22:53:04 GMT
Subject: RFR: 8377013: TimeZone.getDefault() returns obsolete id on Windows
 (Asia/Calcutta)
In-Reply-To: <PMPp8Dq_aPJspR1mTJWBnZOvlsl_aRxf69oYFVSgK1I=.347739c4-b0f9-4d6f-82bc-55d5c356d798@github.com>
References: <PMPp8Dq_aPJspR1mTJWBnZOvlsl_aRxf69oYFVSgK1I=.347739c4-b0f9-4d6f-82bc-55d5c356d798@github.com>
Message-ID: <vyGu9GS7-w8xQiaM51-i2WVLvSWWxiU909NiqyuUZUQ=.cd65372d-a23f-41e8-afe6-ea4f66306d06@github.com>

On Thu, 5 Feb 2026 17:27:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the Windows default time zones returned from `TimeZone.getDefault()` for some regions. On Windows, it uses their own regions for time zones that aren't 1-1 match to IANA's TZ database. Thus a mapping table is created as `conf/tzmappings` on Windows Java runtime. It is derived from CLDR's `windowsZones.xml` but it uses the obsolete IANA ids for their compatibility reasons. The fix is to replace the CLDR's old ids to the latest IANA ids for those regions.
> Since it is hard to provide an automated test, as it involves the modification of the Windows' default time zone, regression test is not provided. Instead the fix is manually confirmed using the JIRA issue's example. Since this is a change in behavior, I will file a corresponding CSR/RN.
> 
> Here is the diff of the generated `conf/tzmappings` for reference:
> 
> @@ -13,7 +13,7 @@
>  Arabian Standard Time:ZZ:Etc/GMT-4:
>  Arabian Standard Time:001:Asia/Dubai:
>  Arabic Standard Time:001:Asia/Baghdad:
> -Argentina Standard Time:001:America/Buenos_Aires:
> +Argentina Standard Time:001:America/Argentina/Buenos_Aires:
>  Astrakhan Standard Time:001:Europe/Astrakhan:
>  Atlantic Standard Time:BM:Atlantic/Bermuda:
>  Atlantic Standard Time:GL:America/Thule:
> @@ -58,7 +58,7 @@
>  Central European Standard Time:MK:Europe/Skopje:
>  Central European Standard Time:001:Europe/Warsaw:
>  Central Pacific Standard Time:AQ:Antarctica/Casey:
> -Central Pacific Standard Time:FM:Pacific/Ponape:
> +Central Pacific Standard Time:FM:Pacific/Pohnpei:
>  Central Pacific Standard Time:NC:Pacific/Noumea:
>  Central Pacific Standard Time:VU:Pacific/Efate:
>  Central Pacific Standard Time:ZZ:Etc/GMT-11:
> @@ -75,7 +75,7 @@
>  Dateline Standard Time:001:Etc/GMT+12:
>  E. Africa Standard Time:AQ:Antarctica/Syowa:
>  E. Africa Standard Time:DJ:Africa/Djibouti:
> -E. Africa Standard Time:ER:Africa/Asmera:
> +E. Africa Standard Time:ER:Africa/Asmara:
>  E. Africa Standard Time:ET:Africa/Addis_Ababa:
>  E. Africa Standard Time:KM:Indian/Comoro:
>  E. Africa Standard Time:MG:Indian/Antananarivo:
> @@ -101,10 +101,10 @@
>  FLE Standard Time:FI:Europe/Helsinki:
>  FLE Standard Time:LT:Europe/Vilnius:
>  FLE Standard Time:LV:Europe/Riga:
> -FLE Standard Time:001:Europe/Kiev:
> +FLE Standard Time:001:Europe/Kyiv:
>  Fiji Standard Time:001:Pacific/Fiji:
>  GMT Standard Time:ES:Atlantic/Canary:
> -GMT Standard Time:FO:Atlantic/Faeroe:
> +GMT Standard Time:FO:Atlantic/Faroe:
>  GMT Standard Time:GG:Europe/Guernsey:
>  GMT Standard Time:IE:Europe/Dublin:
>  GMT Standard Time:IM:Europe/Isle_of_Man:
> @@ -115,7 +115,7 @@
>  GTB St...

make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 296:

> 294: 
> 295:         // Parse data independent of locales
> 296:         parseBCP47();

Perhaps a comment either here or in `bcp47()` which indicates that parseBCP47 **must** precede `parseSupplemental()` such that the aliases can be derived from _timezone.xml_ first.

make/jdk/src/classes/build/tools/cldrconverter/TimeZoneParseHandler.java line 45:

> 43: class TimeZoneParseHandler extends AbstractLDMLHandler<Object> {
> 44:     private static final String PREF_PREFIX = "preferred:";
> 45:     private final Map<String, String> ianaAliasMap = HashMap.newHashMap(32);

To give a sense of understanding, I recommend adding a comment indicating that the size of the `ianaAliasMap` can be estimated from the number of `iana` attributes present in _timezone.xml_. Including the CLDR version in this comment would help with locating and updating the size when CLDR data is upgraded in the JDK.

make/jdk/src/classes/build/tools/cldrconverter/TimeZoneParseHandler.java line 72:

> 70:                     if (iana != null) {
> 71:                         for (var a : alias.split("\\s+")) {
> 72:                             ianaAliasMap.put(a, iana);

I think we should add a check to not add `a` to the `ianaAliasMap` if `a` is equal to `iana`, since the mapping would be identical. E.g. "Asia/Kolkata" -> "Asia/Kolkata".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29591#discussion_r2771466800
PR Review Comment: https://git.openjdk.org/jdk/pull/29591#discussion_r2771442549
PR Review Comment: https://git.openjdk.org/jdk/pull/29591#discussion_r2771318244

From missa at openjdk.org  Thu Feb  5 23:24:00 2026
From: missa at openjdk.org (Mohamed Issa)
Date: Thu, 5 Feb 2026 23:24:00 GMT
Subject: RFR: 8371955: Support AVX10 floating point comparison instructions
 [v9]
In-Reply-To: <71uI1BCZPJmBfUhtRMBcRREf63StolB9Ch0vhgPgZeU=.c3bbfca7-e9da-4caf-82c6-be28ef4f98fe@github.com>
References: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>
 <xb6Vynn9YvjBOEQA07oDT6uaaZZwOqofv-oDx7U8QAY=.4d61455a-bbba-4d73-8c38-06e365827d05@github.com>
 <pDlUnmb64685l7fUy6_2jpow34OMR3JBs63-PMnoAM0=.ae33e19d-66ff-4f1f-b162-e4974e0b0fe5@github.com>
 <71uI1BCZPJmBfUhtRMBcRREf63StolB9Ch0vhgPgZeU=.c3bbfca7-e9da-4caf-82c6-be28ef4f98fe@github.com>
Message-ID: <VsVaxHhTbaIqdAR5nxCYH2zVZE8i7Mbpgi6JoCPkJv0=.35793cde-188e-4ba0-9bad-691cf04d218a@github.com>

On Mon, 2 Feb 2026 18:37:34 GMT, Mohamed Issa <missa at openjdk.org> wrote:

> > FYI: testing launched ?
> 
> @eme64 Did tests pass?

@mhaessig Would you be able to check the test logs for the run Emmanuel launched as I believe he is on vacation? I plan to integrate this PR soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/28337#issuecomment-3856943674

From missa at openjdk.org  Fri Feb  6 00:03:18 2026
From: missa at openjdk.org (Mohamed Issa)
Date: Fri, 6 Feb 2026 00:03:18 GMT
Subject: RFR: 8371955: Support AVX10 floating point comparison instructions
 [v10]
In-Reply-To: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>
References: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>
Message-ID: <6FVuBg-wg5wBqcQy2egEckt3tP0zcYH6mg9mm0g_7xg=.23ae2d7c-c7e3-45fb-bedf-3eb48901b418@github.com>

> Intel&reg; AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN.
> 
> Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added.
> 
> This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26).
> 
> 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java`
> 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java`
> 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java`
> 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java`
> 
> Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths.
> 
> 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java`
> 
> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10

Mohamed Issa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - Merge tag 'tags/jdk-27+8' into user/missa-prime/avx10_2
   
   Added tag jdk-27+8 for changeset 949370ab
 - Add double precision test to CMoveLConstants.java
 - Merge branch 'master' into user/missa-prime/avx10_2
 - Merge branch 'master' into user/missa-prime/avx10_2
 - Change function names and extend IR encoding rules for CMove tests
 - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2
 - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2
 - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad
 - Also update copyright year in IREncodingPrinter.java
 - Include apx_f in list of verified CPU features for IR encoding
 - ... and 17 more: https://git.openjdk.org/jdk/compare/949370ab...205bcf8b

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

Changes: https://git.openjdk.org/jdk/pull/28337/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=09
  Stats: 877 lines in 10 files changed: 677 ins; 105 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/28337.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28337/head:pull/28337

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

From naoto at openjdk.org  Fri Feb  6 00:32:13 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Feb 2026 00:32:13 GMT
Subject: RFR: 8377013: TimeZone.getDefault() returns obsolete id on Windows
 (Asia/Calcutta) [v2]
In-Reply-To: <PMPp8Dq_aPJspR1mTJWBnZOvlsl_aRxf69oYFVSgK1I=.347739c4-b0f9-4d6f-82bc-55d5c356d798@github.com>
References: <PMPp8Dq_aPJspR1mTJWBnZOvlsl_aRxf69oYFVSgK1I=.347739c4-b0f9-4d6f-82bc-55d5c356d798@github.com>
Message-ID: <FzZY6RBGXd2YYTBcQR9Idz3WO_aXVor0_auv8zKUgvE=.646923cb-8a2a-4611-b526-9c2b6b351203@github.com>

> Fixing the Windows default time zones returned from `TimeZone.getDefault()` for some regions. On Windows, it uses their own regions for time zones that aren't 1-1 match to IANA's TZ database. Thus a mapping table is created as `conf/tzmappings` on Windows Java runtime. It is derived from CLDR's `windowsZones.xml` but it uses the obsolete IANA ids for their compatibility reasons. The fix is to replace the CLDR's old ids to the latest IANA ids for those regions.
> Since it is hard to provide an automated test, as it involves the modification of the Windows' default time zone, regression test is not provided. Instead the fix is manually confirmed using the JIRA issue's example. Since this is a change in behavior, I will file a corresponding CSR/RN.
> 
> Here is the diff of the generated `conf/tzmappings` for reference:
> 
> @@ -13,7 +13,7 @@
>  Arabian Standard Time:ZZ:Etc/GMT-4:
>  Arabian Standard Time:001:Asia/Dubai:
>  Arabic Standard Time:001:Asia/Baghdad:
> -Argentina Standard Time:001:America/Buenos_Aires:
> +Argentina Standard Time:001:America/Argentina/Buenos_Aires:
>  Astrakhan Standard Time:001:Europe/Astrakhan:
>  Atlantic Standard Time:BM:Atlantic/Bermuda:
>  Atlantic Standard Time:GL:America/Thule:
> @@ -58,7 +58,7 @@
>  Central European Standard Time:MK:Europe/Skopje:
>  Central European Standard Time:001:Europe/Warsaw:
>  Central Pacific Standard Time:AQ:Antarctica/Casey:
> -Central Pacific Standard Time:FM:Pacific/Ponape:
> +Central Pacific Standard Time:FM:Pacific/Pohnpei:
>  Central Pacific Standard Time:NC:Pacific/Noumea:
>  Central Pacific Standard Time:VU:Pacific/Efate:
>  Central Pacific Standard Time:ZZ:Etc/GMT-11:
> @@ -75,7 +75,7 @@
>  Dateline Standard Time:001:Etc/GMT+12:
>  E. Africa Standard Time:AQ:Antarctica/Syowa:
>  E. Africa Standard Time:DJ:Africa/Djibouti:
> -E. Africa Standard Time:ER:Africa/Asmera:
> +E. Africa Standard Time:ER:Africa/Asmara:
>  E. Africa Standard Time:ET:Africa/Addis_Ababa:
>  E. Africa Standard Time:KM:Indian/Comoro:
>  E. Africa Standard Time:MG:Indian/Antananarivo:
> @@ -101,10 +101,10 @@
>  FLE Standard Time:FI:Europe/Helsinki:
>  FLE Standard Time:LT:Europe/Vilnius:
>  FLE Standard Time:LV:Europe/Riga:
> -FLE Standard Time:001:Europe/Kiev:
> +FLE Standard Time:001:Europe/Kyiv:
>  Fiji Standard Time:001:Pacific/Fiji:
>  GMT Standard Time:ES:Atlantic/Canary:
> -GMT Standard Time:FO:Atlantic/Faeroe:
> +GMT Standard Time:FO:Atlantic/Faroe:
>  GMT Standard Time:GG:Europe/Guernsey:
>  GMT Standard Time:IE:Europe/Dublin:
>  GMT Standard Time:IM:Europe/Isle_of_Man:
> @@ -115,7 +115,7 @@
>  GTB St...

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/29591/files
  - new: https://git.openjdk.org/jdk/pull/29591/files/079e2f32..778b949f

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

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

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

From naoto at openjdk.org  Fri Feb  6 00:32:14 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Feb 2026 00:32:14 GMT
Subject: RFR: 8377013: TimeZone.getDefault() returns obsolete id on Windows
 (Asia/Calcutta)
In-Reply-To: <PMPp8Dq_aPJspR1mTJWBnZOvlsl_aRxf69oYFVSgK1I=.347739c4-b0f9-4d6f-82bc-55d5c356d798@github.com>
References: <PMPp8Dq_aPJspR1mTJWBnZOvlsl_aRxf69oYFVSgK1I=.347739c4-b0f9-4d6f-82bc-55d5c356d798@github.com>
Message-ID: <rMctKwUZgBc-eduSPJ0Uha2MN2mMVTZCQl0SK7tMY5o=.345361ab-6664-4383-a871-4d455e2a67a8@github.com>

On Thu, 5 Feb 2026 17:27:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the Windows default time zones returned from `TimeZone.getDefault()` for some regions. On Windows, it uses their own regions for time zones that aren't 1-1 match to IANA's TZ database. Thus a mapping table is created as `conf/tzmappings` on Windows Java runtime. It is derived from CLDR's `windowsZones.xml` but it uses the obsolete IANA ids for their compatibility reasons. The fix is to replace the CLDR's old ids to the latest IANA ids for those regions.
> Since it is hard to provide an automated test, as it involves the modification of the Windows' default time zone, regression test is not provided. Instead the fix is manually confirmed using the JIRA issue's example. Since this is a change in behavior, I will file a corresponding CSR/RN.
> 
> Here is the diff of the generated `conf/tzmappings` for reference:
> 
> @@ -13,7 +13,7 @@
>  Arabian Standard Time:ZZ:Etc/GMT-4:
>  Arabian Standard Time:001:Asia/Dubai:
>  Arabic Standard Time:001:Asia/Baghdad:
> -Argentina Standard Time:001:America/Buenos_Aires:
> +Argentina Standard Time:001:America/Argentina/Buenos_Aires:
>  Astrakhan Standard Time:001:Europe/Astrakhan:
>  Atlantic Standard Time:BM:Atlantic/Bermuda:
>  Atlantic Standard Time:GL:America/Thule:
> @@ -58,7 +58,7 @@
>  Central European Standard Time:MK:Europe/Skopje:
>  Central European Standard Time:001:Europe/Warsaw:
>  Central Pacific Standard Time:AQ:Antarctica/Casey:
> -Central Pacific Standard Time:FM:Pacific/Ponape:
> +Central Pacific Standard Time:FM:Pacific/Pohnpei:
>  Central Pacific Standard Time:NC:Pacific/Noumea:
>  Central Pacific Standard Time:VU:Pacific/Efate:
>  Central Pacific Standard Time:ZZ:Etc/GMT-11:
> @@ -75,7 +75,7 @@
>  Dateline Standard Time:001:Etc/GMT+12:
>  E. Africa Standard Time:AQ:Antarctica/Syowa:
>  E. Africa Standard Time:DJ:Africa/Djibouti:
> -E. Africa Standard Time:ER:Africa/Asmera:
> +E. Africa Standard Time:ER:Africa/Asmara:
>  E. Africa Standard Time:ET:Africa/Addis_Ababa:
>  E. Africa Standard Time:KM:Indian/Comoro:
>  E. Africa Standard Time:MG:Indian/Antananarivo:
> @@ -101,10 +101,10 @@
>  FLE Standard Time:FI:Europe/Helsinki:
>  FLE Standard Time:LT:Europe/Vilnius:
>  FLE Standard Time:LV:Europe/Riga:
> -FLE Standard Time:001:Europe/Kiev:
> +FLE Standard Time:001:Europe/Kyiv:
>  Fiji Standard Time:001:Pacific/Fiji:
>  GMT Standard Time:ES:Atlantic/Canary:
> -GMT Standard Time:FO:Atlantic/Faeroe:
> +GMT Standard Time:FO:Atlantic/Faroe:
>  GMT Standard Time:GG:Europe/Guernsey:
>  GMT Standard Time:IE:Europe/Dublin:
>  GMT Standard Time:IM:Europe/Isle_of_Man:
> @@ -115,7 +115,7 @@
>  GTB St...

Thank you, Justin. I addressed your suggestions

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

PR Comment: https://git.openjdk.org/jdk/pull/29591#issuecomment-3857126921

From asemenyuk at openjdk.org  Fri Feb  6 01:05:03 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 6 Feb 2026 01:05:03 GMT
Subject: RFR: 8377331: jpackage: improve sign errors reporting
Message-ID: <aMN_gHTEJE_vS1-K4OdtnVQDSouYr6C4dd-g28RVjIs=.8a86e58a-6972-46a2-a778-e01a7685bc39@github.com>

Improve reporting of errors from failed external commands, and signing errors in particular. Use the same formatting for signing errors as for any other errors.

Instead of printing:

"codesign" failed with following output:
jpackage-tests/MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: replacing existing signature
jpackage-tests/MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: bundle format unrecognized, invalid, or unsuitable
In subcomponent: jpackage-tests/MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app/Contents/foo.1
jdk.jpackage.internal.util.function.ExceptionBox: jdk.jpackage.internal.Codesign$CodesignException
        at jdk.jpackage/jdk.jpackage.internal.util.function.ExceptionBox.toUnchecked(ExceptionBox.java:51)
        <stack trace omitted>
Error: jdk.jpackage.internal.Codesign$CodesignException


jpackage will print:

Error: Unexpected exit code 1 from executing the command /usr/bin/codesign -s 'Developer ID Application: jpackage.openjdk.java.net' -vvvv --timestamp --options runtime --prefix Hello. --keychain jpackagerTest.keychain --entitlements config/AppContentWarningMacSignTest.entitlements --force MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app
Command output:
MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: replacing existing signature
MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: bundle format unrecognized, invalid, or unsuitable
In subcomponent: MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app/Contents/foo.1


As for reporting generic errors from failed external commands, jpackage will always print the command's output, regardless of whether it is running in verbose or quiet mode. Previously, it would print command output only in quiet mode, assuming that in verbose mode, the output would be printed immediately after command execution. However, jpackage runs some commands quietly in verbose mode; if one of them failed, the user didn't see its output. To address this problem, jpackage will print the output of the failed command in both quiet and verbose modes.

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

Commit messages:
 - MacSignTest: follow-up for the removal of the "error.tool.failed.with.output" message.
 - TKit: add convenience methods TextStreamVerifier and TextStreamVerifier.Group classes; add assertEndOfTextStream(); MacHelper: add convenience methods to SignKeyOption and SignKeyOptionWithKeychain; Add FailedCommandErrorVerifier
 - Better signing failure reporting: print failed command line, not only the name of the command and its output
 - Always print failed command output

Changes: https://git.openjdk.org/jdk/pull/29596/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29596&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377331
  Stats: 276 lines in 10 files changed: 203 ins; 33 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/29596.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29596/head:pull/29596

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

From asemenyuk at openjdk.org  Fri Feb  6 01:05:03 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 6 Feb 2026 01:05:03 GMT
Subject: RFR: 8377331: jpackage: improve sign errors reporting
In-Reply-To: <aMN_gHTEJE_vS1-K4OdtnVQDSouYr6C4dd-g28RVjIs=.8a86e58a-6972-46a2-a778-e01a7685bc39@github.com>
References: <aMN_gHTEJE_vS1-K4OdtnVQDSouYr6C4dd-g28RVjIs=.8a86e58a-6972-46a2-a778-e01a7685bc39@github.com>
Message-ID: <c9nB75GsVzXSynQnQdNj0kNqvYbUOL7dRxQs0wab8LA=.3b3b59a3-2810-44f8-9605-8fb16ea43b19@github.com>

On Thu, 5 Feb 2026 23:23:28 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Improve reporting of errors from failed external commands, and signing errors in particular. Use the same formatting for signing errors as for any other errors.
> 
> Instead of printing:
> 
> "codesign" failed with following output:
> jpackage-tests/MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: replacing existing signature
> jpackage-tests/MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: bundle format unrecognized, invalid, or unsuitable
> In subcomponent: jpackage-tests/MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app/Contents/foo.1
> jdk.jpackage.internal.util.function.ExceptionBox: jdk.jpackage.internal.Codesign$CodesignException
>         at jdk.jpackage/jdk.jpackage.internal.util.function.ExceptionBox.toUnchecked(ExceptionBox.java:51)
>         <stack trace omitted>
> Error: jdk.jpackage.internal.Codesign$CodesignException
> 
> 
> jpackage will print:
> 
> Error: Unexpected exit code 1 from executing the command /usr/bin/codesign -s 'Developer ID Application: jpackage.openjdk.java.net' -vvvv --timestamp --options runtime --prefix Hello. --keychain jpackagerTest.keychain --entitlements config/AppContentWarningMacSignTest.entitlements --force MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app
> Command output:
> MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: replacing existing signature
> MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: bundle format unrecognized, invalid, or unsuitable
> In subcomponent: MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app/Contents/foo.1
> 
> 
> As for reporting generic errors from failed external commands, jpackage will always print the command's output, regardless of whether it is running in verbose or quiet mode. Previously, it would print command output only in quiet mode, assuming that in verbose mode, the output would be printed immediately after command execution. However, jpackage runs some commands quietly in verbose mode; if one of them failed, the user didn't see its output. To address this problem, jpackage will print the output of the failed command in both quiet and verbose modes.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/29596#issuecomment-3857217861

From jbhateja at openjdk.org  Fri Feb  6 01:30:44 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 6 Feb 2026 01:30:44 GMT
Subject: Integrated: 8376187: [VectorAPI] Define new lane type constants and
 pass them to intrinsic entries
In-Reply-To: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
References: <IVt8agoIkdJj9yb7Vpn94G18pUbXsFvegMwlGlw25fM=.c4d22646-6c83-466b-a119-2ff8efacc955@github.com>
Message-ID: <0WJukZR7EjXs5mDABWXQ97Pz2O-S4u5xzRjaIxTtBwg=.a553a955-11be-4cc3-8159-11b7522efae8@github.com>

On Thu, 29 Jan 2026 07:16:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support.
> 
> Patch add new lane type constants and pass them to vector intrinsic entry points.
> 
> All existing Vector API jtreg test are passing with the patch.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

This pull request has now been integrated.

Changeset: b3130529
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b313052947dc27f23658f48165365c03c301d401
Stats:     2031 lines in 52 files changed: 466 ins; 88 del; 1477 mod

8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries

Reviewed-by: psandoz, qamai

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

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

From liach at openjdk.org  Fri Feb  6 05:16:39 2026
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Feb 2026 05:16:39 GMT
Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps
In-Reply-To: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
References: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
Message-ID: <6zAKwW8Nta3LWehc-HoWbv1jae7BBkBWKXOC0H1Kn-U=.685ddd55-33b2-4a5c-86e9-34fb318f7e97@github.com>

On Thu, 29 Jan 2026 12:40:42 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps.
> 
> Two interesting parts:
> 
> 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators.
> 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps.

The CSR will need to wait for Stuart Marks' review; unfortunately he is tied up in the new JSON API (as disclosed in babylon) development.

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

PR Comment: https://git.openjdk.org/jdk/pull/29485#issuecomment-3858032420

From duke at openjdk.org  Fri Feb  6 05:45:09 2026
From: duke at openjdk.org (Harshit470250)
Date: Fri, 6 Feb 2026 05:45:09 GMT
Subject: RFR: 8377035: [s390x] Disable JSR166 test cases which uses virtual
 threads [v2]
In-Reply-To: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
References: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
Message-ID: <UiSM3r5RcrgWM8pOA7yDk7BU6yCxi5N48vBqKVBE0oc=.beb187c2-f639-44d1-94bc-50f8589389d1@github.com>

> ReentrantReadWriteLock20Test.java is failing on s390 due to virtual threads which are not yet implemented on s390. 
> SynchronousQueue20Test.java also uses virtual thread so I am also disabling it.

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

  change to use Platform.isS390

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29555/files
  - new: https://git.openjdk.org/jdk/pull/29555/files/d25dd14d..746240a7

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

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

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

From jpai at openjdk.org  Fri Feb  6 05:58:06 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 6 Feb 2026 05:58:06 GMT
Subject: RFR: 8377035: [s390x] Disable JSR166 test cases which uses virtual
 threads [v2]
In-Reply-To: <UiSM3r5RcrgWM8pOA7yDk7BU6yCxi5N48vBqKVBE0oc=.beb187c2-f639-44d1-94bc-50f8589389d1@github.com>
References: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
 <UiSM3r5RcrgWM8pOA7yDk7BU6yCxi5N48vBqKVBE0oc=.beb187c2-f639-44d1-94bc-50f8589389d1@github.com>
Message-ID: <5t84xW8PiCsdZVd93x0cHEy9UpmMUteewwxsdPVhl2k=.5d1620a0-9741-425d-b89b-0a9373fb2cc5@github.com>

On Fri, 6 Feb 2026 05:45:09 GMT, Harshit470250 <duke at openjdk.org> wrote:

>> ReentrantReadWriteLock20Test.java is failing on s390 due to virtual threads which are not yet implemented on s390. 
>> SynchronousQueue20Test.java also uses virtual thread so I am also disabling it.
>
> Harshit470250 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change to use Platform.isS390

More out of curiosity, what is the actual failure when these tests are run on s390x? @Harshit470250  would it be possible to add the failure logs in that JBS issue?

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

PR Comment: https://git.openjdk.org/jdk/pull/29555#issuecomment-3858182707

From duke at openjdk.org  Fri Feb  6 06:08:08 2026
From: duke at openjdk.org (Harshit470250)
Date: Fri, 6 Feb 2026 06:08:08 GMT
Subject: RFR: 8377035: [s390x] Disable JSR166 test cases which uses virtual
 threads [v2]
In-Reply-To: <UiSM3r5RcrgWM8pOA7yDk7BU6yCxi5N48vBqKVBE0oc=.beb187c2-f639-44d1-94bc-50f8589389d1@github.com>
References: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
 <UiSM3r5RcrgWM8pOA7yDk7BU6yCxi5N48vBqKVBE0oc=.beb187c2-f639-44d1-94bc-50f8589389d1@github.com>
Message-ID: <-cC3hE3L9I29FjRR-QWmI9bBut1wAvjFK8lgZrcLLY4=.c9a6e3ca-7481-413a-be5b-d6f968cfe7e3@github.com>

On Fri, 6 Feb 2026 05:45:09 GMT, Harshit470250 <duke at openjdk.org> wrote:

>> ReentrantReadWriteLock20Test.java is failing on s390 due to virtual threads which are not yet implemented on s390. 
>> SynchronousQueue20Test.java also uses virtual thread so I am also disabling it.
>
> Harshit470250 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change to use Platform.isS390

`OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x000003efa8500000, 16384, 0) failed; error='Not enough space' (errno=12)`
I will add the failure logs.

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

PR Comment: https://git.openjdk.org/jdk/pull/29555#issuecomment-3858212311

From jbhateja at openjdk.org  Fri Feb  6 06:54:57 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 6 Feb 2026 06:54:57 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating broadcasted
 inputs
Message-ID: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>

Hi all,

This patch optimizes SIMD kernels making heavy use of broadcasted inputs through following reassociating ideal transformations.


 VectorOperation (VectorBroadcast INP1,  VectorBroadcast INP2) => 
                            VectorBroadcast (ScalarOpration INP1, INP2)

 VectorOperation (VectorBroadcast INP1) (VectorOperation (VectorBroadcast INP2) INP3) => 
                             VectorOperation INP3 (VectorOperation (VectorBroadcast INP1) (VectorOperation INP2))


The idea is to push broadcasts across the vector operation and replace the vector with an equivalent, cheaper scalar variant.  Currently, patch handles most common vector operations.

Following are the performance number of benchmark included with this patch on latest generation x86 targets:- 

**AMD Turin (2.1GHz)**
<img width="1122" height="355" alt="image" src="https://github.com/user-attachments/assets/3f5087bf-0e14-4c56-b0c2-3d23253bad54" />

**Intel Granite Rapids (2.1GHz)**
<img width="1105" height="325" alt="image" src="https://github.com/user-attachments/assets/c8481f86-4db2-4c4e-bd65-51542c59fe63" />



Kindly review and share your feedback.

Best Regards,
Jatin

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

Commit messages:
 - Adding JTREG testcase
 - Clanups
 - Adding a benchmark
 - Adding VectorNode::Ideal on Idealazation exit
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8358521
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8358521
 - Updates
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8358521
 - Skip optimizing predicated vector operations
 - 8358521: Optimize vector operations with broadcasted inputs

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

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

From alanb at openjdk.org  Fri Feb  6 07:23:19 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Feb 2026 07:23:19 GMT
Subject: RFR: 8377035: [s390x] Disable JSR166 test cases which uses virtual
 threads [v2]
In-Reply-To: <-cC3hE3L9I29FjRR-QWmI9bBut1wAvjFK8lgZrcLLY4=.c9a6e3ca-7481-413a-be5b-d6f968cfe7e3@github.com>
References: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
 <UiSM3r5RcrgWM8pOA7yDk7BU6yCxi5N48vBqKVBE0oc=.beb187c2-f639-44d1-94bc-50f8589389d1@github.com>
 <-cC3hE3L9I29FjRR-QWmI9bBut1wAvjFK8lgZrcLLY4=.c9a6e3ca-7481-413a-be5b-d6f968cfe7e3@github.com>
Message-ID: <SODkcRrkT9nI4dDO3pIPe8xxENiUn7nUP1JY0QjMmWc=.411445c8-29d6-43ee-9bbc-2ca600e0c55d@github.com>

On Fri, 6 Feb 2026 06:05:34 GMT, Harshit470250 <duke at openjdk.org> wrote:

> `OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x000003efa8500000, 16384, 0) failed; error='Not enough space' (errno=12)` I will add the failure logs.

ReentrantReadWriteLock20Test creates 64k virtual threads. If the s390 port doesn't have the VM continuations implementation then the fallback/alternative implementation will create a native thread to execute each virtual thread. So I assume this commit is thread stack or some other resources when create a native thread.

Should be easy to duplicate on other platforms with -XX:+UnlockExperimentalVMOptions -XX:-VMContinuations.

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

PR Comment: https://git.openjdk.org/jdk/pull/29555#issuecomment-3858476125

From dfenacci at openjdk.org  Fri Feb  6 07:44:44 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Fri, 6 Feb 2026 07:44:44 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <ILLRs0p4F_EwS1Qxnn-VCMaNpOG8qp-S06b8pWzuRfQ=.8ae1f46e-60d2-4747-bafb-96e64270caef@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <ILLRs0p4F_EwS1Qxnn-VCMaNpOG8qp-S06b8pWzuRfQ=.8ae1f46e-60d2-4747-bafb-96e64270caef@github.com>
Message-ID: <SEIKY8PZJsofFbK26THAjugLY3H4aXoqptBFOByz3Mc=.e6a98413-a506-48df-b7f3-04a26fc896ea@github.com>

On Fri, 23 Jan 2026 13:47:53 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> ## Issue
>> 
>> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
>> 
>> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
>> 
>> ## Causes
>> 
>> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
>> 
>> ## Fix
>> 
>> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
>> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
>> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
>> 
>> # Testing
>> 
>> * Tier 1-3+
>> * 2 JTReg tests added
>>   * `TestRangeCheck.java` as regression test for the reported issue
>>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion
>
> I'd like to provide some help for reviewers:
> 
> 1. [JDK-8361842] (integrated in 655dc516c22) implemented changes for `java.lang.StringCoding`
> 2. [JDK-8374210] (integrated in 7e18de137c3) reported regressions against JDK-8361842, and used as the BACKOUT issue.
> 3. [JDK-8374582] (this PR) is the REDO of JDK-8361842, plus the fix for regressions reported in JDK-8374210
> 
> That is, this PR starts with 3c466d372b7 (i.e, the revert of 7e18de137c3), and continues with the fix, which is **the interesting part, and that can be viewed by diff'ing 3c466d372b7...ff22857609d**. (ff22857609d is the last commit as of date.)
> 
> [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210
> [JDK-8374582]: https://bugs.openjdk.org/browse/JDK-8374582

Thanks a lot for your reviews @vy @chhagedorn @TobiHartmann!

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

PR Comment: https://git.openjdk.org/jdk/pull/29164#issuecomment-3858562112

From dfenacci at openjdk.org  Fri Feb  6 07:47:58 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Fri, 6 Feb 2026 07:47:58 GMT
Subject: Integrated: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
Message-ID: <RAPvCUiWJQUnfx3ZUKknSjbF-Xf-uNu-yWNjY_fEibc=.ce5bb433-f320-4595-b1cb-3498a8f0096e@github.com>

On Mon, 12 Jan 2026 10:29:39 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> ## Issue
> 
> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
> 
> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
> 
> ## Causes
> 
> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
> 
> ## Fix
> 
> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
> 
> # Testing
> 
> * Tier 1-3+
> * 2 JTReg tests added
>   * `TestRangeCheck.java` as regression test for the reported issue
>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion

This pull request has now been integrated.

Changeset: bfd5bdaf
Author:    Damon Fenacci <dfenacci at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bfd5bdaf7ffd96cf887fbbfe072414be38ee1b84
Stats:     462 lines in 36 files changed: 306 ins; 19 del; 137 mod

8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics

Co-authored-by: Volkan Yazici <vyazici at openjdk.org>
Reviewed-by: chagedorn, thartmann, vyazici

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

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

From epeter at openjdk.org  Fri Feb  6 08:05:43 2026
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 6 Feb 2026 08:05:43 GMT
Subject: RFR: 8371955: Support AVX10 floating point comparison instructions
 [v10]
In-Reply-To: <6FVuBg-wg5wBqcQy2egEckt3tP0zcYH6mg9mm0g_7xg=.23ae2d7c-c7e3-45fb-bedf-3eb48901b418@github.com>
References: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>
 <6FVuBg-wg5wBqcQy2egEckt3tP0zcYH6mg9mm0g_7xg=.23ae2d7c-c7e3-45fb-bedf-3eb48901b418@github.com>
Message-ID: <kPk24XtG7gY1skM_4p6Z3-rXLGPn_X2vffehlG0x0TU=.3305cc30-57b4-453a-9838-c38ace505439@github.com>

On Fri, 6 Feb 2026 00:03:18 GMT, Mohamed Issa <missa at openjdk.org> wrote:

>> Intel&reg; AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN.
>> 
>> Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added.
>> 
>> This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26).
>> 
>> 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java`
>> 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java`
>> 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java`
>> 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java`
>> 
>> Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths.
>> 
>> 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java`
>> 
>> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10
>
> Mohamed Issa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:
> 
>  - Merge tag 'tags/jdk-27+8' into user/missa-prime/avx10_2
>    
>    Added tag jdk-27+8 for changeset 949370ab
>  - Add double precision test to CMoveLConstants.java
>  - Merge branch 'master' into user/missa-prime/avx10_2
>  - Merge branch 'master' into user/missa-prime/avx10_2
>  - Change function names and extend IR encoding rules for CMove tests
>  - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2
>  - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2
>  - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad
>  - Also update copyright year in IREncodingPrinter.java
>  - Include apx_f in list of verified CPU features for IR encoding
>  - ... and 17 more: https://git.openjdk.org/jdk/compare/949370ab...205bcf8b

Testing passed. Only quickly sanity-checked the PR since there are already 2 approvals, looks reasonable :)

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

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28337#pullrequestreview-3761422684

From alanb at openjdk.org  Fri Feb  6 08:46:48 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Feb 2026 08:46:48 GMT
Subject: RFR: 8377313:
 java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java#id0 timeout
Message-ID: <v9v0TK7Yf1SMO7EcWkPBBwikqvJtgg8Mfk_2jqDjXaY=.3440f88e-af3f-433d-99b6-f83344435f53@github.com>

Dial down the number of iterations in the GetStackTraceALotWhenPinned.java and GetStackTraceALotWhenBlocking.java stress tests.

We have several stress tests that bash on Thread::getStackTrace while virtual threads are in transitions (mount/unmount when parking, blocking, waiting, ..). Some of these tests are running slower since JDK-8376568. Further work is required to reduce/avoid the wait in MountUnmountDisabler::disable_transition_for_one, tracked as JDK-8377312. In the mean-time, we dial down the tests.

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

Commit messages:
 - Initial commit

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

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

From ogillespie at openjdk.org  Fri Feb  6 09:20:01 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Fri, 6 Feb 2026 09:20:01 GMT
Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps
In-Reply-To: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
References: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
Message-ID: <8B8jax-GWfVsF6VE61Cu1cTZNfwTHL_qVKs3mfhvcL0=.72f5bb9d-a0aa-4b8a-b933-b7c7146715b1@github.com>

On Thu, 29 Jan 2026 12:40:42 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps.
> 
> Two interesting parts:
> 
> 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators.
> 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps.

Thanks. No rush :)

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

PR Comment: https://git.openjdk.org/jdk/pull/29485#issuecomment-3858990523

From eirbjo at openjdk.org  Fri Feb  6 09:35:06 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 6 Feb 2026 09:35:06 GMT
Subject: RFR: 8376533: Remove test dependencies on ReferenceQueue$Lock in
 preparation for JDK-8376477
In-Reply-To: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com>
References: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com>
Message-ID: <gXKjSlAM-8Q0uKlYpPAK6VcOkYcodTnpAOYxCtP200U=.7dda7139-10ae-43cf-b163-694e31d28c3a@github.com>

On Tue, 27 Jan 2026 21:11:05 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which updates a few JDK tests to not depend on the existence of `java.lang.ref.ReferenceQueue$Lock` and `java.lang.Shutdown$Lock` classes. These are suggested for removal in JDK-8376477, see #29442.
> 
> * `ClhsdbInspect` is updated to use add a nested Lock class in the sample app and use that instead.
> * `ConcurrentAssociateTest` and `Phaser/Basic` are updated to not use lock name when filtering threads to dump for debugging purposes when failing.
> * `ImageReaderBenchmark` micro is updated to remove these classes from the list of expected system image resource names
> 
> I have verified that these tests now run with or without the `Lock` classes present in the JDK. I called the thread dump debug methods manually to verify them since these only run on test failure. GHA run passes.
> 
> Test only change/cleanup. `noreg-self`

Friendly reminder that this test-only PR is looking for a reviewer in the servicability area.

Specifically, we need someone to look at `test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java` and verify that it's okay to use a custom nested class in the test app instead of relying on JDK internals in `ReferenceQueue`.

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

PR Comment: https://git.openjdk.org/jdk/pull/29455#issuecomment-3859095577

From jpai at openjdk.org  Fri Feb  6 09:46:52 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 6 Feb 2026 09:46:52 GMT
Subject: RFR: 8377313:
 java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java#id0 timeout
In-Reply-To: <v9v0TK7Yf1SMO7EcWkPBBwikqvJtgg8Mfk_2jqDjXaY=.3440f88e-af3f-433d-99b6-f83344435f53@github.com>
References: <v9v0TK7Yf1SMO7EcWkPBBwikqvJtgg8Mfk_2jqDjXaY=.3440f88e-af3f-433d-99b6-f83344435f53@github.com>
Message-ID: <zC7S61gBUZJpFiROemexCc1KJUkwieNRztLl6dbAk6M=.a81e9c3d-4220-4caf-9847-cbeb0fdbfef4@github.com>

On Fri, 6 Feb 2026 08:40:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Dial down the number of iterations in the GetStackTraceALotWhenPinned.java and GetStackTraceALotWhenBlocking.java stress tests.
> 
> We have several stress tests that bash on Thread::getStackTrace while virtual threads are in transitions (mount/unmount when parking, blocking, waiting, ..). Some of these tests are running slower since JDK-8376568. Further work is required to reduce/avoid the wait in MountUnmountDisabler::disable_transition_for_one, tracked as JDK-8377312. In the mean-time, we dial down the tests.

This looks OK to me. Would `GetStackTraceALotWithTimedWait` need a simlar change in its test defintion and at:


int iterations = args.length > 0 ? Integer.parseInt(args[0]) : 100_000;

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29598#pullrequestreview-3761900656

From jbhateja at openjdk.org  Fri Feb  6 09:51:16 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 6 Feb 2026 09:51:16 GMT
Subject: RFR: 8376794: Enable copy and mismatch Partial Inlining for AMD
 AVX512 targets
In-Reply-To: <LIdQi9c0pTKY9GZJoZVnpKC7DRYZYaATzujDQTPSyvY=.b0d8ee2f-bc7b-4174-b7f4-6e3cddc4721d@github.com>
References: <LIdQi9c0pTKY9GZJoZVnpKC7DRYZYaATzujDQTPSyvY=.b0d8ee2f-bc7b-4174-b7f4-6e3cddc4721d@github.com>
Message-ID: <MaEALSlEOe2FtVMxs1TyEM9zm4kjvPqOQh03rrVQgGc=.83896f59-c05d-49d4-b47f-fe6ede8e450e@github.com>

On Mon, 2 Feb 2026 10:37:16 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Partial in-lining handles copy and mismatch for small array sizes less than -XX:ArrayOperationPartialInlineSize bytes through JIT code rather than calling optimized stubs thereby saving costly call overhead.
> 
> Enabling partial in-lining optimization for AMD EPYC servers supporting AVX-512 feature.
> 
> Following are the performance numbers on Turin at fixed frequency of 2.1GHz
> 
> <img width="440" height="440" alt="image" src="https://github.com/user-attachments/assets/14b55ee3-b65c-4247-8739-67f1b94dceb4" />
> <img width="440" height="300" alt="image" src="https://github.com/user-attachments/assets/c00d6443-45a2-4277-961d-580ceea5da88" />
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Hi @sviswa7, @TobiHartmann , can you kindly review this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/29519#issuecomment-3859197682

From alanb at openjdk.org  Fri Feb  6 09:57:50 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Feb 2026 09:57:50 GMT
Subject: RFR: 8377313:
 java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java#id0 timeout
In-Reply-To: <zC7S61gBUZJpFiROemexCc1KJUkwieNRztLl6dbAk6M=.a81e9c3d-4220-4caf-9847-cbeb0fdbfef4@github.com>
References: <v9v0TK7Yf1SMO7EcWkPBBwikqvJtgg8Mfk_2jqDjXaY=.3440f88e-af3f-433d-99b6-f83344435f53@github.com>
 <zC7S61gBUZJpFiROemexCc1KJUkwieNRztLl6dbAk6M=.a81e9c3d-4220-4caf-9847-cbeb0fdbfef4@github.com>
Message-ID: <NKCuWIOgKcyr_pcEZ1l9SYiCUegRcXkboRzfcy56C1o=.64d0a5ec-b78b-4579-874f-403917675f23@github.com>

On Fri, 6 Feb 2026 09:44:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This looks OK to me. Would `GetStackTraceALotWithTimedWait` need a simlar change 

Thanks for asking. The target threads in that test spend most of their time in timed-Obejct.wait so they are mostly unmounted and not in transitions.

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

PR Comment: https://git.openjdk.org/jdk/pull/29598#issuecomment-3859244825

From mcimadamore at openjdk.org  Fri Feb  6 10:06:07 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Feb 2026 10:06:07 GMT
Subject: RFR: 8377245: AbstractMemorySegmentImpl#getString with length
 should be @ForceInline
In-Reply-To: <gvLsEyIsYlOV1SFxFRkAgoKzqQBedErupUudjZr-JTU=.8ac2bb73-adbd-43bb-bcf4-4e1cfa6404ae@github.com>
References: <gvLsEyIsYlOV1SFxFRkAgoKzqQBedErupUudjZr-JTU=.8ac2bb73-adbd-43bb-bcf4-4e1cfa6404ae@github.com>
Message-ID: <16wIRRDR_q3L8DaD-0fpEB9JLEt-VO026OrL773co2w=.c03f5dc9-932a-4f6e-8547-1e74b5a4c949@github.com>

On Thu, 5 Feb 2026 13:59:50 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Please consider this change to add `@ForceInline` to the `MemorySegment#getString` overload added in JDK-8369564. The other pre-existing `#getString` methods already have `@ForceInline` annotations.

No objections from me

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29586#pullrequestreview-3762026580

From snazy at snazy.de  Fri Feb  6 10:08:17 2026
From: snazy at snazy.de (Robert Stupp)
Date: Fri, 6 Feb 2026 11:08:17 +0100
Subject: InetAddress.get*() vs RFC 6724
Message-ID: <CAM_p_fu8ySUjQiMOW4+obS++DTV9d5iwKLbCQAYm+T2oqwsj6A@mail.gmail.com>

Hi all,

I wanted to test for the appetite to change the current default behavior of
the IP address lookup policy on dual-stack (IPv4+IPv6) systems.

The default evaluated in InetAddress.initializePlatformLookupPolicy()
yields 'IPV4_FIRST' to return IPv4 addresses before IPv6 addresses unless
'java.net.preferIPv6Addresses' is set to 'true'. I wonder whether this
could be changed to the system default, relying on what 'getaddrinfo'
returns?

This would make Java compliant with RFC 6724, which (strongly) recommends
to yield IPv6 addresses first.

Naively speaking, it can be confusing if something like 'curl' or 'wget'
connect via IPv6, but any Java application connects via IPv4.

Although it's a tiny code change, it would be a "big" or "surprising"
behavior change. Therefore I think, if there's appetite for such a change,
it would need to go into one of the next major releases.

WDYT?

Cheers,
Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260206/1e24de09/attachment-0001.htm>

From alan.bateman at oracle.com  Fri Feb  6 10:45:43 2026
From: alan.bateman at oracle.com (Alan Bateman)
Date: Fri, 6 Feb 2026 10:45:43 +0000
Subject: InetAddress.get*() vs RFC 6724
In-Reply-To: <CAM_p_fu8ySUjQiMOW4+obS++DTV9d5iwKLbCQAYm+T2oqwsj6A@mail.gmail.com>
References: <CAM_p_fu8ySUjQiMOW4+obS++DTV9d5iwKLbCQAYm+T2oqwsj6A@mail.gmail.com>
Message-ID: <33a7b1d1-259c-4c03-b33d-f94b90fbfa7e@oracle.com>

On 06/02/2026 10:08, Robert Stupp wrote:
> Hi all,
>
> I wanted to test for the appetite to change the current default 
> behavior of the IP address lookup policy on dual-stack (IPv4+IPv6) 
> systems.
>
> The default evaluated in InetAddress.initializePlatformLookupPolicy() 
> yields 'IPV4_FIRST' to return IPv4 addresses before IPv6 addresses 
> unless 'java.net.preferIPv6Addresses' is set to 'true'. I wonder 
> whether this could be changed to the system default, relying on what 
> 'getaddrinfo' returns?
>
> This would make Java compliant with RFC 6724, which (strongly) 
> recommends to yield IPv6 addresses first.
>
> Naively speaking, it can be confusing if something like 'curl' or 
> 'wget' connect via IPv6, but any Java application connects via IPv4.
>
> Although it's a tiny code change, it would be a "big" or "surprising" 
> behavior change. Therefore I think, if there's appetite for such a 
> change, it would need to go into one of the next major releases.
>
> WDYT?
>

Moving to net-dev as that is where the networking APIs are maintained.

As an initial comment, changing the JDK to prefer IPv6 addresses by 
default would be a significant and observable change. TBH, I don't see 
this being changed without a wide survey of configurations and a JEP 
that lays out the case and implications of the change.

Is your motive for asking solely because curl/wget tools prefer IPv6? 
I'm wondering if there is more to the question, maybe HTTP protocol 
handler or client only using the first address?

-Alan




From cushon at openjdk.org  Fri Feb  6 10:46:05 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 6 Feb 2026 10:46:05 GMT
Subject: Integrated: 8377245: AbstractMemorySegmentImpl#getString with length
 should be @ForceInline
In-Reply-To: <gvLsEyIsYlOV1SFxFRkAgoKzqQBedErupUudjZr-JTU=.8ac2bb73-adbd-43bb-bcf4-4e1cfa6404ae@github.com>
References: <gvLsEyIsYlOV1SFxFRkAgoKzqQBedErupUudjZr-JTU=.8ac2bb73-adbd-43bb-bcf4-4e1cfa6404ae@github.com>
Message-ID: <hhisIaEdmPnlOvDq3-Fej9sPXEI-2XOatR68miEE42g=.b4ca636a-dd88-4c5f-9c2c-ac916beed54e@github.com>

On Thu, 5 Feb 2026 13:59:50 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Please consider this change to add `@ForceInline` to the `MemorySegment#getString` overload added in JDK-8369564. The other pre-existing `#getString` methods already have `@ForceInline` annotations.

This pull request has now been integrated.

Changeset: cd6a7a54
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd6a7a54c5e323ec53747f76b07edb7f90e1f965
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8377245: AbstractMemorySegmentImpl#getString with length should be @ForceInline

Reviewed-by: mcimadamore

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

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

From jbhateja at openjdk.org  Fri Feb  6 11:42:31 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 6 Feb 2026 11:42:31 GMT
Subject: RFR: 8371187: [BigEndian Platforms] Vector lane reversal error
 [v5]
In-Reply-To: <61m6W7G30qJ9m3Hswa06ZJODwcxBD_-i__csHf-BMQU=.135843e1-25c7-487b-b1d8-c059c18ddfc6@github.com>
References: <qtK0j-Go95tXDYayBRnjhfvpNRVwbRgz1Q0TOBi4SWs=.53e6b13c-2f7a-4c77-bf4c-c9a3d2429d2b@github.com>
 <61m6W7G30qJ9m3Hswa06ZJODwcxBD_-i__csHf-BMQU=.135843e1-25c7-487b-b1d8-c059c18ddfc6@github.com>
Message-ID: <On8DHiwFjMJtg85iLAL0kzgTA1iieXtCDkudP1gPcZE=.0c19f90e-9cac-4d90-9995-8805f8d049ee@github.com>

On Fri, 23 Jan 2026 10:51:18 GMT, Varada M <varadam at openjdk.org> wrote:

>> This change fixes incorrect lane ordering in reinterpretation operations on big-endian platforms. When converting from wider to narrower lane types like Long to Int, Long to Short, big-endian systems produced reversed sub-lanes.
>> The patch adds a maybeSwapOnConverted() and a generic normalizeSubLanesForSpecies() shuffle builder to correct the sub-lane order based on element sizes on big-endian
>> 
>> JBS: [JDK-8371187](https://bugs.openjdk.org/browse/JDK-8371187)
>
> Varada M has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8371187: [BigEndian Platforms] Vector lane reversal error
>  - 8371187: [BigEndian Platforms] Vector lane reversal error

We have forgotten to checkin X-Vector.java.template file which contains definition of 'swapIfNeeded' 
Please address [JDK-8377355](https://bugs.openjdk.org/browse/JDK-8377355)

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

PR Comment: https://git.openjdk.org/jdk/pull/28425#issuecomment-3859952896

From cushon at openjdk.org  Fri Feb  6 12:54:32 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 6 Feb 2026 12:54:32 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
Message-ID: <dOFgmjEL-NFRJaONRGus8VdLBtd1iya_NrvjU7CUcas=.914b9ef0-ebbe-467e-8db1-4c5dacd0aa85@github.com>

On Fri, 30 Jan 2026 15:56:20 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background.
>> 
>> ---
>> 
>> 
>> Benchmark                              (encoding)  (stringLength)   Mode  Cnt          Score          Error  Units
>> StringLoopJmhBenchmark.getBytes             ASCII              10  thrpt    5  406782650.595 ? 16960032.852  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII             100  thrpt    5  172936926.189 ?  4532029.201  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII            1000  thrpt    5   38830681.232 ?  2413274.766  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII          100000  thrpt    5     458881.155 ?    12818.317  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1              10  thrpt    5   37193762.990 ?  3962947.391  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1             100  thrpt    5   55400876.236 ?  1267331.434  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1            1000  thrpt    5   11104514.001 ?    41718.545  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1          100000  thrpt    5     182535.414 ?    10296.120  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16              10  thrpt    5  113474681.457 ?  8326589.199  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16             100  thrpt    5   37854103.127 ?  4808526.773  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16            1000  thrpt    5    4139833.009 ?    70636.784  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16          100000  thrpt    5      57644.637 ?     1887.112  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII              10  thrpt    5  946701647.247 ? 76938927.141  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII             100  thrpt    5  396615374.479 ? 15167234.884  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII            1000  thrpt    5  100464784.979 ?   794027.897  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII          100000  thrpt    5    1215487.689 ?     1916.468  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1              10  thrpt    5  221265102.323 ? 17013983.056  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1             100  thrpt    5  137617873.887 ?  5842185.781  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1            1000  thrpt    5   92540259.1...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename getBytesLength to getByteLength

Sorry for the last minute changes here. Folks who reviewed this, do you have any feedback on the changes in https://github.com/openjdk/jdk/pull/28454#issuecomment-3824421699 or the updates to the CSR? The change is renaming `getBytesLength` to `getByteLength`, and adding more discussion to the CSR about why the return type is `int` instead of `long`.

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

PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3860279135

From jbhateja at openjdk.org  Fri Feb  6 13:20:12 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 6 Feb 2026 13:20:12 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v19]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <pfdN40GL-WKT1KI1eyfhQoGk_jdSMvilo0shbPJwvUI=.1aa20ef7-89d2-425b-9bc9-d4eaaced4874@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Adding new lane type constants for intrinsic entries, removing basictype extension changes
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Clanups
 - Refactoring vectorIntrinsics
 - Refactoring and cleanups
 - Refactoring and cleanups
 - Review comments resolutions
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Adding testpoint for JDK-8373574
 - ... and 26 more: https://git.openjdk.org/jdk/compare/2d6a1aa3...54f87337

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

Changes: https://git.openjdk.org/jdk/pull/28002/files
  Webrev: Webrev is not available because diff is too large
  Stats: 519196 lines in 211 files changed: 285007 ins; 233139 del; 1050 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

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

From eirbjo at openjdk.org  Fri Feb  6 13:51:03 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 6 Feb 2026 13:51:03 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
Message-ID: <bZkVAyMwe-LPEST1O2d_NAEkS-lwkblyHmTI3Amw3yI=.6d47d147-0e19-4e0c-a11c-1d694b3ba66c@github.com>

On Fri, 30 Jan 2026 15:56:20 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background.
>> 
>> ---
>> 
>> 
>> Benchmark                              (encoding)  (stringLength)   Mode  Cnt          Score          Error  Units
>> StringLoopJmhBenchmark.getBytes             ASCII              10  thrpt    5  406782650.595 ? 16960032.852  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII             100  thrpt    5  172936926.189 ?  4532029.201  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII            1000  thrpt    5   38830681.232 ?  2413274.766  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII          100000  thrpt    5     458881.155 ?    12818.317  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1              10  thrpt    5   37193762.990 ?  3962947.391  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1             100  thrpt    5   55400876.236 ?  1267331.434  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1            1000  thrpt    5   11104514.001 ?    41718.545  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1          100000  thrpt    5     182535.414 ?    10296.120  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16              10  thrpt    5  113474681.457 ?  8326589.199  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16             100  thrpt    5   37854103.127 ?  4808526.773  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16            1000  thrpt    5    4139833.009 ?    70636.784  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16          100000  thrpt    5      57644.637 ?     1887.112  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII              10  thrpt    5  946701647.247 ? 76938927.141  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII             100  thrpt    5  396615374.479 ? 15167234.884  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII            1000  thrpt    5  100464784.979 ?   794027.897  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII          100000  thrpt    5    1215487.689 ?     1916.468  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1              10  thrpt    5  221265102.323 ? 17013983.056  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1             100  thrpt    5  137617873.887 ?  5842185.781  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1            1000  thrpt    5   92540259.1...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename getBytesLength to getByteLength

Excuse my last minute bikeshedding, but naming in `java.util.String` is important and everlasting, so here we go:

I understand the reasoning behind `getBytesLength` / `getByteLength` aligning with the preexisting `getBytes` method. However,  when seen as an independent API name, it seems quite weak.

What is a "byte length" anyway? 8 bits? Any outsider/newcomer would need to dig into the API docs to figure out what this method does.  

Could we at least consider something with a stronger semantic expessiveness?

May we also consider that this method could lean on `length()` instead of `getBytes()` ?

What this returns is *the length in bytes of this String encoded with the given Charset*.

Was `getEncodedLength` considered?

I find it a bit revealing that the private implementation methods are named `encodedLength***`. 

So perhaps `encodedLength` could work?

I expect this method to have few "regular" users. Maybe not confusing the 99% of String users that will never need this method is more important than improving discoverability for the 1%?

If I'm right that this method will have few "regular" users, perhaps specialists could be better served finding it in `java.util.Charset`?

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

PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3860582916

From cushon at openjdk.org  Fri Feb  6 14:10:54 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 6 Feb 2026 14:10:54 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
Message-ID: <W6X3xsKv0dnGRwNdoDnwCbN-j6YZppThynETk3xZwrM=.ae99bd27-b835-4b5e-80d5-dd18bb8ccf38@github.com>

On Fri, 30 Jan 2026 15:56:20 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background.
>> 
>> ---
>> 
>> 
>> Benchmark                              (encoding)  (stringLength)   Mode  Cnt          Score          Error  Units
>> StringLoopJmhBenchmark.getBytes             ASCII              10  thrpt    5  406782650.595 ? 16960032.852  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII             100  thrpt    5  172936926.189 ?  4532029.201  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII            1000  thrpt    5   38830681.232 ?  2413274.766  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII          100000  thrpt    5     458881.155 ?    12818.317  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1              10  thrpt    5   37193762.990 ?  3962947.391  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1             100  thrpt    5   55400876.236 ?  1267331.434  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1            1000  thrpt    5   11104514.001 ?    41718.545  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1          100000  thrpt    5     182535.414 ?    10296.120  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16              10  thrpt    5  113474681.457 ?  8326589.199  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16             100  thrpt    5   37854103.127 ?  4808526.773  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16            1000  thrpt    5    4139833.009 ?    70636.784  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16          100000  thrpt    5      57644.637 ?     1887.112  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII              10  thrpt    5  946701647.247 ? 76938927.141  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII             100  thrpt    5  396615374.479 ? 15167234.884  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII            1000  thrpt    5  100464784.979 ?   794027.897  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII          100000  thrpt    5    1215487.689 ?     1916.468  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1              10  thrpt    5  221265102.323 ? 17013983.056  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1             100  thrpt    5  137617873.887 ?  5842185.781  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1            1000  thrpt    5   92540259.1...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename getBytesLength to getByteLength

Thanks for the comments,

re: `getEncodedLength` or `encodedLength`, those options where considered, although I didn't write them up as alternatives in the CSR.

The main reason `getEncodedLength` wasn't used is that it doesn't make it clear that the unit of length is bytes. For UTF-8 a byte length is intuitive, for e.g. UTF-16 or UTF-32 the "encoded length" could also be the count of int16 (number of wchar_t) or int32.

Including a `get` prefix or not was also considered, one benefit of `get` is that it aligns with `getBytes`, and also it may help convey that the method is doing computation (it's often going to be O(1), compared to e.g. `length()` which is O(1)).

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

PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3860683771

From markus at headcrashing.eu  Sun Feb  8 14:08:00 2026
From: markus at headcrashing.eu (Markus KARG)
Date: Sun, 8 Feb 2026 15:08:00 +0100
Subject: JDK-8377388 - Replacing "new StringReader(String)" by
 "Reader.of(CharSequence);" in Scanner
Message-ID: <db9b6198-d4bd-4226-91e5-ee067f13d259@headcrashing.eu>

Core-Lib Devs,

as proposed in https://bugs.openjdk.org/browse/JDK-8377388 I would like 
to replace "new StringReader(String)" by "Reader.of(CharSequence);" in 
java.util.Scanner, which seems to be safe and simple:

* There is no actual need for the synchronization found in StringReader, 
as Scanner itself is explicitly *not* synchronized, no code depends on 
StringReader in partiular, and the reader is not leaked.

Alan, Chen and Jaikiran were already active in the JIRA ticket.

I have meanwhile coded the change (see diff at 
https://github.com/mkarg/jdk/commit/03837bb46aeb4c907af0fef8063f461aceaf079a) 
and tested it successfully using OpenJDK Github Actions (see result at 
https://github.com/mkarg/jdk/actions/runs/21787869983).

Are you fine with me opening a Pull Request on Github?

Thanks!

-Markus


From chen.l.liang at oracle.com  Sun Feb  8 14:44:18 2026
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sun, 8 Feb 2026 14:44:18 +0000
Subject: JDK-8377388 - Replacing "new StringReader(String)" by
 "Reader.of(CharSequence);" in Scanner
In-Reply-To: <db9b6198-d4bd-4226-91e5-ee067f13d259@headcrashing.eu>
References: <db9b6198-d4bd-4226-91e5-ee067f13d259@headcrashing.eu>
Message-ID: <SJ2PR10MB766912FBF74DF294BF7BDB81A264A@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Mark,
I think this patch should be simple enough to prove it has no unexpected impacts.
The reader becomes the source field, which is only used in Scanner.readInput apart from closing; readInput uses buf in a non-thread-safe way, so I think it is reasonable for readInput to operate on a non-thread-safe source too.
In addition, now StringReader is just a synchronized wrapper of Reader.of. So there should be minimal impact from this change.

Regards,
Chen Liang
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Markus KARG <markus at headcrashing.eu>
Sent: Sunday, February 8, 2026 8:08 AM
To: 'core-libs-dev' <core-libs-dev at openjdk.org>
Subject: JDK-8377388 - Replacing "new StringReader(String)" by "Reader.of(CharSequence);" in Scanner

Core-Lib Devs,

as proposed in https://bugs.openjdk.org/browse/JDK-8377388 I would like
to replace "new StringReader(String)" by "Reader.of(CharSequence);" in
java.util.Scanner, which seems to be safe and simple:

* There is no actual need for the synchronization found in StringReader,
as Scanner itself is explicitly *not* synchronized, no code depends on
StringReader in partiular, and the reader is not leaked.

Alan, Chen and Jaikiran were already active in the JIRA ticket.

I have meanwhile coded the change (see diff at
https://github.com/mkarg/jdk/commit/03837bb46aeb4c907af0fef8063f461aceaf079a)
and tested it successfully using OpenJDK Github Actions (see result at
https://github.com/mkarg/jdk/actions/runs/21787869983).

Are you fine with me opening a Pull Request on Github?

Thanks!

-Markus

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

From markus at headcrashing.eu  Sun Feb  8 15:57:22 2026
From: markus at headcrashing.eu (Markus KARG)
Date: Sun, 8 Feb 2026 16:57:22 +0100
Subject: Clarification on JavaDoc Writer::append(CharSequence)
Message-ID: <c84e861d-be48-462b-985d-60293b4f0105@headcrashing.eu>

Dear Core-Lib Devs,

the JavaDocs of Writer::append(CharSequence) literally says:

 ? ? ?* <p> An invocation of this method of the form {@code out.append(csq)}
 ? ? ?* when {@code csq} is not {@code null}, behaves in exactly the 
same way
 ? ? ?* as the invocation
 ? ? ?*
 ? ? ?* {@snippet lang=java :
 ? ? ?*? ? ?out.write(csq.toString())
 ? ? ?* }
 ? ? ?* ...

I am kindly asking for an authoritative clarification how this is to be 
understood:

* (A) ONLY the particular implementation found in Writer.java MUST 
invoke "csq.toString"?

* (B) OpenJDK's OWN subclasses of Writer MUST invoke "csq.toString"?

* (C) ALL subclasses of Writer (even third-party code) MUST invoke 
"csq.toString"?

* (D) ...?...

Regards

-Markus Karg


From chen.l.liang at oracle.com  Mon Feb  9 04:06:30 2026
From: chen.l.liang at oracle.com (Chen Liang)
Date: Mon, 9 Feb 2026 04:06:30 +0000
Subject: Clarification on JavaDoc Writer::append(CharSequence)
In-Reply-To: <c84e861d-be48-462b-985d-60293b4f0105@headcrashing.eu>
References: <c84e861d-be48-462b-985d-60293b4f0105@headcrashing.eu>
Message-ID: <SJ2PR10MB7669E9DF443BCB24253E0574A265A@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Markus,
A piece of API specification in the Javadoc form applies to both callers and all implementations of a particular method. So here, (C) out of your options.

There are @apiNote, @implSpec, and @implNote Javadoc block tags that indicates the scope of their text. For example, the implSpec tag applies to an immediate class/method, so were this documentation in an @implSpec tag, it would have been (A) out of the options.

Meanwhile, the two note tags have the same scope (apiNote for all implementation, implNote for particular implementation) as the corresponding specs, but they are not binding and are just for informative purposes, and their updates do not require CSR reviews.

The scope you described in (B) is a valid scope too; I did a regex search "reference\s+implementation", case-insensitive, and found that most of these descriptions are in @implNote tags.

Regards,
Chen Liang
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Markus KARG <markus at headcrashing.eu>
Sent: Sunday, February 8, 2026 9:57 AM
To: 'core-libs-dev' <core-libs-dev at openjdk.org>
Subject: Clarification on JavaDoc Writer::append(CharSequence)

Dear Core-Lib Devs,

the JavaDocs of Writer::append(CharSequence) literally says:

      * <p> An invocation of this method of the form {@code out.append(csq)}
      * when {@code csq} is not {@code null}, behaves in exactly the
same way
      * as the invocation
      *
      * {@snippet lang=java :
      *     out.write(csq.toString())
      * }
      * ...

I am kindly asking for an authoritative clarification how this is to be
understood:

* (A) ONLY the particular implementation found in Writer.java MUST
invoke "csq.toString"?

* (B) OpenJDK's OWN subclasses of Writer MUST invoke "csq.toString"?

* (C) ALL subclasses of Writer (even third-party code) MUST invoke
"csq.toString"?

* (D) ...?...

Regards

-Markus Karg

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

From alan.bateman at oracle.com  Mon Feb  9 08:11:54 2026
From: alan.bateman at oracle.com (Alan Bateman)
Date: Mon, 9 Feb 2026 08:11:54 +0000
Subject: JDK-8377388 - Replacing "new StringReader(String)" by
 "Reader.of(CharSequence);" in Scanner
In-Reply-To: <db9b6198-d4bd-4226-91e5-ee067f13d259@headcrashing.eu>
References: <db9b6198-d4bd-4226-91e5-ee067f13d259@headcrashing.eu>
Message-ID: <890773d8-8a7a-40ab-8e49-7ec3a0dae2e7@oracle.com>

On 08/02/2026 14:08, Markus KARG wrote:
> Core-Lib Devs,
>
> as proposed in https://bugs.openjdk.org/browse/JDK-8377388 I would 
> like to replace "new StringReader(String)" by 
> "Reader.of(CharSequence);" in java.util.Scanner, which seems to be 
> safe and simple:
>
> * There is no actual need for the synchronization found in 
> StringReader, as Scanner itself is explicitly *not* synchronized, no 
> code depends on StringReader in partiular, and the reader is not leaked.

Async close is one area where StringReader and the Reader returned by 
Reader.of(cs) have different behavior. At the same time Scanner is 
specified to not be thread safe. So on the surface, I think it should be 
okay, and anything relying on concurrent usage or async close of a 
Scanner may already broken if it doesn't use external synchronization. I 
think the compatibility impact for the CSR will be low.

-Alan

From markus at headcrashing.eu  Mon Feb  9 12:02:22 2026
From: markus at headcrashing.eu (Markus KARG)
Date: Mon, 9 Feb 2026 13:02:22 +0100
Subject: Clarification on JavaDoc Writer::append(CharSequence)
In-Reply-To: <SJ2PR10MB7669E9DF443BCB24253E0574A265A@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <c84e861d-be48-462b-985d-60293b4f0105@headcrashing.eu>
 <SJ2PR10MB7669E9DF443BCB24253E0574A265A@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <c928800c-3549-4459-a664-daffa9bb382a@headcrashing.eu>

Chen,


thank you very much for your elaborate answer. Unfortunately it is not 
finally answering my actual question.


First of all, unfortunately, the wording is ambiguous: You wrote "...and 
all implementations", but then go on with "(C) out" - but (C) was the 
SOLE case about ALL implementations, so this is yes and no in the same line.


Second, you elaborate about @apiNote, @implSpec, and @implNote, but 
NEITHER of them is used in the mentioned JavaDocs location. Maybe you 
missed that my question is EXACTLY about that particular JavaDoc 
location BECAUSE those markers are missing?


Third, I need an AUTHORITATIVE and UNAMBIGUOUS answer, and your wording 
sounds more like an opinion.


Hence, kindly asking once more for a clear and authoritative answer: Is 
it (A), (B) or (C) for Writer::append(CharSequence)?


Thanks!

-Markus



Am 09.02.2026 um 05:06 schrieb Chen Liang:
> Hi Markus,
> A piece of API specification in the Javadoc form applies to both 
> callers and all implementations of a particular method. So here, (C) 
> out of your options.
>
> There are @apiNote, @implSpec, and @implNote Javadoc block tags that 
> indicates the scope of their text. For example, the implSpec tag 
> applies to an immediate class/method, so were this documentation in an 
> @implSpec tag, it would have been (A) out of the options.
>
> Meanwhile, the two note tags have the same scope (apiNote for all 
> implementation, implNote for particular implementation) as the 
> corresponding specs, but they are not binding and are just for 
> informative purposes, and their updates do not require CSR reviews.
>
> The scope you described in (B) is a valid scope too; I did a regex 
> search "reference\s+implementation", case-insensitive, and found that 
> most of these descriptions are in @implNote tags.
>
> Regards,
> Chen Liang
> ------------------------------------------------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of 
> Markus KARG <markus at headcrashing.eu>
> *Sent:* Sunday, February 8, 2026 9:57 AM
> *To:* 'core-libs-dev' <core-libs-dev at openjdk.org>
> *Subject:* Clarification on JavaDoc Writer::append(CharSequence)
> Dear Core-Lib Devs,
>
> the JavaDocs of Writer::append(CharSequence) literally says:
>
> ?? ? ?* <p> An invocation of this method of the form {@code 
> out.append(csq)}
> ?? ? ?* when {@code csq} is not {@code null}, behaves in exactly the
> same way
> ?? ? ?* as the invocation
> ?? ? ?*
> ?? ? ?* {@snippet lang=java :
> ?? ? ?*? ? ?out.write(csq.toString())
> ?? ? ?* }
> ?? ? ?* ...
>
> I am kindly asking for an authoritative clarification how this is to be
> understood:
>
> * (A) ONLY the particular implementation found in Writer.java MUST
> invoke "csq.toString"?
>
> * (B) OpenJDK's OWN subclasses of Writer MUST invoke "csq.toString"?
>
> * (C) ALL subclasses of Writer (even third-party code) MUST invoke
> "csq.toString"?
>
> * (D) ...?...
>
> Regards
>
> -Markus Karg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260209/9f62d83c/attachment.htm>

From markus at headcrashing.eu  Mon Feb  9 12:08:48 2026
From: markus at headcrashing.eu (Markus KARG)
Date: Mon, 9 Feb 2026 13:08:48 +0100
Subject: JDK-8377388 - Replacing "new StringReader(String)" by
 "Reader.of(CharSequence);" in Scanner
In-Reply-To: <890773d8-8a7a-40ab-8e49-7ec3a0dae2e7@oracle.com>
References: <db9b6198-d4bd-4226-91e5-ee067f13d259@headcrashing.eu>
 <890773d8-8a7a-40ab-8e49-7ec3a0dae2e7@oracle.com>
Message-ID: <e54016f8-775a-4255-9e43-4c011dbc4074@headcrashing.eu>

Thank you, Alan and Chen!

As two committers affirmed, I now have opened the pull request: 
https://github.com/openjdk/jdk/pull/29627

Kindly inviting everybody to review it.

Regards

-Markus

Am 09.02.2026 um 09:11 schrieb Alan Bateman:
> On 08/02/2026 14:08, Markus KARG wrote:
>> Core-Lib Devs,
>>
>> as proposed in https://bugs.openjdk.org/browse/JDK-8377388 I would 
>> like to replace "new StringReader(String)" by 
>> "Reader.of(CharSequence);" in java.util.Scanner, which seems to be 
>> safe and simple:
>>
>> * There is no actual need for the synchronization found in 
>> StringReader, as Scanner itself is explicitly *not* synchronized, no 
>> code depends on StringReader in partiular, and the reader is not leaked.
>
> Async close is one area where StringReader and the Reader returned by 
> Reader.of(cs) have different behavior. At the same time Scanner is 
> specified to not be thread safe. So on the surface, I think it should 
> be okay, and anything relying on concurrent usage or async close of a 
> Scanner may already broken if it doesn't use external synchronization. 
> I think the compatibility impact for the CSR will be low.
>
> -Alan

From chen.l.liang at oracle.com  Mon Feb  9 13:04:56 2026
From: chen.l.liang at oracle.com (Chen Liang)
Date: Mon, 9 Feb 2026 13:04:56 +0000
Subject: [External] : Re: Clarification on JavaDoc
 Writer::append(CharSequence)
In-Reply-To: <c928800c-3549-4459-a664-daffa9bb382a@headcrashing.eu>
References: <c84e861d-be48-462b-985d-60293b4f0105@headcrashing.eu>
 <SJ2PR10MB7669E9DF443BCB24253E0574A265A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <c928800c-3549-4459-a664-daffa9bb382a@headcrashing.eu>
Message-ID: <CH3PR10MB76778137999D3A783C729E9CA265A@CH3PR10MB7677.namprd10.prod.outlook.com>

C.
________________________________
From: Markus KARG <markus at headcrashing.eu>
Sent: Monday, February 9, 2026 6:02:22 AM
To: Chen Liang <chen.l.liang at oracle.com>; 'core-libs-dev' <core-libs-dev at openjdk.org>
Subject: [External] : Re: Clarification on JavaDoc Writer::append(CharSequence)


Chen,


thank you very much for your elaborate answer. Unfortunately it is not finally answering my actual question.


First of all, unfortunately, the wording is ambiguous: You wrote "...and all implementations", but then go on with "(C) out" - but (C) was the SOLE case about ALL implementations, so this is yes and no in the same line.


Second, you elaborate about @apiNote, @implSpec, and @implNote, but NEITHER of them is used in the mentioned JavaDocs location. Maybe you missed that my question is EXACTLY about that particular JavaDoc location BECAUSE those markers are missing?


Third, I need an AUTHORITATIVE and UNAMBIGUOUS answer, and your wording sounds more like an opinion.


Hence, kindly asking once more for a clear and authoritative answer: Is it (A), (B) or (C) for Writer::append(CharSequence)?


Thanks!

-Markus



Am 09.02.2026 um 05:06 schrieb Chen Liang:
Hi Markus,
A piece of API specification in the Javadoc form applies to both callers and all implementations of a particular method. So here, (C) out of your options.

There are @apiNote, @implSpec, and @implNote Javadoc block tags that indicates the scope of their text. For example, the implSpec tag applies to an immediate class/method, so were this documentation in an @implSpec tag, it would have been (A) out of the options.

Meanwhile, the two note tags have the same scope (apiNote for all implementation, implNote for particular implementation) as the corresponding specs, but they are not binding and are just for informative purposes, and their updates do not require CSR reviews.

The scope you described in (B) is a valid scope too; I did a regex search "reference\s+implementation", case-insensitive, and found that most of these descriptions are in @implNote tags.

Regards,
Chen Liang
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org><mailto:core-libs-dev-retn at openjdk.org> on behalf of Markus KARG <markus at headcrashing.eu><mailto:markus at headcrashing.eu>
Sent: Sunday, February 8, 2026 9:57 AM
To: 'core-libs-dev' <core-libs-dev at openjdk.org><mailto:core-libs-dev at openjdk.org>
Subject: Clarification on JavaDoc Writer::append(CharSequence)

Dear Core-Lib Devs,

the JavaDocs of Writer::append(CharSequence) literally says:

      * <p> An invocation of this method of the form {@code out.append(csq)}
      * when {@code csq} is not {@code null}, behaves in exactly the
same way
      * as the invocation
      *
      * {@snippet lang=java :
      *     out.write(csq.toString())
      * }
      * ...

I am kindly asking for an authoritative clarification how this is to be
understood:

* (A) ONLY the particular implementation found in Writer.java MUST
invoke "csq.toString"?

* (B) OpenJDK's OWN subclasses of Writer MUST invoke "csq.toString"?

* (C) ALL subclasses of Writer (even third-party code) MUST invoke
"csq.toString"?

* (D) ...?...

Regards

-Markus Karg

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

From alan.bateman at oracle.com  Mon Feb  9 13:22:48 2026
From: alan.bateman at oracle.com (Alan Bateman)
Date: Mon, 9 Feb 2026 13:22:48 +0000
Subject: Clarification on JavaDoc Writer::append(CharSequence)
In-Reply-To: <c84e861d-be48-462b-985d-60293b4f0105@headcrashing.eu>
References: <c84e861d-be48-462b-985d-60293b4f0105@headcrashing.eu>
Message-ID: <434d8551-2fa1-4d55-b349-86edf24bd9c8@oracle.com>



On 08/02/2026 15:57, Markus KARG wrote:
> Dear Core-Lib Devs,
>
> the JavaDocs of Writer::append(CharSequence) literally says:
>
> ? ? ?* <p> An invocation of this method of the form {@code 
> out.append(csq)}
> ? ? ?* when {@code csq} is not {@code null}, behaves in exactly the 
> same way
> ? ? ?* as the invocation
> ? ? ?*
> ? ? ?* {@snippet lang=java :
> ? ? ?*? ? ?out.write(csq.toString())
> ? ? ?* }
> ? ? ?* ...
>
> I am kindly asking for an authoritative clarification how this is to 
> be understood:
>
> * (A) ONLY the particular implementation found in Writer.java MUST 
> invoke "csq.toString"?
>
> * (B) OpenJDK's OWN subclasses of Writer MUST invoke "csq.toString"?
>
> * (C) ALL subclasses of Writer (even third-party code) MUST invoke 
> "csq.toString"?
>
> * (D) ...?...

It just means that out.append(csq) and out.write(csq.toString()) are 
equivalent when csq is not null. It does not mean that every 
implementation must invoke csq.toString(). Writer.nullWriter is the 
extreme in that it can ignore csq. With specs like this then implicit 
assumption that the toString doesn't have observable side effects.

-Alan

From jlu at openjdk.org  Mon Feb  9 21:20:09 2026
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 9 Feb 2026 21:20:09 GMT
Subject: RFR: 8377013: TimeZone.getDefault() returns obsolete id on Windows
 (Asia/Calcutta) [v2]
In-Reply-To: <FzZY6RBGXd2YYTBcQR9Idz3WO_aXVor0_auv8zKUgvE=.646923cb-8a2a-4611-b526-9c2b6b351203@github.com>
References: <PMPp8Dq_aPJspR1mTJWBnZOvlsl_aRxf69oYFVSgK1I=.347739c4-b0f9-4d6f-82bc-55d5c356d798@github.com>
 <FzZY6RBGXd2YYTBcQR9Idz3WO_aXVor0_auv8zKUgvE=.646923cb-8a2a-4611-b526-9c2b6b351203@github.com>
Message-ID: <OsIR6ZXpTHvdHEJCtMwCFhYmG89nPNZGGvNjxO2pn8o=.0b883a7b-6305-4795-bc05-d62ba0148c09@github.com>

On Fri, 6 Feb 2026 00:32:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing the Windows default time zones returned from `TimeZone.getDefault()` for some regions. On Windows, it uses their own regions for time zones that aren't 1-1 match to IANA's TZ database. Thus a mapping table is created as `conf/tzmappings` on Windows Java runtime. It is derived from CLDR's `windowsZones.xml` but it uses the obsolete IANA ids for their compatibility reasons. The fix is to replace the CLDR's old ids to the latest IANA ids for those regions.
>> Since it is hard to provide an automated test, as it involves the modification of the Windows' default time zone, regression test is not provided. Instead the fix is manually confirmed using the JIRA issue's example. Since this is a change in behavior, I will file a corresponding CSR/RN.
>> 
>> Here is the diff of the generated `conf/tzmappings` for reference:
>> 
>> @@ -13,7 +13,7 @@
>>  Arabian Standard Time:ZZ:Etc/GMT-4:
>>  Arabian Standard Time:001:Asia/Dubai:
>>  Arabic Standard Time:001:Asia/Baghdad:
>> -Argentina Standard Time:001:America/Buenos_Aires:
>> +Argentina Standard Time:001:America/Argentina/Buenos_Aires:
>>  Astrakhan Standard Time:001:Europe/Astrakhan:
>>  Atlantic Standard Time:BM:Atlantic/Bermuda:
>>  Atlantic Standard Time:GL:America/Thule:
>> @@ -58,7 +58,7 @@
>>  Central European Standard Time:MK:Europe/Skopje:
>>  Central European Standard Time:001:Europe/Warsaw:
>>  Central Pacific Standard Time:AQ:Antarctica/Casey:
>> -Central Pacific Standard Time:FM:Pacific/Ponape:
>> +Central Pacific Standard Time:FM:Pacific/Pohnpei:
>>  Central Pacific Standard Time:NC:Pacific/Noumea:
>>  Central Pacific Standard Time:VU:Pacific/Efate:
>>  Central Pacific Standard Time:ZZ:Etc/GMT-11:
>> @@ -75,7 +75,7 @@
>>  Dateline Standard Time:001:Etc/GMT+12:
>>  E. Africa Standard Time:AQ:Antarctica/Syowa:
>>  E. Africa Standard Time:DJ:Africa/Djibouti:
>> -E. Africa Standard Time:ER:Africa/Asmera:
>> +E. Africa Standard Time:ER:Africa/Asmara:
>>  E. Africa Standard Time:ET:Africa/Addis_Ababa:
>>  E. Africa Standard Time:KM:Indian/Comoro:
>>  E. Africa Standard Time:MG:Indian/Antananarivo:
>> @@ -101,10 +101,10 @@
>>  FLE Standard Time:FI:Europe/Helsinki:
>>  FLE Standard Time:LT:Europe/Vilnius:
>>  FLE Standard Time:LV:Europe/Riga:
>> -FLE Standard Time:001:Europe/Kiev:
>> +FLE Standard Time:001:Europe/Kyiv:
>>  Fiji Standard Time:001:Pacific/Fiji:
>>  GMT Standard Time:ES:Atlantic/Canary:
>> -GMT Standard Time:FO:Atlantic/Faeroe:
>> +GMT Standard Time:FO:Atlantic/Faroe:
>>  GMT Standard Time:GG:Europe/Guernsey:
>>  GMT Standard Time...
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by jlu (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29591#pullrequestreview-3774382646

From sviswanathan at openjdk.org  Mon Feb  9 21:24:30 2026
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 9 Feb 2026 21:24:30 GMT
Subject: RFR: 8376794: Enable copy and mismatch Partial Inlining for AMD
 AVX512 targets
In-Reply-To: <LIdQi9c0pTKY9GZJoZVnpKC7DRYZYaATzujDQTPSyvY=.b0d8ee2f-bc7b-4174-b7f4-6e3cddc4721d@github.com>
References: <LIdQi9c0pTKY9GZJoZVnpKC7DRYZYaATzujDQTPSyvY=.b0d8ee2f-bc7b-4174-b7f4-6e3cddc4721d@github.com>
Message-ID: <-6CdVqRlf2pPkhmumd3J6mSCeZDeW8lUpCkvxVDUJbM=.2dea83f9-10b9-4918-9a7c-4178e1a7df92@github.com>

On Mon, 2 Feb 2026 10:37:16 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Partial in-lining handles copy and mismatch for small array sizes less than -XX:ArrayOperationPartialInlineSize bytes through JIT code rather than calling optimized stubs thereby saving costly call overhead.
> 
> Enabling partial in-lining optimization for AMD EPYC servers supporting AVX-512 feature.
> 
> Following are the performance numbers on Turin at fixed frequency of 2.1GHz
> 
> <img width="440" height="440" alt="image" src="https://github.com/user-attachments/assets/14b55ee3-b65c-4247-8739-67f1b94dceb4" />
> <img width="440" height="300" alt="image" src="https://github.com/user-attachments/assets/c00d6443-45a2-4277-961d-580ceea5da88" />
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29519#pullrequestreview-3775402009

From jbhateja at openjdk.org  Mon Feb  9 21:25:22 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 9 Feb 2026 21:25:22 GMT
Subject: RFR: 8377438: [VectorAPI] Add new carrier type to LaneType class
Message-ID: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>

As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.

With Float16 we need to differentiate b/w vector lane element type and carrier type. while element type corresponds to exact type of lane i.e. Float16.class, carrier type corresponds to the storage type required to propagate IEEE 754 float16 values to inline expander.

Patch adds a new carrier type to existing LaneType structure and use it for following purpose.
 - To compute preferred shape of vector.
 - To allocate vector backing storage during dummy vector and iota array creation.
 - Sanity checking to ensure vector lane type is a primitive type in inline expander.

All existing Vector API jtreg test are passing with the patch.

Kindly review and share your feedback.

Best Regards,
Jatin

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

Commit messages:
 - 8377438: [VectorAPI] Add new carrier type to LaneType class

Changes: https://git.openjdk.org/jdk/pull/29629/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29629&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377438
  Stats: 318 lines in 38 files changed: 233 ins; 1 del; 84 mod
  Patch: https://git.openjdk.org/jdk/pull/29629.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29629/head:pull/29629

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

From dfuchs at openjdk.org  Mon Feb  9 21:25:48 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Feb 2026 21:25:48 GMT
Subject: RFR: 8377457: java/util/logging/ParentLoggersTest.java failed
 intermittently
Message-ID: <svnEUsJ4X3Jx0e9XbXVSvYZa4sIGS2z6CgDLLEj1uP0=.f34489e6-9b0c-4b53-a79a-e896a8c0062d@github.com>

`java/util/logging/ParentLoggersTest.java` has been observed failing intermittently - nut rarely - in the loom repo.
After inspection of the code Logger::doSetParent was found to do multiple read of the volatile `parent` field. After changing the method to do a single read the test has no longer been observed failing.

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

Commit messages:
 - 8377457: java/util/logging/ParentLoggersTest.java failed intermittently

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

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

From alanb at openjdk.org  Mon Feb  9 21:25:49 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Feb 2026 21:25:49 GMT
Subject: RFR: 8377457: java/util/logging/ParentLoggersTest.java failed
 intermittently
In-Reply-To: <svnEUsJ4X3Jx0e9XbXVSvYZa4sIGS2z6CgDLLEj1uP0=.f34489e6-9b0c-4b53-a79a-e896a8c0062d@github.com>
References: <svnEUsJ4X3Jx0e9XbXVSvYZa4sIGS2z6CgDLLEj1uP0=.f34489e6-9b0c-4b53-a79a-e896a8c0062d@github.com>
Message-ID: <JwaDgd5NerEF5FcMxnqZXGPJ8bClHAliuFgAtxJlvvo=.891fb2b3-6375-4b46-a9b0-9c2c07b3c000@github.com>

On Mon, 9 Feb 2026 10:35:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> `java/util/logging/ParentLoggersTest.java` has been observed failing intermittently - nut rarely - in the loom repo.
> After inspection of the code Logger::doSetParent was found to do multiple read of the volatile `parent` field. After changing the method to do a single read the test has no longer been observed failing.

This change has been in the loom repo since Oct 2025 and no sightings of the test failure since then. So I think changing it to read parent once is good.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29634#pullrequestreview-3772642255

From jpai at openjdk.org  Mon Feb  9 21:26:03 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 9 Feb 2026 21:26:03 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used with
 QOP auth-int against Active Directory
Message-ID: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>

Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?

The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.

When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.

When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.

Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `OutputStream` is a `BufferedOutputStream`. So the fact that `Connection` attempts to write out on a closed `OutputStream` after the `Connection` has been closed has gone unnoticed in this part of the code.

The reason why this shows up when SASL is invoked is because, in the presence of SASL, the LdapCtx code sets up a different (wrapping) `InputStream` and `OutputStream` for the `Connection` instance. Specifically, the `OutputStream` is now a `com.sun.jndi.ldap.sasl.SaslOutputStream`. If (for whatever reason) the `Connection`'s InputStream raises an IOException when reading from the `Connection`'s stream, then like before we close the `Connection` and attempt to write a "abandon request" message over a closed `OutputStream`. Turns out `SaslOutputStream.write(...)` doesn't have checks for closed state. When a `SaslOutputStream` is closed, it `null`s out the reference to a member field. That member field then gets used in `SaslOutputStream.write(...)` and results in a `NullPointerException` which propagates out of the `OutputStream.write(...)` call. Since `Connection.abandonRequest(...)` only guards and ignores the specified `IOException` from `OutputStream.write(...)`, this unexpected e
 xception gets propagated all the way to the application code.

The fix is trivial - the internal implementation in `Connection.abandonRequest(...)` must not attempt to write out on the OutputStream, if the connection is already closed. That's the fix this PR proposes. A new jtreg test has been introduced to reproduce the issue and verify the fix. All tests under `test/jdk/com/sun/jndi/ldap/` directory continue to pass after this change and tier testing is currently in progress.

Additionally, `com.sun.jndi.ldap.sasl.SaslOutputStream` could also be enhanced to throw `IOException` from `write(...)` and other related methods if the stream is closed. But that can be done as a separate task.

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

Commit messages:
 - copyright years
 - alternate fix
 - rename test
 - 8362268: NPE thrown from SASL GSSAPI impl when  TLS is  used with QOP auth-int against Active Directory
 - introduce test

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

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

From duke at openjdk.org  Mon Feb  9 21:26:03 2026
From: duke at openjdk.org (Michael Osipov)
Date: Mon, 9 Feb 2026 21:26:03 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory
In-Reply-To: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
Message-ID: <6YoZlJcNXIc6cwdRl0iViQdzO6msn-u75BUYTRw8hgA=.e1e6cfe6-a1c3-49b3-9634-7540151dc87c@github.com>

On Mon, 9 Feb 2026 14:47:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?
> 
> The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.
> 
> When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.
> 
> When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.
> 
> Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `OutputStream` is a `Bu...

Unfortunately, my credentials for that forest have been removed severa months ago and for my new forest the admins are incapable to configure LDAPS although the entire CA chain is up and running. Though, I see two problems with the change:

1. You encode the `AbandonRequest` although it is not sent, that's waste
2. The BER stream is dumped to tracefile although not request is being sent, that is wrong.

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

Changes requested by michael-o at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/29638#pullrequestreview-3774365653

From jpai at openjdk.org  Mon Feb  9 21:26:03 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 9 Feb 2026 21:26:03 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory
In-Reply-To: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
Message-ID: <TIVQcQ3OFyOpZOMBtg_5OXoI4eJD3JCqMbzpNETf05Q=.72f3b76a-f794-48dd-aa2e-1abebf129d3f@github.com>

On Mon, 9 Feb 2026 14:47:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?
> 
> The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.
> 
> When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.
> 
> When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.
> 
> Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `OutputStream` is a `Bu...

Hello Michael @michael-o, since you reported this issue, would it be possible to build the JDK with the fix in this PR and see if it addresses the issue on your setup too?

> Additionally, com.sun.jndi.ldap.sasl.SaslOutputStream could also be enhanced to throw IOException from write(...) and other related methods if the stream is closed. But that can be done as a separate task.

I've created https://bugs.openjdk.org/browse/JDK-8377486 to track this.

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

PR Comment: https://git.openjdk.org/jdk/pull/29638#issuecomment-3872211030
PR Comment: https://git.openjdk.org/jdk/pull/29638#issuecomment-3872262606

From wxiao at openjdk.org  Mon Feb  9 21:26:04 2026
From: wxiao at openjdk.org (Weibing Xiao)
Date: Mon, 9 Feb 2026 21:26:04 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory
In-Reply-To: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
Message-ID: <u8kanltZyaCNkkl1S5vVHhASWs8BXWGZlzAp1bQmikc=.9905a220-b857-4ed5-b977-0e923edcc40b@github.com>

On Mon, 9 Feb 2026 14:47:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?
> 
> The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.
> 
> When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.
> 
> When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.
> 
> Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `OutputStream` is a `Bu...

Verified the change against my code to duplicate the failure. It fixed the failure.

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

PR Comment: https://git.openjdk.org/jdk/pull/29638#issuecomment-3872789670

From dfuchs at openjdk.org  Mon Feb  9 21:26:05 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Feb 2026 21:26:05 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory
In-Reply-To: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
Message-ID: <iFuI-Zwo0mazBgA2to6WM2I1ZImt8ijErjxANN4G0Bo=.4ecacdc4-22c7-4b38-bacf-130bf1af5b35@github.com>

On Mon, 9 Feb 2026 14:47:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?
> 
> The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.
> 
> When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.
> 
> When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.
> 
> Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `OutputStream` is a `Bu...

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 554:

> 552:                     // on a (closed) stream of a connection that can no longer be used.
> 553:                     return;
> 554:                 }

I am not sure this is the right test. If I am not mistaken, this means that "abandon request" will never be sent to the server, ever, since the flag is set to false in cleanup() before abandonning requests. 
Should we instead test whether the socket output is closed here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29638#discussion_r2783554381

From jpai at openjdk.org  Mon Feb  9 21:26:07 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 9 Feb 2026 21:26:07 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory
In-Reply-To: <iFuI-Zwo0mazBgA2to6WM2I1ZImt8ijErjxANN4G0Bo=.4ecacdc4-22c7-4b38-bacf-130bf1af5b35@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
 <iFuI-Zwo0mazBgA2to6WM2I1ZImt8ijErjxANN4G0Bo=.4ecacdc4-22c7-4b38-bacf-130bf1af5b35@github.com>
Message-ID: <VWMI83VSuQfpYs_L1FiMpOJW_O5Phfrasdp1rZBNLxA=.0bb35fd4-f7b6-4754-aca4-2a1786b7198e@github.com>

On Mon, 9 Feb 2026 16:40:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?
>> 
>> The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.
>> 
>> When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.
>> 
>> When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.
>> 
>> Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `Outp...
>
> src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 554:
> 
>> 552:                     // on a (closed) stream of a connection that can no longer be used.
>> 553:                     return;
>> 554:                 }
> 
> I am not sure this is the right test. If I am not mistaken, this means that "abandon request" will never be sent to the server, ever, since the flag is set to false in cleanup() before abandonning requests. 
> Should we instead test whether the socket output is closed here?

That's a good point. Like you note, I think we will have to check a different state here instead of `!useable`. I'll update the PR tomorrow after a more closer look.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29638#discussion_r2783629638

From eirbjo at openjdk.org  Mon Feb  9 21:27:27 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 9 Feb 2026 21:27:27 GMT
Subject: RFR: 8377461: Add ZipFile test for incorrect number of entries
 reported in ENDTOT
Message-ID: <HNKqPs_z16aAUi5uScwFT9ICjbLZDGZEJOSF-kuHdNo=.249a67d7-a6c1-4991-9777-f2e8f1d85c72@github.com>

Please review this PR introducing a test to verify that `ZipFile::size` reports the actual number of CEN entries in a ZIP file, despite an incorrect number being reported in the END header.

Background:

The `ZipFile` implementation treats `ENDTOT` as an indication, but falls back to counting CEN entries if this number is too low. After parsing the CEN, there is also code to adjust the total down to the actual count of CEN entries.

The behavior of always reporting the actual number of CEN entries has no current test coverage in the JDK. It seems good to have tests excercising these code paths and protecting against regressions in this area.

Verification:

Verified that the new test catches introduced regressions in handling over- and underreported numbers in ENDTOT and that no existing test catches such regressions.

Test-only change, `noreg-self`.

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

Commit messages:
 - Also verify number of ZipFile::entries and count of ZipFile::stream.
 - Add test to verify ZipFile:size with incorrect ENDTOT fields

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

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

From duke at openjdk.org  Mon Feb  9 21:26:51 2026
From: duke at openjdk.org (Markus KARG)
Date: Mon, 9 Feb 2026 21:26:51 GMT
Subject: RFR: 8377388: Replacing "new StringReader(String)" by
 "Reader.of(CharSequence);" in Scanner
Message-ID: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>

This Pull Request provides an implementation for [JDK-8377388](https://bugs.openjdk.org/browse/JDK-8377388): 'Replacing "new StringReader(String)" by "Reader.of(CharSequence);" in Scanner'.

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

Commit messages:
 - 8377388: Replacing "new StringReader(String)" by "Reader.of(CharSequence);" in Scanner

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

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

From lancea at openjdk.org  Mon Feb  9 21:27:36 2026
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 9 Feb 2026 21:27:36 GMT
Subject: RFR: 8377461: Add ZipFile test for incorrect number of entries
 reported in ENDTOT
In-Reply-To: <HNKqPs_z16aAUi5uScwFT9ICjbLZDGZEJOSF-kuHdNo=.249a67d7-a6c1-4991-9777-f2e8f1d85c72@github.com>
References: <HNKqPs_z16aAUi5uScwFT9ICjbLZDGZEJOSF-kuHdNo=.249a67d7-a6c1-4991-9777-f2e8f1d85c72@github.com>
Message-ID: <p6Jh-wvi1qCsE6wo0jPOYEO5hgzfpMZR98mr-aYqgaU=.63f89763-7388-4f7f-be27-d5b45973aca7@github.com>

On Mon, 9 Feb 2026 12:27:31 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR introducing a test to verify that `ZipFile::size` reports the actual number of CEN entries in a ZIP file, despite an incorrect number being reported in the END header.
> 
> Background:
> 
> The `ZipFile` implementation treats `ENDTOT` as an indication, but falls back to counting CEN entries if this number is too low. After parsing the CEN, there is also code to adjust the total down to the actual count of CEN entries.
> 
> The behavior of always reporting the actual number of CEN entries has no current test coverage in the JDK. It seems good to have tests excercising these code paths and protecting against regressions in this area.
> 
> Verification:
> 
> Verified that the new test catches introduced regressions in handling over- and underreported numbers in ENDTOT and that no existing test catches such regressions.
> 
> Test-only change, `noreg-self`.

Thanks for Tackling this Eirik.

A couple minor comments below.

A follow one would be to  also check:

4.3.15 Zip64 end of central directory locator

but can be a follow on project

test/jdk/java/util/zip/ZipFile/IncorrectEndTot.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved.

I believe this is a new Test so 2026 is what we need for the copyright

test/jdk/java/util/zip/ZipFile/IncorrectEndTot.java line 60:

> 58:                 Arguments.of(10, 11), // CEN has one less than ENDTOT
> 59:                 Arguments.of(11, 10), // CEN has one more than ENDTOT
> 60:                 Arguments.of(0, 10)   // No CEN entries (empty ZIP)

Should you include Arguments.of(0, 0) to test an empty ZIP?

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

PR Review: https://git.openjdk.org/jdk/pull/29635#pullrequestreview-3774857487
PR Review Comment: https://git.openjdk.org/jdk/pull/29635#discussion_r2784113108
PR Review Comment: https://git.openjdk.org/jdk/pull/29635#discussion_r2784427229

From alanb at openjdk.org  Mon Feb  9 21:26:58 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Feb 2026 21:26:58 GMT
Subject: RFR: 8377411: java/lang/Thread/virtual/stress/ParkAfterTimedPark.java
 only testing pinned case
Message-ID: <8qZaQWwThjatuQE08vr5VRg_kA7bAjcgjAr1i-MEuDQ=.8a8e05f6-d483-428a-a3e4-65d9d4b08a95@github.com>

Recently added test java/lang/Thread/virtual/stress/ParkAfterTimedPark.java has a parameter to indicate if the target thread is pinned or not. I fat fingered the conversion of a test with the result that the "pinned" parameter is ignored and the tests unconditionally tests the pinned case, not the unpinned case.

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

Commit messages:
 - Initial commit

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

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

From jbhateja at openjdk.org  Mon Feb  9 21:28:02 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 9 Feb 2026 21:28:02 GMT
Subject: RFR: 8376186: [VectorAPI] Nomenclature change for concrete vector
 classes
Message-ID: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>

As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.

In preparation of Float16 vector API support, changes to nomenclature of concrete vector class by suffixing the vector type with vector bit sizes e.g. FloatVector256 so that we don't end up generating names like Float16256Vector.

All existing Vector API jtreg test are passing with the patch.

Kindly review and share your feedback.

Best Regards,
Jatin

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

Commit messages:
 - Removing older artifact
 - 8376186: [VectorAPI] Nomenclature change for concrete vector classes

Changes: https://git.openjdk.org/jdk/pull/29614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29614&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8376186
  Stats: 74830 lines in 130 files changed: 31372 ins; 31371 del; 12087 mod
  Patch: https://git.openjdk.org/jdk/pull/29614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29614/head:pull/29614

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

From cushon at openjdk.org  Mon Feb  9 21:29:00 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 9 Feb 2026 21:29:00 GMT
Subject: RFR: 8208752: Calling a deserialized Lambda might fail with
 ClassCastException [v5]
In-Reply-To: <XymdjugFQvrNU3zsz9KekcQ_WAEragtZv5dcGRAJjFM=.d718ce22-a12b-484d-87d1-c6e387759f2d@github.com>
References: <XymdjugFQvrNU3zsz9KekcQ_WAEragtZv5dcGRAJjFM=.d718ce22-a12b-484d-87d1-c6e387759f2d@github.com>
Message-ID: <902M4uGOH1q89__zeHdJJWzob-36TlRCRXmcchFCZ0s=.43a2b376-070f-42b3-ace3-2b0742dfe54c@github.com>

> See [JDK-8208752: Calling a deserialized Lambda might fail with ClassCastException](https://bugs.openjdk.org/browse/JDK-8208752).
> 
> Lambda deserialization currently does not consider `SerializedLambda#getInstantiatedMethodType` when deserializing lambdas, which can lead to method references that differ only in `getInstantiatedMethodType` being merged into the same lambda instance, and can result in `ClassCastException`s like the one reported in the bug.
> 
> This depends on the fix for [JDK-8374654: Inconsistent handling of lambda deserialization for Object method references on interfaces](https://bugs.openjdk.org/browse/JDK-8374654) in https://github.com/openjdk/jdk/pull/29075.

Liam Miller-Cushon 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 remote-tracking branch 'origin/master' into JDK-8208752
 - Merge branch 'JDK-8374654' into JDK-8208752
 - Test cleanup
 - Updates for --debug=dumpLambdaDeserializationStats
 - Merge branch 'JDK-8374654' into JDK-8208752
 - Use --debug=dumpLambdaDeserializationStats in test
 - Merge remote-tracking branch 'origin/master' into JDK-8374654
 - Merge branch 'JDK-8374654' into JDK-8208752
 - Only resolve object methods on interfaces
 - Update test
 - ... and 5 more: https://git.openjdk.org/jdk/compare/37b49b29...3a224b0c

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

Changes: https://git.openjdk.org/jdk/pull/28943/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28943&range=04
  Stats: 188 lines in 8 files changed: 163 ins; 0 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/28943.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28943/head:pull/28943

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

From liach at openjdk.org  Mon Feb  9 21:28:07 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Feb 2026 21:28:07 GMT
Subject: RFR: 8376186: [VectorAPI] Nomenclature change for concrete vector
 classes
In-Reply-To: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
References: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
Message-ID: <xaV6FhMy0PM-8fnVF8GLraqZwMZo9n3khqqV257AAr8=.23e69139-5204-4b48-a2f1-935c9a54a323@github.com>

On Fri, 6 Feb 2026 18:33:17 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
> 
> In preparation of Float16 vector API support, changes to nomenclature of concrete vector class by suffixing the vector type with vector bit sizes e.g. FloatVector256 so that we don't end up generating names like Float16256Vector.
> 
> All existing Vector API jtreg test are passing with the patch.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Looks good to me. Verified by:

1. Running the generators, verified the results are the same, ignoring the missing parts handled by #29616; you can integrate before that one I think.
2. Tiers 1-5 clear, only one unrelated failure from JDK-8377425.

Let another engineer confirm too.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29614#pullrequestreview-3768566495

From vromero at openjdk.org  Mon Feb  9 21:29:05 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 9 Feb 2026 21:29:05 GMT
Subject: RFR: 8208752: Calling a deserialized Lambda might fail with
 ClassCastException [v5]
In-Reply-To: <902M4uGOH1q89__zeHdJJWzob-36TlRCRXmcchFCZ0s=.43a2b376-070f-42b3-ace3-2b0742dfe54c@github.com>
References: <XymdjugFQvrNU3zsz9KekcQ_WAEragtZv5dcGRAJjFM=.d718ce22-a12b-484d-87d1-c6e387759f2d@github.com>
 <902M4uGOH1q89__zeHdJJWzob-36TlRCRXmcchFCZ0s=.43a2b376-070f-42b3-ace3-2b0742dfe54c@github.com>
Message-ID: <sBWW1HEkBzFcrmTbsMYpKXXgX9eihRKhAcenjr_kTKU=.98fbfb17-c8e5-46cf-8635-7e428aa62363@github.com>

On Mon, 9 Feb 2026 20:55:44 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> See [JDK-8208752: Calling a deserialized Lambda might fail with ClassCastException](https://bugs.openjdk.org/browse/JDK-8208752).
>> 
>> Lambda deserialization currently does not consider `SerializedLambda#getInstantiatedMethodType` when deserializing lambdas, which can lead to method references that differ only in `getInstantiatedMethodType` being merged into the same lambda instance, and can result in `ClassCastException`s like the one reported in the bug.
>> 
>> This depends on the fix for [JDK-8374654: Inconsistent handling of lambda deserialization for Object method references on interfaces](https://bugs.openjdk.org/browse/JDK-8374654) in https://github.com/openjdk/jdk/pull/29075.
>
> Liam Miller-Cushon 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 remote-tracking branch 'origin/master' into JDK-8208752
>  - Merge branch 'JDK-8374654' into JDK-8208752
>  - Test cleanup
>  - Updates for --debug=dumpLambdaDeserializationStats
>  - Merge branch 'JDK-8374654' into JDK-8208752
>  - Use --debug=dumpLambdaDeserializationStats in test
>  - Merge remote-tracking branch 'origin/master' into JDK-8374654
>  - Merge branch 'JDK-8374654' into JDK-8208752
>  - Only resolve object methods on interfaces
>  - Update test
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/37b49b29...3a224b0c

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28943#pullrequestreview-3774053614

From jbhateja at openjdk.org  Mon Feb  9 21:28:11 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 9 Feb 2026 21:28:11 GMT
Subject: RFR: 8376186: [VectorAPI] Nomenclature change for concrete vector
 classes
In-Reply-To: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
References: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
Message-ID: <UCWvurZdiFR5btKOA-fv5eDo_x8LoZomagzejTrGEZE=.98564f14-4eec-4294-b5a4-b7ae2968e3bf@github.com>

On Fri, 6 Feb 2026 18:33:17 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
> 
> In preparation of Float16 vector API support, changes to nomenclature of concrete vector class by suffixing the vector type with vector bit sizes e.g. FloatVector256 so that we don't end up generating names like Float16256Vector.
> 
> All existing Vector API jtreg test are passing with the patch.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Hi @PaulSandoz , Can you kindly be the second reviewer here, please check and approve this.

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

PR Comment: https://git.openjdk.org/jdk/pull/29614#issuecomment-3866139614

From jlahoda at openjdk.org  Mon Feb  9 21:29:10 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 9 Feb 2026 21:29:10 GMT
Subject: RFR: 8208752: Calling a deserialized Lambda might fail with
 ClassCastException [v5]
In-Reply-To: <902M4uGOH1q89__zeHdJJWzob-36TlRCRXmcchFCZ0s=.43a2b376-070f-42b3-ace3-2b0742dfe54c@github.com>
References: <XymdjugFQvrNU3zsz9KekcQ_WAEragtZv5dcGRAJjFM=.d718ce22-a12b-484d-87d1-c6e387759f2d@github.com>
 <902M4uGOH1q89__zeHdJJWzob-36TlRCRXmcchFCZ0s=.43a2b376-070f-42b3-ace3-2b0742dfe54c@github.com>
Message-ID: <0cA77Tf6rpRVhTCEXUOKXKlS0-d2JaRGDXNSnqLq0mA=.e292d6dc-7373-4fbe-99c2-2b01d97774da@github.com>

On Mon, 9 Feb 2026 20:55:44 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> See [JDK-8208752: Calling a deserialized Lambda might fail with ClassCastException](https://bugs.openjdk.org/browse/JDK-8208752).
>> 
>> Lambda deserialization currently does not consider `SerializedLambda#getInstantiatedMethodType` when deserializing lambdas, which can lead to method references that differ only in `getInstantiatedMethodType` being merged into the same lambda instance, and can result in `ClassCastException`s like the one reported in the bug.
>> 
>> This depends on the fix for [JDK-8374654: Inconsistent handling of lambda deserialization for Object method references on interfaces](https://bugs.openjdk.org/browse/JDK-8374654) in https://github.com/openjdk/jdk/pull/29075.
>
> Liam Miller-Cushon 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 remote-tracking branch 'origin/master' into JDK-8208752
>  - Merge branch 'JDK-8374654' into JDK-8208752
>  - Test cleanup
>  - Updates for --debug=dumpLambdaDeserializationStats
>  - Merge branch 'JDK-8374654' into JDK-8208752
>  - Use --debug=dumpLambdaDeserializationStats in test
>  - Merge remote-tracking branch 'origin/master' into JDK-8374654
>  - Merge branch 'JDK-8374654' into JDK-8208752
>  - Only resolve object methods on interfaces
>  - Update test
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/37b49b29...3a224b0c

LGTM.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28943#pullrequestreview-3774311246

From cushon at openjdk.org  Mon Feb  9 21:29:26 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 9 Feb 2026 21:29:26 GMT
Subject: RFR: 8208752: Calling a deserialized Lambda might fail with
 ClassCastException [v4]
In-Reply-To: <B1hO-HI5IxMDZwfA1Kcj_TudB_N1gTZcgVh3ybrnu9c=.a8b5752a-dfe6-49ad-831c-9651ccacb864@github.com>
References: <XymdjugFQvrNU3zsz9KekcQ_WAEragtZv5dcGRAJjFM=.d718ce22-a12b-484d-87d1-c6e387759f2d@github.com>
 <B1hO-HI5IxMDZwfA1Kcj_TudB_N1gTZcgVh3ybrnu9c=.a8b5752a-dfe6-49ad-831c-9651ccacb864@github.com>
Message-ID: <Wc2zPU0tZLQYaq8tJlj6MJyBXXeqJrEFd_jU6yPp0JM=.4e653052-87ca-40ef-8af0-1c63e89beb79@github.com>

On Thu, 22 Jan 2026 11:45:08 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> See [JDK-8208752: Calling a deserialized Lambda might fail with ClassCastException](https://bugs.openjdk.org/browse/JDK-8208752).
>> 
>> Lambda deserialization currently does not consider `SerializedLambda#getInstantiatedMethodType` when deserializing lambdas, which can lead to method references that differ only in `getInstantiatedMethodType` being merged into the same lambda instance, and can result in `ClassCastException`s like the one reported in the bug.
>> 
>> This depends on the fix for [JDK-8374654: Inconsistent handling of lambda deserialization for Object method references on interfaces](https://bugs.openjdk.org/browse/JDK-8374654) in https://github.com/openjdk/jdk/pull/29075.
>
> Liam Miller-Cushon 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 'JDK-8374654' into JDK-8208752
>  - Test cleanup
>  - Updates for --debug=dumpLambdaDeserializationStats
>  - Merge branch 'JDK-8374654' into JDK-8208752
>  - Merge branch 'JDK-8374654' into JDK-8208752
>  - Update test
>  - Merge branch 'JDK-8374654' into JDK-8208752
>  - Don't rely on the iteration order of Map.of entries
>  - 8208752: Calling a deserialized Lambda might fail with ClassCastException

Is there any more feedback on this, or on [CSR JDK-8376198](https://bugs.openjdk.org/browse/JDK-8376198)?

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

PR Comment: https://git.openjdk.org/jdk/pull/28943#issuecomment-3871288496

From vyazici at openjdk.org  Mon Feb  9 21:29:18 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 9 Feb 2026 21:29:18 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics
Message-ID: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>

Moves input validation checks to Java for `java.lang.StringLatin1` intrinsics. While doing so, affected `java.lang.StringUTF16` methods needed to be updated due to relaxed checks at intrinsics. The javadocs of the touched methods are extensively overhauled.

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

Commit messages:
 - More doc updates
 - Reflect that `VerifyIntrinsicChecks` is removed
 - Merge remote-tracking branch 'upstream/master' into sLatin1Intr
 - Fix `Helper`
 - Guard `equals` intrinsic
 - Cosmetic improvements
 - Guard `indexOf` intrinsics
 - Document `StringLatin1`
 - Guard `inflate`/`compress` intrinsics
 - Guard `compareTo` intrinsics

Changes: https://git.openjdk.org/jdk/pull/28832/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28832&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367129
  Stats: 554 lines in 5 files changed: 457 ins; 16 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/28832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28832/head:pull/28832

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

From vyazici at openjdk.org  Mon Feb  9 21:29:37 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 9 Feb 2026 21:29:37 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics
In-Reply-To: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
Message-ID: <QI5xxAtpYiwD2Q9XTrANOQykxo3ffvOFSICINXpTISA=.4fa6158a-c65f-4752-a8de-f363b0362e95@github.com>

On Mon, 15 Dec 2025 20:30:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Moves input validation checks to Java for `java.lang.StringLatin1` intrinsics. While doing so, affected `java.lang.StringUTF16` methods needed to be updated due to relaxed checks at intrinsics. The javadocs of the touched methods are extensively overhauled.

src/java.base/share/classes/java/lang/StringLatin1.java line 114:

> 112:     // inline_string_equals
> 113:     @IntrinsicCandidate
> 114:     private static boolean equals0(byte[] value, byte[] other) {

This intrinsic is actually identical to `Arrays::equals`, and can be removed ? I'm exploring this in #28717.

src/java.base/share/classes/java/lang/StringLatin1.java line 493:

> 491:         byte first = str[0];
> 492:         int max = (valueToIndex - strToIndex);
> 493:         for (int i = valueFromIndex; i <= max; i++) {

Note that the earlier code used `valueCount` ? the same `Count`-suffixed variables are used at the intrinsics too. Though as can be seen from these two lines, what is meant is a `ToIndex`. That is, `valueCount` does *not* denote _"the count of characters"_ after the from index, but instead it denotes _"the (exclusive) index of the last character"_. I've updated the Java code to reflect this, though I've not touched the intrinsic.

Note that the same issue (and the correction) is present in the `StringUTF16::indexOf` family too.

src/java.base/share/classes/java/lang/StringUTF16.java line 1671:

> 1669: 
> 1670:     // inflatedCopy byte[] -> byte[]
> 1671:     static void inflate(byte[] src, int srcOff, byte[] dst, int dstOff, int len) {

Moved this to `StringLatin1`, which happens to be the only caller of this method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2620787257
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2620776159
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2620792767

From eirbjo at openjdk.org  Mon Feb  9 21:30:52 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 9 Feb 2026 21:30:52 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <W6X3xsKv0dnGRwNdoDnwCbN-j6YZppThynETk3xZwrM=.ae99bd27-b835-4b5e-80d5-dd18bb8ccf38@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
 <W6X3xsKv0dnGRwNdoDnwCbN-j6YZppThynETk3xZwrM=.ae99bd27-b835-4b5e-80d5-dd18bb8ccf38@github.com>
Message-ID: <2BdASdHcWrwVR4vDUls8cwb_c3jNMRjLr1b551JsVvg=.3bb9ab66-458b-4a92-9178-b1563a3e9af2@github.com>

On Fri, 6 Feb 2026 14:08:07 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> The main reason `getEncodedLength` wasn't used is that it doesn't make it clear that the unit of length is bytes. For UTF-8 a byte length is intuitive, for e.g. UTF-16 or UTF-32 the "encoded length" could also be the count of int16 (number of wchar_t) or int32.

Emphasizing the unit of measurement is a laudable goal. I just feel that in this case it obscures what is being computed.

What?s computed here is the *encoded* length, the unit of measurement seems a secondary concern.

A String does not intrinsically have a ?byte length?, this concept seems only meaningful in relation to an encoding operation.

Was `getEncodedByteLength` considered? `getEncodedLengthInBytes`?

Was Charset considered as a home for this method? There the operational context of encoding would be obvious.

> Including a `get` prefix or not was also considered, one benefit of `get` is that it aligns with `getBytes`, and also it may help convey that the method is doing computation (it's often going to be O(1), compared to e.g. `length()` which is O(1)).

Again a laudable goal, but the actual computation seems obscure.

String is prime real estate for millions of programmers. We should get this right.

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

PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3861158061

From cushon at openjdk.org  Mon Feb  9 21:30:56 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 9 Feb 2026 21:30:56 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <2BdASdHcWrwVR4vDUls8cwb_c3jNMRjLr1b551JsVvg=.3bb9ab66-458b-4a92-9178-b1563a3e9af2@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
 <W6X3xsKv0dnGRwNdoDnwCbN-j6YZppThynETk3xZwrM=.ae99bd27-b835-4b5e-80d5-dd18bb8ccf38@github.com>
 <2BdASdHcWrwVR4vDUls8cwb_c3jNMRjLr1b551JsVvg=.3bb9ab66-458b-4a92-9178-b1563a3e9af2@github.com>
Message-ID: <p_FcqCbZJI3v6oHLm3DKQW7zgH0RVMh2O4AB6itlyUI=.945bb19c-4844-4438-bc54-8bd7f5d62dbe@github.com>

On Fri, 6 Feb 2026 15:50:24 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Was `getEncodedByteLength` considered? `getEncodedLengthInBytes`?

I think `getEncodedByteLength` and `getEncodedLengthInBytes` are both descriptive of what the method does. They seem verbose to me. In `getByteLength(Charset)`, the `Charset` provides some signal to the reader that the method is dealing with an encoded length.

> Was Charset considered as a home for this method? There the operational context of encoding would be obvious.

I don't think that was discussed. The primary motivation for adding this API is performance, I'd want to keep the fast path that optimizes using String internals, and avoid going through e.g. CharBuffer. I think it would be possible to add something to `JavaLangAccess` and have a specialized implementation of the method for the standard charsets (or their encoders) to preserve that.

> String is prime real estate for millions of programmers. We should get this right.

I agree!

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

PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3861273721

From rriggs at openjdk.org  Mon Feb  9 21:31:12 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 9 Feb 2026 21:31:12 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
Message-ID: <dcjRyp8Tw75L2Vi-Z6Sju1BTtrU1bpx-8zlVdQD21A0=.d228ab0b-6d7b-4cd2-8907-7e439ede95a0@github.com>

On Fri, 30 Jan 2026 15:56:20 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background.
>> 
>> ---
>> 
>> 
>> Benchmark                              (encoding)  (stringLength)   Mode  Cnt          Score          Error  Units
>> StringLoopJmhBenchmark.getBytes             ASCII              10  thrpt    5  406782650.595 ? 16960032.852  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII             100  thrpt    5  172936926.189 ?  4532029.201  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII            1000  thrpt    5   38830681.232 ?  2413274.766  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII          100000  thrpt    5     458881.155 ?    12818.317  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1              10  thrpt    5   37193762.990 ?  3962947.391  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1             100  thrpt    5   55400876.236 ?  1267331.434  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1            1000  thrpt    5   11104514.001 ?    41718.545  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1          100000  thrpt    5     182535.414 ?    10296.120  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16              10  thrpt    5  113474681.457 ?  8326589.199  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16             100  thrpt    5   37854103.127 ?  4808526.773  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16            1000  thrpt    5    4139833.009 ?    70636.784  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16          100000  thrpt    5      57644.637 ?     1887.112  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII              10  thrpt    5  946701647.247 ? 76938927.141  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII             100  thrpt    5  396615374.479 ? 15167234.884  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII            1000  thrpt    5  100464784.979 ?   794027.897  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII          100000  thrpt    5    1215487.689 ?     1916.468  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1              10  thrpt    5  221265102.323 ? 17013983.056  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1             100  thrpt    5  137617873.887 ?  5842185.781  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1            1000  thrpt    5   92540259.1...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename getBytesLength to getByteLength

I favored close alignment with `getBytes(CharSet).length`. As this is method is intended as a replacement for that.
The encoded form is always bytes, so I don't think 'byte' needs to be in the name.

I'd be fine with `getEncodedLength(Charset)`.
The discoverability of the method if placed as `Charset.getEncodedLength(String)` would be very low and would require cross-package hacking to gain the performance advantage.

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

PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3861386284

From jvernee at openjdk.org  Mon Feb  9 21:31:59 2026
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 9 Feb 2026 21:31:59 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
Message-ID: <kRi61jloPuIqbNpENKgKl5GZ-Dzf_yKO7HkbMW3iP1M=.e61813a6-e51d-4ee0-993b-83c1aa1d7ed5@github.com>

On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

> MemorySegments allocated from shared Arena from
> java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over.
> 
> The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op .
> 
> The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654.
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    30.88   |   32.15  |    33.54  |    32.82  |    27.46  |     8.45 |
> |   2    | 142.56    | 134.48  |   132.01 |    131.50 |    116.68   |   46.53 |
> |  4    |  310.18   |  282.75  |   287.59  |   271.82  |   251.88   |   86.11 |
> |  8    |  702.02   |  710.29  |   736.72  |   670.63  |   533.46   |  194.60 |
> |   16  |  1,436.17 |  1,684.80 |  1,833.69 |  1,782.78 |  1,100.15 |    827.28 |
> |  24  | 2,185.55 |  2,508.86 |  2,732.22 |  2,815.26 |  1,646.09 |  1,530.28  |
> |   32  | 2,942.48 |  3,432.84 |  3,643.64 |  3,782.23 |  2,236.81 |  2,278.52 |
> |   48  | 4,466.56 |  5,174.72 |  5,401.95 |  5,621.41 |  4,926.30  | 3,026.58 |
> 
> After:
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    32.41  |    32.11  |    34.43  |  31.32  |    27.94  |     9.82 |
> |    2  |    32.64  |    33.72  |    35.11  |  31.30  |    28.02  |     9.81 |
> |    4  |    32.71  |    36.84  |    34.67  |  31.35  |   28.12   |   10.49 |
> |    8  |    58.22  |    31.60  |    36.87  |  31.72  |    47.09  |...

Thanks for looking at this.

Besides the code comments, there are few points that I'd like to bring up as well:

1. I'm not sure I see using a ticket being worth it vs. just calling `getCounter` again in `release0`. The JIT understands that the current thread doesn't change in most situations, so it should be able to common out the load of the hash code.

2. This adds significant footprint to SharedSession. Especially on server class machines which can have as much as to 512 logical processors (or more), this would add 8 pages of memory use per session instance, assuming the typical 64 byte cache line size, just for the counters.

3. This is already a tricky bit of code in which we've seen several hard to diagnose issues. So, making changes here makes me a bit nervous, and I'm honestly having a hard time judging the cost vs. benefit of this change, considering also that the benchmark is testing the absolute worst case scenario where the acquire/release are being hammered. (and now I _really_ wish I had found the time to look at this earlier).

Given 2. and 3. taken together, and out of an abundance of caution, I suggest keeping both the old and new implementations as separate MemorySessionImpl sub-classes, and then using a system property to select one or the other in `createShared`. Just in case someone wants to switch back to the single counter implementation, or in case we want to use this to diagnose an issue. (Having a single static property select between the impls should also avoid issues with megamorphic call sites since the total number of loaded impls in a given process should stay the same).

src/java.base/share/classes/jdk/internal/foreign/ConfinedSession.java line 54:

> 52:     public int acquire0() {
> 53:         checkValidState();
> 54:         if (acquireCount == MAX_FORKS) {

This acquireCount field should be moved to ConfinedSession

src/java.base/share/classes/jdk/internal/foreign/SharedResourceList.java line 66:

> 64:         if (FST.getAcquire(this) != ResourceCleanup.CLOSED_LIST) {
> 65:             //ok now we're really closing down
> 66:             ResourceCleanup prev = null;

My IDE tells me this `null` assignment is redundant.

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 51:

> 49: 
> 50:     final static private int numCounters;
> 51:     final static private int mask;

Suggestion:

    final static private int COUNTER_MASK;

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 54:

> 52: 
> 53:     // The number of ints per cacheline.
> 54:     final static private int multiplier;

Suggestion:

    final static private int INTS_PER_COUNTER;

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 56:

> 54:     final static private int multiplier;
> 55:     final static int CNT_CLOSING = -1;
> 56:     final static int CNT_CLOSED = -2;

Please use the existing style for modifier order here: `private static final`, and capitalize `static final` field names.

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 58:

> 56:     final static int CNT_CLOSED = -2;
> 57: 
> 58:     private static final jdk.internal.misc.Unsafe UNSAFE = jdk.internal.misc.Unsafe.getUnsafe();

Could you use an import here?

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 78:

> 76: 
> 77:         // Each counter is an integer on its own cacheline.
> 78:         multiplier = ((cacheLineSize < Integer.BYTES) ? 64 : cacheLineSize) / Integer.BYTES;

Why 64 and not 4? Or just `Math.max(cacheLineSize, Integer.BYTES)`.

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 101:

> 99:     private int compareAndExchange(int index, int expected, int value) {
> 100:         assert numCounters > index;
> 101:         return counters.compareAndExchange(index * multiplier, expected, value);

Suggestion:

    @ForceInline
    private int getAcquireCounter(int index) {
        assert numCounters > index;
        return counters.getAcquire(index * multiplier);
    }

    @ForceInline
    private int compareAndExchangeCounter(int index, int expected, int value) {
        assert numCounters > index;
        return counters.compareAndExchange(index * multiplier, expected, value);


Also, maybe you want to use these from `justClose`.

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 129:

> 127:                     old = getAcquire(ticket);
> 128:                     Thread.onSpinWait();
> 129:                 } while (old == CNT_CLOSING);

My worry with something like this is that we don't make monotonic progress between the states, but we might back off and retry.

In other words, if a closing thread fails to close the session, we loop back around, but might end up here again if another thread tries to close the session again, so we could theoretically get 'stuck' here.

In this case I believe it's okay since failing to close a session is typically an indication of an issue in the application logic, so we don't expect this to happen over and over again. Although, we've seen this being used in the wild as a fallback where close was called on a maybe-closed session from a cleaner.

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 151:

> 149:                 old = compareAndExchange(ticket, value, value - 1);
> 150:             } else {
> 151:                 throw alreadyClosed();

Please keep the existing comment for this case

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 157:

> 155: 
> 156:     synchronized void justClose() {
> 157:         int value;

Why is this declared here?

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 180:

> 178:                 // It is already closed - throw an exception.
> 179:                 throw alreadyClosed();
> 180:             }

I don't see how this could occur. You've made `justClose` synchronized, which means we will always see an up to date `state`, and threads can not race to close the session anymore.

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 220:

> 218:     public boolean isCloseable() {
> 219:         if (state == CLOSED) {
> 220:             return true;

This doesn't look right to me. I don't think any override is needed here. It's not a predicate intended to ask whether a session is closeable in it's current state, but rather to ask whether the session kind can be explicitly closed at all.

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 301:

> 299:                 sessionTickets[i] = ticketLocal;
> 300:                 cb.loadConstant(0)
> 301:                 .istore(ticketLocal);

Suggestion:

                  .istore(ticketLocal);

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 566:

> 564:             int ticketLocal = sessionTickets[i];
> 565:             cb.aload(scopeLocal)
> 566:             .ifThen(Opcode.IFNONNULL, ifCb -> {

Suggestion:

              .ifThen(Opcode.IFNONNULL, ifCb -> {

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 569:

> 567:                 ifCb.aload(scopeLocal)
> 568:                 .iload(ticketLocal)
> 569:                 .invokevirtual(CD_MemorySessionImpl, "release0", MTD_RELEASE0);

Suggestion:

                    .iload(ticketLocal)
                    .invokevirtual(CD_MemorySessionImpl, "release0", MTD_RELEASE0);

test/jdk/java/foreign/TestMemorySession.java line 396:

> 394:         int ticket = sessionImpl.acquire0();
> 395: 
> 396:         assertFalse(sessionImpl.isCloseable());

i.e. this should return `true`, shared session may be closed.

test/jdk/java/foreign/TestMemorySession.java line 431:

> 429:         } catch (IllegalStateException e) {
> 430:             fail();
> 431:         }

Failure is implicit if an exception is thrown, so this try/catch shouldn't be necessary.

test/jdk/java/foreign/TestMemorySession.java line 439:

> 437:         } catch (IllegalStateException e) {
> 438:             fail();
> 439:         }

Same here

test/jdk/java/foreign/TestMemorySession.java line 466:

> 464:         boolean closeLose = false;
> 465: 
> 466:         while (true) {

We can't just loop indefinitely. This will definitely result in test timeouts eventually. Please add an upper bound for the number of iterations.

test/jdk/java/foreign/TestMemorySession.java line 481:

> 479:                 threads[i].start();
> 480:             }
> 481:             Thread.sleep(100);

Thread.sleep is not very reliable, especially in highly concurrent CI environment. If the intent is to wait for the threads so start up, I suggest using a CountDownLatch.

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

PR Review: https://git.openjdk.org/jdk/pull/28575#pullrequestreview-3544278113
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782215557
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782052307
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782237502
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782236426
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2676944433
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2592405598
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782072535
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782322487
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2635843460
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782220024
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782226537
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782264630
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782317235
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2774197899
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2592332912
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2592333337
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782350583
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782365127
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782370062
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782403652
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782390762

From mcimadamore at openjdk.org  Mon Feb  9 21:32:09 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 9 Feb 2026 21:32:09 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
Message-ID: <4XtDzO577CpjYbza6luwnpzsXxuZ9L7ttq80_Ypt_Bw=.9cc3b7ea-dfb5-44d1-a468-c7359c0a7a43@github.com>

On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

> MemorySegments allocated from shared Arena from
> java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over.
> 
> The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op .
> 
> The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654.
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    30.88   |   32.15  |    33.54  |    32.82  |    27.46  |     8.45 |
> |   2    | 142.56    | 134.48  |   132.01 |    131.50 |    116.68   |   46.53 |
> |  4    |  310.18   |  282.75  |   287.59  |   271.82  |   251.88   |   86.11 |
> |  8    |  702.02   |  710.29  |   736.72  |   670.63  |   533.46   |  194.60 |
> |   16  |  1,436.17 |  1,684.80 |  1,833.69 |  1,782.78 |  1,100.15 |    827.28 |
> |  24  | 2,185.55 |  2,508.86 |  2,732.22 |  2,815.26 |  1,646.09 |  1,530.28  |
> |   32  | 2,942.48 |  3,432.84 |  3,643.64 |  3,782.23 |  2,236.81 |  2,278.52 |
> |   48  | 4,466.56 |  5,174.72 |  5,401.95 |  5,621.41 |  4,926.30  | 3,026.58 |
> 
> After:
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    32.41  |    32.11  |    34.43  |  31.32  |    27.94  |     9.82 |
> |    2  |    32.64  |    33.72  |    35.11  |  31.30  |    28.02  |     9.81 |
> |    4  |    32.71  |    36.84  |    34.67  |  31.35  |   28.12   |   10.49 |
> |    8  |    58.22  |    31.60  |    36.87  |  31.72  |    47.09  |...

Overall, I think that this is a good experiment (and I'm very grateful for it), but I'm a bit skeptical in seeing it introduced in the JDK codebase. This is a very sensitive area, with lots of multi-threaded gotchas (lots of different failure modes to take into account). As I commented originally, I still feel like separating the ref counter from the liveness bit (ignoring everything else) brings even more failure modes to the table.

After discussing all of this with @JornVernee, we agreed that we should refrain from integrating this work (even if provided merely as an option), and maybe keep the door open to explore other alternatives that might provide some relief, while keeping the code more maintainable in the long run

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

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3872916825

From eirbjo at openjdk.org  Mon Feb  9 21:31:20 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 9 Feb 2026 21:31:20 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <dcjRyp8Tw75L2Vi-Z6Sju1BTtrU1bpx-8zlVdQD21A0=.d228ab0b-6d7b-4cd2-8907-7e439ede95a0@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
 <dcjRyp8Tw75L2Vi-Z6Sju1BTtrU1bpx-8zlVdQD21A0=.d228ab0b-6d7b-4cd2-8907-7e439ede95a0@github.com>
Message-ID: <eDV4Sq6wPNEDyrZSEVnZvALOVcdcstTS9TRkvwT809M=.632b8ee7-039b-48b4-9285-7d5b9e893fd0@github.com>

On Fri, 6 Feb 2026 16:34:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> I'd be fine with `getEncodedLength(Charset)`.

This name makes it clear that the method returns the length of this String, after encoding. While it is not explicity that the length is in bytes, as Roger says, encoding implies bytes anyway, so at the least "Encoded" strongly suggests the unit of measurement is bytes.

The existence of a separate method for an encoded length makes it clear that this cannot have the same semantics as `String::length`. I don't think there is much room for confusion.

While the similarity to the `getBytes().length` idiom is neat in 2026, I don't think it is important enough to determine the name of the metod. A method should describe what it does, not what it's soon to be outdated idiom used to look like back in the day.

> The discoverability of the method if placed as `Charset.getEncodedLength(String)` would be very low and would require cross-package hacking to gain the performance advantage.

The target audicence for this method is not discussed in the CSR, at least not explicitly. If the target audience is "most programmers", then String is a good home. If the target audience is specialist/framework/library developers working in very large companies with very large datasets, then perhaps the discoverabilty is not such a big issue and it's better to "hide away" this in Charset, which is where encoding operations generally live. If performance is important enough, it can warrant use of `JavaLangAccess`.

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

PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3861566063

From eirbjo at openjdk.org  Mon Feb  9 21:31:37 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 9 Feb 2026 21:31:37 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <RB3W_BrY_zcpYpTGt1BdLjRXtrexF-1GpfGoizQmti4=.a4eeeb79-8224-4c82-9a16-a9890882339b@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
 <dcjRyp8Tw75L2Vi-Z6Sju1BTtrU1bpx-8zlVdQD21A0=.d228ab0b-6d7b-4cd2-8907-7e439ede95a0@github.com>
 <eDV4Sq6wPNEDyrZSEVnZvALOVcdcstTS9TRkvwT809M=.632b8ee7-039b-48b4-9285-7d5b9e893fd0@github.com>
 <RB3W_BrY_zcpYpTGt1BdLjRXtrexF-1GpfGoizQmti4=.a4eeeb79-8224-4c82-9a16-a9890882339b@github.com>
Message-ID: <3B5NpEJg1-ylIKV9DYOrb5QN6T_Z6JC4ncRnxiUIjjM=.dfd3ef16-1d2f-4461-8fed-1aa167a487fd@github.com>

On Fri, 6 Feb 2026 17:05:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Maybe it should be looked at but in these discussions it would be CharsetEncoder, not Charset.

Thanks Alan, not exactly my turf :-)

It would be interesting to prototype if an implementation in `CharsetEncoder` could retain the desired performance characteristics. At the least, it would be good to see this alternative discussed in the CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3861656546

From dl at openjdk.org  Mon Feb  9 21:29:49 2026
From: dl at openjdk.org (Doug Lea)
Date: Mon, 9 Feb 2026 21:29:49 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v32]
In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
Message-ID: <kGa3H3Cyb8199fB0vWvDGM1d7HJRuZHxPbNTNgULMME=.4fa3ce14-f18a-4af2-9a4d-b289f3f08e36@github.com>

> Changes signal filtering to avoid possible starvation

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

 - Merge branch 'openjdk:master' into JDK-8373118
 - setup for helpJoin
 - Merge branch 'openjdk:master' into JDK-8373118
 - reduce interference after stalls
 - Avoid yield, for performance test
 - Don't oversignal LIFO
 - Try out different approach
 - Simplify scan mode control by moving and reworking topLevelExec and throwing on trim
 - Another set of contend vs deactivate vs park tradeoffs
 - Fix missing undo
 - ... and 35 more: https://git.openjdk.org/jdk/compare/ce27d5c9...1b9272b3

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28797/files
  - new: https://git.openjdk.org/jdk/pull/28797/files/7ae93ed7..1b9272b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=30-31

  Stats: 9477 lines in 285 files changed: 4647 ins; 1548 del; 3282 mod
  Patch: https://git.openjdk.org/jdk/pull/28797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28797/head:pull/28797

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

From eirbjo at openjdk.org  Mon Feb  9 21:31:47 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 9 Feb 2026 21:31:47 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
Message-ID: <TH-wqKMDI5ZFgLVZu21sO7Ie_23hM_GdDJupWDjfn5U=.fa68aa51-c4d8-41ab-8198-706bdd0f82c0@github.com>

On Fri, 30 Jan 2026 15:56:20 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background.
>> 
>> ---
>> 
>> 
>> Benchmark                              (encoding)  (stringLength)   Mode  Cnt          Score          Error  Units
>> StringLoopJmhBenchmark.getBytes             ASCII              10  thrpt    5  406782650.595 ? 16960032.852  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII             100  thrpt    5  172936926.189 ?  4532029.201  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII            1000  thrpt    5   38830681.232 ?  2413274.766  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII          100000  thrpt    5     458881.155 ?    12818.317  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1              10  thrpt    5   37193762.990 ?  3962947.391  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1             100  thrpt    5   55400876.236 ?  1267331.434  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1            1000  thrpt    5   11104514.001 ?    41718.545  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1          100000  thrpt    5     182535.414 ?    10296.120  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16              10  thrpt    5  113474681.457 ?  8326589.199  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16             100  thrpt    5   37854103.127 ?  4808526.773  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16            1000  thrpt    5    4139833.009 ?    70636.784  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16          100000  thrpt    5      57644.637 ?     1887.112  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII              10  thrpt    5  946701647.247 ? 76938927.141  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII             100  thrpt    5  396615374.479 ? 15167234.884  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII            1000  thrpt    5  100464784.979 ?   794027.897  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII          100000  thrpt    5    1215487.689 ?     1916.468  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1              10  thrpt    5  221265102.323 ? 17013983.056  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1             100  thrpt    5  137617873.887 ?  5842185.781  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1            1000  thrpt    5   92540259.1...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename getBytesLength to getByteLength

Should we also consider the inverse operation, that is to compute the length of a String had it been decoded from a sequence of bytes?

`new String(byte[], Charset).length()` 

Someone will eventually ask for this. I see some potential use case for it in the `ZipFile` implementation where knowing the length ahead of decoding could provide efficient rejection of strings without decoding and without looking at String contents. 

Not saying we need to add it now, just that the name chosen here should leave room for a future addition of this inverse operation.

Something like:


str.getEncodedLength(Charset); // Encoded length of this string
String.getDecodedLength(byte[], Charset); // Decoded length of byte sequence 


or, with the current scheme:


str.getByteLength(Charset); // Encoded length of this string
String.getStringLength(byte[], Charset); // Decoded length of byte sequence 


EDIT:

Moving this out of `java.lang.String` unlocks:

* Symmetry in that both can be instance methods
* We would be free to support `ByteBuffer` and any `CharSequence`, not just strings:


Charset cs = StandardCharsets.UTF_8;
String h = "hello";
byte[] bytes = h.getBytes(cs);

cs.encodedLength(CharBuffer.wrap(h));
cs.encodedLength(new StringBuilder(h));

cs.decodedLength(bytes);
cs.decodedLength(ByteBuffer.wrap(bytes));

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

PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3869643511

From alanb at openjdk.org  Mon Feb  9 21:31:28 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Feb 2026 21:31:28 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <eDV4Sq6wPNEDyrZSEVnZvALOVcdcstTS9TRkvwT809M=.632b8ee7-039b-48b4-9285-7d5b9e893fd0@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
 <dcjRyp8Tw75L2Vi-Z6Sju1BTtrU1bpx-8zlVdQD21A0=.d228ab0b-6d7b-4cd2-8907-7e439ede95a0@github.com>
 <eDV4Sq6wPNEDyrZSEVnZvALOVcdcstTS9TRkvwT809M=.632b8ee7-039b-48b4-9285-7d5b9e893fd0@github.com>
Message-ID: <RB3W_BrY_zcpYpTGt1BdLjRXtrexF-1GpfGoizQmti4=.a4eeeb79-8224-4c82-9a16-a9890882339b@github.com>

On Fri, 6 Feb 2026 17:01:41 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> then perhaps the discoverabilty is not such a big issue and it's better to "hide away" this in Charset, which is where encoding operations generally live.

Maybe it should be looked at but in these discussions it would be CharsetEncoder, not Charset.

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

PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3861593365

From cushon at openjdk.org  Mon Feb  9 21:31:55 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 9 Feb 2026 21:31:55 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <dcjRyp8Tw75L2Vi-Z6Sju1BTtrU1bpx-8zlVdQD21A0=.d228ab0b-6d7b-4cd2-8907-7e439ede95a0@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
 <dcjRyp8Tw75L2Vi-Z6Sju1BTtrU1bpx-8zlVdQD21A0=.d228ab0b-6d7b-4cd2-8907-7e439ede95a0@github.com>
Message-ID: <-LFl1EtppLD8wkhQBOxPu8MrXXc6C6tO3gmCoeLK9JQ=.0f921030-33f3-4d9c-af12-45a4af633d53@github.com>

On Fri, 6 Feb 2026 16:34:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The encoded form is always bytes, so I don't think 'byte' needs to be in the name. I'd be fine with getEncodedLength(Charset).

The javadoc would specify that it's a length in bytes, so perhaps that's sufficient without including 'bytes' in the method name.

I do think that some callers might expect `getEncodedLength(UTF_16)` to return a length in code units and not bytes. There was some related discussion in [JDK-8372338](https://bugs.openjdk.org/browse/JDK-8372338) and also Maurizio's [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html#reading-strings-with-known-length) doc.

> The discoverability of the method if placed as Charset.getEncodedLength(String) would be very low and would require cross-package hacking to gain the performance advantage.

For completeness, here's a demo of it in `CharsetEncoder` (https://github.com/openjdk/jdk/pull/29639). As expected it's possible to implement it that way and preserve equivalent performance, by adding a package visibility method to `String` and using `JavaLangAccess`. With that change, `string.getByteLength(UTF_8)` could be expressed as:


    try {
        int byteLength = StandardCharsets.UTF_8.newEncoder()
                .onUnmappableCharacter(CodingErrorAction.REPLACE)
                .onMalformedInput(CodingErrorAction.REPLACE)
                .getByteLength(stringData);
    } catch (CharacterCodingException e) {
        throw new IllegalStateException(e);
    }


I can update the CSR to document this as an alternative.

> Should we also consider the inverse operation, that is to compute the length of a String had it been decoded from a sequence of bytes? Someone will eventually ask for this. I see some potential use case for it in the ZipFile implementation where knowing the length ahead of decoding could provide efficient rejection of strings without decoding and without looking at String contents.

What is the use-case for `decodedLength` in `ZipFile`? Does 'efficient rejection of strings without decoding' require knowing the decoded length, or just whether the data is a valid encoding?

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

PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3872766017

From dl at openjdk.org  Mon Feb  9 21:30:07 2026
From: dl at openjdk.org (Doug Lea)
Date: Mon, 9 Feb 2026 21:30:07 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v29]
In-Reply-To: <rsAMbHXQHPISH_USfLzZDDuamembcmWaJvVxZmHo-nk=.78508a4c-a33c-47db-83e3-1ef3976440a7@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
 <Lt4qpr0fkua7hF7hccOH20Bj3hSYkTOIAwM6tMlhiho=.110f4df8-4104-4453-bc75-3aa66caecee0@github.com>
 <rsAMbHXQHPISH_USfLzZDDuamembcmWaJvVxZmHo-nk=.78508a4c-a33c-47db-83e3-1ef3976440a7@github.com>
Message-ID: <52katzmucGX0y8q5PZddfmdAo6WiZyXWrwQVdMXG_6E=.c373ec7e-792a-41db-a101-503c17176327@github.com>

On Mon, 26 Jan 2026 12:43:42 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Don't oversignal LIFO
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1058:
> 
>> 1056:     static final int MAX_CAP          = 0x7fff;   // max # workers
>> 1057:     static final int EXTERNAL_ID_MASK = 0x3ffe;   // max external queue id
>> 1058:     static final int INVALID_ID       = 0x4000;   // unused external queue id
> 
> @DougLea INVALID_ID looks to be unused now so we could remove it.

Thanks, done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2779769083

From dl at openjdk.org  Mon Feb  9 21:30:28 2026
From: dl at openjdk.org (Doug Lea)
Date: Mon, 9 Feb 2026 21:30:28 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v27]
In-Reply-To: <fKtA5LcPWA0E39LqrEk9s27cbTJ-46FjOr6GQhCh_rM=.0a52494d-ef70-4495-bec9-4ab77f15d8f6@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
 <j47N33FkwwZ8S0JsKFXOSM6w7mjnfGpuuSFdDC79YUE=.8a01860e-45ee-4691-8c97-06d6a858ffcc@github.com>
 <fKtA5LcPWA0E39LqrEk9s27cbTJ-46FjOr6GQhCh_rM=.0a52494d-ef70-4495-bec9-4ab77f15d8f6@github.com>
Message-ID: <1RctAxWYDbTNy-ND6F7-kwyK7132ScRSIi95RR2bfFg=.aebe5cc8-08ff-428b-9d09-0ae8bd700310@github.com>

On Mon, 19 Jan 2026 21:03:02 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify scan mode control by moving and reworking topLevelExec and throwing on trim
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1271:
> 
>> 1269:                 }
>> 1270:                 if (pred == null && pool != null)
>> 1271:                     pool.signalWork(this, s); // may have appeared empty
> 
> @DougLea I presume we don't need to do the getReferenceAcquire if the pool is null?
> 
> If so, then we could do something like:
> 
> 
>                 boolean signal = pool != null && U.getReferenceAcquire(a, slotOffset(m & (s - 1))) == null;
>                 if (unlock != 1) {            // release external lock
>                     U.putInt(this, PHASE, unlock);
>                     U.storeFence();
>                 }
>                 if (signal)
>                     pool.signalWork(this, s); // may have appeared empty

I was skeptical about specializing around here, but after reading this, I found that avoiding getAcquire when already known empty was s small win.

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1303:
> 
>> 1301:                     if (unlock != 1)
>> 1302:                         phase = unlock;
>> 1303:                     if (pool != null)
> 
> @DougLea Are we 100% sure we always need to signal upon resize?

Yes, because worker in runWorker won't see a task and so won't propagate (and it costs more to check this than just always doing it on resize).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2779750895
PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2779755766

From eirbjo at openjdk.org  Mon Feb  9 21:32:04 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 9 Feb 2026 21:32:04 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <-LFl1EtppLD8wkhQBOxPu8MrXXc6C6tO3gmCoeLK9JQ=.0f921030-33f3-4d9c-af12-45a4af633d53@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
 <dcjRyp8Tw75L2Vi-Z6Sju1BTtrU1bpx-8zlVdQD21A0=.d228ab0b-6d7b-4cd2-8907-7e439ede95a0@github.com>
 <-LFl1EtppLD8wkhQBOxPu8MrXXc6C6tO3gmCoeLK9JQ=.0f921030-33f3-4d9c-af12-45a4af633d53@github.com>
Message-ID: <IaSQM7fea0j-a6y8D94GAf3-gkpTc8AEK_T07fxiWpc=.64fa7ee5-19b8-4571-a58d-c90c021bb3c8@github.com>

On Mon, 9 Feb 2026 16:26:42 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> What is the use-case for `decodedLength` in `ZipFile`? Does 'efficient rejection of strings without decoding' require knowing the decoded length, or just whether the data is a valid encoding?

The ZIP file CEN header format only includes the length of the name in encoded form. Knowing the length of the decoded string could potentially let us quickly reject lookup matches against a lookup String only based on comparing string lengths (ZipFile supports returning "directory/" as a result for "directory", so we know a match would be 9 or 10 chars long).  

In practise, we compare hash codes before comparing strings. So this would only be useful for hash collisions. These are rare, so not worth optimizing. Perhaps there are other oppertinities though, it would certainly be possible to reject lookups based on min/max occurrence of entry lengths (or perhaps a bitset of occurring string lengths).

But I'm sure there are other use cases where a `java.lang.String` is compared to its encoded form and knowing the length without String allocation could be useful. Input validation is another, possibly combined with rejection on malformed encoded data.

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

PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3872836764

From dl at openjdk.org  Mon Feb  9 21:30:53 2026
From: dl at openjdk.org (Doug Lea)
Date: Mon, 9 Feb 2026 21:30:53 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v28]
In-Reply-To: <uZzhYfZYklb3gvI97xQAv7GQKZ0ATE4VPiLoXHoU0d4=.e135fe66-785c-4751-9ca3-ce533a8e2865@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
 <t6OJG3N-Eh72D1D5SEO-BreGyaMKiaDP1nZYa7_z2Es=.5988b7ab-4be1-4792-a7bd-71a74fd0fc12@github.com>
 <uZzhYfZYklb3gvI97xQAv7GQKZ0ATE4VPiLoXHoU0d4=.e135fe66-785c-4751-9ca3-ce533a8e2865@github.com>
Message-ID: <-RvxrvXvIINaTCXtYmWYORqS4LiXeSD7dXg53FETxSo=.37a3484b-d845-4988-87fb-2788fe2f2a10@github.com>

On Fri, 23 Jan 2026 13:10:49 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Try out different approach
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1303:
> 
>> 1301:                     U.putReferenceVolatile(this, ARRAY, newArray);
>> 1302:                     if (unlock != 1)
>> 1303:                         phase = unlock;
> 
> Not sure if it helps, but if we can piggyback on the volatile write to phase, then we could structure it like so:
> 
> 
>                     if (unlock != 1) {
>                         U.putReference(this, ARRAY, newArray);
>                         phase = unlock;
>                     } else {
>                         U.putReferenceVolatile(this, ARRAY, newArray);
>                     }

Good idea. Will do.

> src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 643:
> 
>> 641:      */
>> 642:     public final ForkJoinTask<V> fork() {
>> 643:         Thread t; ForkJoinWorkerThread wt;
> 
> @DougLea Btw, we can likely remove noUserHelp and setNoUserHelp (and associated bits).

The bit is still needed in FJT awaitDone, and the method might be useful elsewhere even though it's no longer used with signalling because the other changes make it not worthwhile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2779788838
PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2779768384

From vklang at openjdk.org  Mon Feb  9 21:31:03 2026
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 9 Feb 2026 21:31:03 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v32]
In-Reply-To: <kGa3H3Cyb8199fB0vWvDGM1d7HJRuZHxPbNTNgULMME=.4fa3ce14-f18a-4af2-9a4d-b289f3f08e36@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
 <kGa3H3Cyb8199fB0vWvDGM1d7HJRuZHxPbNTNgULMME=.4fa3ce14-f18a-4af2-9a4d-b289f3f08e36@github.com>
Message-ID: <QS1nw4DaFaJfYR6cJ8OAjRuLbDu6dlLItAocYDcdtnQ=.dec0a1c5-9f9a-4b6e-a64f-0abe079a1867@github.com>

On Mon, 9 Feb 2026 09:32:51 GMT, Doug Lea <dl at openjdk.org> wrote:

>> Changes signal filtering to avoid possible starvation
>
> 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 45 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8373118
>  - setup for helpJoin
>  - Merge branch 'openjdk:master' into JDK-8373118
>  - reduce interference after stalls
>  - Avoid yield, for performance test
>  - Don't oversignal LIFO
>  - Try out different approach
>  - Simplify scan mode control by moving and reworking topLevelExec and throwing on trim
>  - Another set of contend vs deactivate vs park tradeoffs
>  - Fix missing undo
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/ce27d5c9...1b9272b3

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1984:

> 1982:                                 if (qid != (prevSrc = src))
> 1983:                                     w.source = src = qid;
> 1984:                                 U.storeFence();

@DougLea Since `source` is `volatile` again, we only need the storeFence in an `else` here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2781581201

From dl at openjdk.org  Mon Feb  9 21:31:41 2026
From: dl at openjdk.org (Doug Lea)
Date: Mon, 9 Feb 2026 21:31:41 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v32]
In-Reply-To: <GOdFqzqsuH3UugAQQh9MHYmjlxmljX-YGFBAQMG6rh0=.6045b428-853a-43a0-894b-ee8162683a76@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
 <YBoyP1MKQyLS-izG5Tl-TFZdRZVGW0VF1Q3sNnFia7w=.7610284c-7d80-4eff-90e8-cc60d2afd7ea@github.com>
 <GOdFqzqsuH3UugAQQh9MHYmjlxmljX-YGFBAQMG6rh0=.6045b428-853a-43a0-894b-ee8162683a76@github.com>
Message-ID: <rMSpoaBIafI3hmfZ7omJ33Eb9Vrw9zLu5wZD7UtqT8k=.57c13c20-82e0-402c-b76a-279d7337ea70@github.com>

On Thu, 5 Feb 2026 12:17:20 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 45 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8373118
>>  - setup for helpJoin
>>  - Merge branch 'openjdk:master' into JDK-8373118
>>  - reduce interference after stalls
>>  - Avoid yield, for performance test
>>  - Don't oversignal LIFO
>>  - Try out different approach
>>  - Simplify scan mode control by moving and reworking topLevelExec and throwing on trim
>>  - Another set of contend vs deactivate vs park tradeoffs
>>  - Fix missing undo
>>  - ... and 35 more: https://git.openjdk.org/jdk/compare/ce27d5c9...1b9272b3
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1988:
> 
>> 1986:                                 ran = 1;
>> 1987:                                 ++taken;
>> 1988:                                 if (propagate && U.getReferenceAcquire(a, np) != null)
> 
> At this point, it might even make sense to fold the propagate logic into the if-clause itself. Something like:
> 
> 
>                                 ran = 1;
>                                 ++taken;
>                                 if ((rnt != null) &&
>                                     (ps < 0 ||
>                                      ((qid & 1) == 0 &&
>                                       (fifo != 0 || taken == 1))) && U.getReferenceAcquire(a, np) != null)

Thanks. I changed to something similar.

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2030:
> 
>> 2028:                 int phase = U.getInt(w, WorkQueue.PHASE);
>> 2029:                 long sp = (phase + NEXTIDLE) & LMASK, pc = ctl;
>> 2030:                 U.putInt(w, WorkQueue.PHASE, phase | IDLE);
> 
> So the idea here is to potentially delay the store?

main idea is that if shadowed "idle" is 0, it can't be wrong, so just plain-read to get full value

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2811:
> 
>> 2809:                     if (q.base == b && t != null &&
>> 2810:                         U.compareAndSetReference(a, k, t, null)) {
>> 2811:                         q.base = b + 1;
> 
> Doesn't this mean that this write might end up not safely published? ?

That one can't matter, but for consistency I added storeFence

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2779732120
PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2779742532
PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2779732881

From jbhateja at openjdk.org  Mon Feb  9 21:33:28 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 9 Feb 2026 21:33:28 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v20]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <GxlEHGCu9uuiWMGB6FdaZ09x49S6xavovN2UzWT8yCY=.a6a693b4-509c-4ef3-a736-5527145472c8@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

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

  Test cleanups and re-factoring

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28002/files
  - new: https://git.openjdk.org/jdk/pull/28002/files/54f87337..ed6d33a6

Webrevs:
 - full: Webrev is not available because diff is too large
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=18-19

  Stats: 2439 lines in 77 files changed: 540 ins; 0 del; 1899 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

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

From dl at openjdk.org  Mon Feb  9 21:32:16 2026
From: dl at openjdk.org (Doug Lea)
Date: Mon, 9 Feb 2026 21:32:16 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v26]
In-Reply-To: <mspk3CG3iXJGaUnBOiTuPnnNosqFFReuKGrN6Q_mgME=.9d607bcf-4c97-447a-ad14-b862ce75d370@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
 <pRIle-vMDEdEjBY3ZtCeXlDL9JlCC_Y_3LTNbVsRwXE=.4a895d1d-4107-4501-ad9e-d6d7aea940f4@github.com>
 <mspk3CG3iXJGaUnBOiTuPnnNosqFFReuKGrN6Q_mgME=.9d607bcf-4c97-447a-ad14-b862ce75d370@github.com>
Message-ID: <2-zT83lu6oPAUwH9nqhoBQleaJ-U2mVkksGrwlTQeVI=.6c81451c-e648-44c6-aa39-bd4aaa3edaaa@github.com>

On Thu, 15 Jan 2026 14:29:02 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Another set of contend vs deactivate vs park tradeoffs
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2593:
> 
>> 2591:                 break;
>> 2592:             if ((q = qs[i = (id = r & EXTERNAL_ID_MASK) & (n - 1)]) == null) {
>> 2593:                 WorkQueue newq = new WorkQueue(null, id, 0, false);
> 
> @DougLea Is there a specific reason as to why CLEAR_TLS is false here?

Because external queues don't have owners, so it would never apply.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2779782366

From bkilambi at openjdk.org  Mon Feb  9 21:33:53 2026
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 9 Feb 2026 21:33:53 GMT
Subject: RFR: 8366444: Add support for add/mul reduction operations for
 Float16 [v6]
In-Reply-To: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com>
References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com>
Message-ID: <IkUknE_nm70vBx8hfW3UYJyYiRlXw5BUMv_lFBgaQOQ=.6bdd353a-3e09-4fec-8a3f-7fe2cd4f683f@github.com>

> This patch adds mid-end support for vectorized add/mul reduction operations for half floats. It also includes backend aarch64 support for these operations. Only vectorization support through autovectorization is added as VectorAPI currently does not support Float16 vector species.
> 
> Both add and mul reduction vectorized through autovectorization mandate the implementation to be strictly ordered. The following is how each of these reductions is implemented for different aarch64 targets -
> 
> **For AddReduction :**
> On Neon only targets (UseSVE = 0): Generates scalarized additions using the scalar `fadd` instruction for both 8B and 16B vector lengths. This is because Neon does not provide a direct instruction for computing strictly ordered floating point add reduction.
> 
> On SVE targets (UseSVE > 0): Generates the `fadda` instruction which computes add reduction for floating point in strict order.
> 
> **For MulReduction :**
> Both Neon and SVE do not provide a direct instruction for computing strictly ordered floating point multiply reduction. For vector lengths of 8B and 16B, a scalarized sequence of scalar `fmul` instructions is generated and multiply reduction for vector lengths > 16B is not supported.
> 
> Below is the performance of the two newly added microbenchmarks in `Float16OperationsBenchmark.java` tested on three different aarch64 machines and with varying `MaxVectorSize` -
> 
> Note: On all machines, the score (ops/ms) is compared with the master branch without this patch which generates a sequence of loads (`ldrsh`) to load the FP16 value into an FPR and a scalar `fadd/fmul` to add/multiply the loaded value to the running sum/product. The ratios given below are the ratios between the throughput with this patch and the throughput without this patch.
> Ratio > 1 indicates the performance with this patch is better than the master branch.
> 
> **N1 (UseSVE = 0, max vector length = 16B):**
> 
> Benchmark         vectorDim  Mode   Cnt  8B     16B
> ReductionAddFP16  256        thrpt  9    1.41   1.40
> ReductionAddFP16  512        thrpt  9    1.41   1.41
> ReductionAddFP16  1024       thrpt  9    1.43   1.40
> ReductionAddFP16  2048       thrpt  9    1.43   1.40
> ReductionMulFP16  256        thrpt  9    1.22   1.22
> ReductionMulFP16  512        thrpt  9    1.21   1.23
> ReductionMulFP16  1024       thrpt  9    1.21   1.22
> ReductionMulFP16  2048       thrpt  9    1.20   1.22
> 
> 
> On N1, the scalarized sequence of `fadd/fmul` are generated for both `MaxVectorSize` of 8B and 16B for add reduction ...

Bhavana Kilambi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Address review feedback
 - merge from main
 - Merge commit '9f13ec1ccb684398e311b5f139773ca9f39561fe' into HEAD
 - Address review comments for the JTREG test and microbenchmark
 - Merge branch 'master'
 - Address review comments
 - Fix build failures on Mac
 - Address review comments
 - Merge 'master'
 - 8366444: Add support for add/mul reduction operations for Float16
   
   This patch adds mid-end support for vectorized add/mul reduction
   operations for half floats. It also includes backend aarch64 support for
   these operations. Only vectorization support through autovectorization
   is added as VectorAPI currently does not support Float16 vector species.
   
   Both add and mul reduction vectorized through autovectorization mandate
   the implementation to be strictly ordered. The following is how each of
   these reductions is implemented for different aarch64 targets -
   
   For AddReduction :
   On Neon only targets (UseSVE = 0): Generates scalarized additions
   using the scalar "fadd" instruction for both 8B and 16B vector lengths.
   This is because Neon does not provide a direct instruction for computing
   strictly ordered floating point add reduction.
   
   On SVE targets (UseSVE > 0): Generates the "fadda" instruction which
   computes add reduction for floating point in strict order.
   
   For MulReduction :
   Both Neon and SVE do not provide a direct instruction for computing
   strictly ordered floating point multiply reduction. For vector lengths
   of 8B and 16B, a scalarized sequence of scalar "fmul" instructions is
   generated and multiply reduction for vector lengths > 16B is not
   supported.
   
   Below is the performance of the two newly added microbenchmarks in
   Float16OperationsBenchmark.java tested on three different aarch64
   machines and with varying MaxVectorSize -
   
   Note: On all machines, the score (ops/ms) is compared with the master
   branch without this patch which generates a sequence of loads ("ldrsh")
   to load the FP16 value into an FPR and a scalar "fadd/fmul" to
   add/multiply the loaded value to the running sum/product. The ratios
   given below are the ratios between the throughput with this patch and
   the throughput without this patch.
   Ratio > 1 indicates the performance with this patch is better than the
   master branch.
   
   N1 (UseSVE = 0, max vector length = 16B):
   Benchmark         vectorDim  Mode   Cnt  8B     16B
   ReductionAddFP16  256        thrpt  9    1.41   1.40
   ReductionAddFP16  512        thrpt  9    1.41   1.41
   ReductionAddFP16  1024       thrpt  9    1.43   1.40
   ReductionAddFP16  2048       thrpt  9    1.43   1.40
   ReductionMulFP16  256        thrpt  9    1.22   1.22
   ReductionMulFP16  512        thrpt  9    1.21   1.23
   ReductionMulFP16  1024       thrpt  9    1.21   1.22
   ReductionMulFP16  2048       thrpt  9    1.20   1.22
   
   On N1, the scalarized sequence of fadd/fmul are generated for both
   MaxVectorSize of 8B and 16B for add reduction and mul reduction
   respectively.
   
   V1 (UseSVE = 1, max vector length = 32B):
   Benchmark         vectorDim  Mode   Cnt  8B     16B     32B
   ReductionAddFP16  256        thrpt  9    1.11   1.75    2.02
   ReductionAddFP16  512        thrpt  9    1.02   1.64    1.93
   ReductionAddFP16  1024       thrpt  9    1.02   1.59    1.85
   ReductionAddFP16  2048       thrpt  9    1.02   1.56    1.80
   ReductionMulFP16  256        thrpt  9    1.12   0.99    1.09
   ReductionMulFP16  512        thrpt  9    1.04   1.01    1.04
   ReductionMulFP16  1024       thrpt  9    1.02   1.02    1.00
   ReductionMulFP16  2048       thrpt  9    1.01   1.01    1.00
   
   On V1, for MaxVectorSize = 8: scalarized fadd/fmul sequence will be
   generated for AddReductionVHF/MulReductionVHF as UseSVE defaults to 0
   [2].
   For MaxVectorSize = 16: scalarized "fmul" sequence is generated for
   MulReductionVHF and "fadda" is generated for AddReductionVHF which
   fetches signficant gains.
   For MaxVectorSize = 32: Autovectorization of MulReductionVHF is disabled
   for MaxVectorSize > 16B so the autovectorizer checks for maximal
   implemented size[1] which is 16B and generates scalarized "fmul"
   sequence for 16B in this case. For AddReductionVHF, it generates the
   "fadda" instruction.
   
   V2 (UseSVE = 2, max vector length = 16B)
   Benchmark         vectorDim  Mode   Cnt  8B     16B
   ReductionAddFP16  256        thrpt  9    1.16   1.70
   ReductionAddFP16  512        thrpt  9    1.02   1.61
   ReductionAddFP16  1024       thrpt  9    1.01   1.53
   ReductionAddFP16  2048       thrpt  9    1.00   1.49
   ReductionMulFP16  256        thrpt  9    1.18   0.99
   ReductionMulFP16  512        thrpt  9    1.04   1.01
   ReductionMulFP16  1024       thrpt  9    1.02   1.02
   ReductionMulFP16  2048       thrpt  9    1.01   1.01
   
   On V2, for MaxVectorSize = 8: scalarized fadd/fmul sequence will be
   generated as UseSVE defaults to 0 [2].
   For MaxVectorSize = 16: "fadda" instruction is generated for
   AddReductionVHF which results in significant gains in performance. For
   MulReductionVHF, the scalarized "fmul" sequence will be generated.
   
   Testing:
   hotspot_all, jdk(tiers1-3) and langtools(tier1) all pass on N1/V1/V2.
   
   [1] https://github.com/openjdk/jdk/blob/a272696813f2e5e896ac9de9985246aaeb9d476c/src/hotspot/share/opto/superword.cpp#L1677
   [2] https://github.com/openjdk/jdk/blob/a272696813f2e5e896ac9de9985246aaeb9d476c/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp#L479

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

Changes: https://git.openjdk.org/jdk/pull/27526/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27526&range=05
  Stats: 826 lines in 14 files changed: 762 ins; 13 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/27526.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27526/head:pull/27526

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

From duke at openjdk.org  Mon Feb  9 21:34:19 2026
From: duke at openjdk.org (Yi Wu)
Date: Mon, 9 Feb 2026 21:34:19 GMT
Subject: RFR: 8366444: Add support for add/mul reduction operations for
 Float16 [v5]
In-Reply-To: <KROTUb6gjcZCTDVdgdaGlgSUP0mAOWnTiKeG1xrfzD4=.b09865ae-4183-44bb-a707-f36db7190066@github.com>
References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com>
 <KROTUb6gjcZCTDVdgdaGlgSUP0mAOWnTiKeG1xrfzD4=.b09865ae-4183-44bb-a707-f36db7190066@github.com>
Message-ID: <i8aZikMdgmdn5fe3I3DmP7XP9IVWnRO44D2tng0LKF0=.0d87845e-89e7-4019-ad4c-051daf671248@github.com>

On Mon, 29 Dec 2025 17:39:42 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> This patch adds mid-end support for vectorized add/mul reduction operations for half floats. It also includes backend aarch64 support for these operations. Only vectorization support through autovectorization is added as VectorAPI currently does not support Float16 vector species.
>> 
>> Both add and mul reduction vectorized through autovectorization mandate the implementation to be strictly ordered. The following is how each of these reductions is implemented for different aarch64 targets -
>> 
>> **For AddReduction :**
>> On Neon only targets (UseSVE = 0): Generates scalarized additions using the scalar `fadd` instruction for both 8B and 16B vector lengths. This is because Neon does not provide a direct instruction for computing strictly ordered floating point add reduction.
>> 
>> On SVE targets (UseSVE > 0): Generates the `fadda` instruction which computes add reduction for floating point in strict order.
>> 
>> **For MulReduction :**
>> Both Neon and SVE do not provide a direct instruction for computing strictly ordered floating point multiply reduction. For vector lengths of 8B and 16B, a scalarized sequence of scalar `fmul` instructions is generated and multiply reduction for vector lengths > 16B is not supported.
>> 
>> Below is the performance of the two newly added microbenchmarks in `Float16OperationsBenchmark.java` tested on three different aarch64 machines and with varying `MaxVectorSize` -
>> 
>> Note: On all machines, the score (ops/ms) is compared with the master branch without this patch which generates a sequence of loads (`ldrsh`) to load the FP16 value into an FPR and a scalar `fadd/fmul` to add/multiply the loaded value to the running sum/product. The ratios given below are the ratios between the throughput with this patch and the throughput without this patch.
>> Ratio > 1 indicates the performance with this patch is better than the master branch.
>> 
>> **N1 (UseSVE = 0, max vector length = 16B):**
>> 
>> Benchmark         vectorDim  Mode   Cnt  8B     16B
>> ReductionAddFP16  256        thrpt  9    1.41   1.40
>> ReductionAddFP16  512        thrpt  9    1.41   1.41
>> ReductionAddFP16  1024       thrpt  9    1.43   1.40
>> ReductionAddFP16  2048       thrpt  9    1.43   1.40
>> ReductionMulFP16  256        thrpt  9    1.22   1.22
>> ReductionMulFP16  512        thrpt  9    1.21   1.23
>> ReductionMulFP16  1024       thrpt  9    1.21   1.22
>> ReductionMulFP16  2048       thrpt  9    1.20   1.22
>> 
>> 
>> On N1, the scalarized sequence of `fadd/fmul` are gener...
>
> Bhavana Kilambi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Address review comments for the JTREG test and microbenchmark
>  - Merge branch 'master'
>  - Address review comments
>  - Fix build failures on Mac
>  - Address review comments
>  - Merge 'master'
>  - 8366444: Add support for add/mul reduction operations for Float16
>    
>    This patch adds mid-end support for vectorized add/mul reduction
>    operations for half floats. It also includes backend aarch64 support for
>    these operations. Only vectorization support through autovectorization
>    is added as VectorAPI currently does not support Float16 vector species.
>    
>    Both add and mul reduction vectorized through autovectorization mandate
>    the implementation to be strictly ordered. The following is how each of
>    these reductions is implemented for different aarch64 targets -
>    
>    For AddReduction :
>    On Neon only targets (UseSVE = 0): Generates scalarized additions
>    using the scalar "fadd" instruction for both 8B and 16B vector lengths.
>    This is because Neon does not provide a direct instruction for computing
>    strictly ordered floating point add reduction.
>    
>    On SVE targets (UseSVE > 0): Generates the "fadda" instruction which
>    computes add reduction for floating point in strict order.
>    
>    For MulReduction :
>    Both Neon and SVE do not provide a direct instruction for computing
>    strictly ordered floating point multiply reduction. For vector lengths
>    of 8B and 16B, a scalarized sequence of scalar "fmul" instructions is
>    generated and multiply reduction for vector lengths > 16B is not
>    supported.
>    
>    Below is the performance of the two newly added microbenchmarks in
>    Float16OperationsBenchmark.java tested on three different aarch64
>    machines and with varying MaxVectorSize -
>    
>    Note: On all machines, the score (ops/ms) is compared with the master
>    branch without this patch which generates a sequence of loads ("ldrsh")
>    to load the FP16 value into an FPR and a scalar "fadd/fmul" to
>    add/multiply the loaded value to the running sum/product. The ratios
>    given below are the ratios between the throughput with this patch and
>    the throughput without this patch.
>    Ratio > 1 indicates the performance with this patch is better than the
>    master branch.
>    
>    N1 (UseSVE = 0, max vector length = 16B):
>    Benchmark         vectorDim  Mode   Cnt  8B     16B
>    ReductionAddFP16  256        th...

Here are the new benchmark result:

Neoverse N1 (UseSVE = 0, max vector length = 16B):

Benchmark            vectorDim   Mode    Cnt     8B     16B
ReductionAddFP16        256     thrpt     9     1.17    1.21
ReductionAddFP16        512     thrpt     9     1.17    1.18
ReductionAddFP16       1024     thrpt     9     1.18    1.17
ReductionAddFP16       2048     thrpt     9     1.19    1.16
ReductionMulFP16        256     thrpt     9     1.03    1.04
ReductionMulFP16        512     thrpt     9     1.02    1.03
ReductionMulFP16       1024     thrpt     9     1.01    1.02
ReductionMulFP16       2048     thrpt     9     1.01    1.01


Neoverse V1 (UseSVE = 1, max vector length = 32B):

Benchmark            vectorDim   Mode   Cnt     8B     16B     32B
ReductionAddFP16        256     thrpt     9     1.12    1.75    1.95
ReductionAddFP16        512     thrpt     9     1.07    1.64    1.87
ReductionAddFP16       1024     thrpt     9     1.05    1.59    1.78
ReductionAddFP16       2048     thrpt     9     1.04    1.56    1.74
ReductionMulFP16        256     thrpt     9     1.12    1.12    1.11
ReductionMulFP16        512     thrpt     9     1.04    1.05    1.05
ReductionMulFP16       1024     thrpt     9     1.02    1.02    0.99
ReductionMulFP16       2048     thrpt     9     1.01    1.01    1.00


Neoverse V2 (UseSVE = 2, max vector length = 16B)

Benchmark            vectorDim   Mode    Cnt     8B     16B
ReductionAddFP16        256     thrpt     9     1.16    1.70
ReductionAddFP16        512     thrpt     9     1.07    1.61
ReductionAddFP16       1024     thrpt     9     1.03    1.53
ReductionAddFP16       2048     thrpt     9     1.02    1.50
ReductionMulFP16        256     thrpt     9     1.18    1.18
ReductionMulFP16        512     thrpt     9     1.08    1.07
ReductionMulFP16       1024     thrpt     9     1.04    1.04
ReductionMulFP16       2048     thrpt     9     1.02    1.01

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

PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3861614647

From jbhateja at openjdk.org  Mon Feb  9 21:36:16 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 9 Feb 2026 21:36:16 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v13]
In-Reply-To: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
Message-ID: <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@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 with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
 - Review comments resolutions
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
 - Review comments resolutions
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
 - Update callGenerator.hpp copyright year
 - Review comments resolution
 - Cleanups
 - Review comments resolutions
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
 - ... and 6 more: https://git.openjdk.org/jdk/compare/ffb6279c...1dfff558

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

Changes: https://git.openjdk.org/jdk/pull/24104/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=12
  Stats: 1330 lines in 29 files changed: 1234 ins; 2 del; 94 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 zlin at openjdk.org  Mon Feb  9 21:36:25 2026
From: zlin at openjdk.org (Zihao Lin)
Date: Mon, 9 Feb 2026 21:36:25 GMT
Subject: RFR: 8352171: Arrays.hashCode for sub-range of byte array API
 addition [v2]
In-Reply-To: <7gQl1n-MJduqKk69EPDFI-HGRG2KcVYVXp8Ca9TXWLw=.0a399d96-8982-4704-a367-32d8d9b080bb@github.com>
References: <863TowvS917gG9yKE1hbDkd_CeYCwzbSm_mtAcKFTJQ=.f6a72b03-5642-493d-8d2b-48bbf4a3f8b2@github.com>
 <DHO19EafD_p-lodbKi5kcbHxZfv3h8HcftSLZfz91XU=.92f7cea0-2503-4307-abb5-96d19fad3a5b@github.com>
 <7gQl1n-MJduqKk69EPDFI-HGRG2KcVYVXp8Ca9TXWLw=.0a399d96-8982-4704-a367-32d8d9b080bb@github.com>
Message-ID: <4sB2MtVSsjRkGO_aKiQ3QooMCAB0p0lNohlWFSGI9Vk=.70e3962c-6ffc-479b-aeae-ba078929d55b@github.com>

On Sat, 6 Dec 2025 14:19:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Zihao Lin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into dev
>>  - 8352171: Arrays.hashCode for sub-range of byte array API addition
>
> Also, I think a name like hashCodeOfRange serves better, like copyOfRange.

Hi @liach @SirYwell @RogerRiggs , I finish the [CRS](https://bugs.openjdk.org/browse/JDK-8376961), can your help to take a look, thank your everyone.

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

PR Comment: https://git.openjdk.org/jdk/pull/24128#issuecomment-3871603955

From rriggs at openjdk.org  Mon Feb  9 21:36:44 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 9 Feb 2026 21:36:44 GMT
Subject: RFR: 8352171: Arrays.hashCode for sub-range of byte array API
 addition [v3]
In-Reply-To: <nxrWw6FZFcRhcLcDU0VhTqy385UMeGfx-YbtS5arZ00=.94edd34b-ef09-472f-9292-71bc0cd6a4b1@github.com>
References: <863TowvS917gG9yKE1hbDkd_CeYCwzbSm_mtAcKFTJQ=.f6a72b03-5642-493d-8d2b-48bbf4a3f8b2@github.com>
 <nxrWw6FZFcRhcLcDU0VhTqy385UMeGfx-YbtS5arZ00=.94edd34b-ef09-472f-9292-71bc0cd6a4b1@github.com>
Message-ID: <dL1PEN7lziB5IW_sYzCvAPtSngCNz7xOa7D3s_CDBxw=.461077c5-55d3-46f4-be51-f6ea4da8eaf6@github.com>

On Mon, 9 Feb 2026 15:24:53 GMT, Zihao Lin <zlin at openjdk.org> wrote:

>> Add the java.util.Arrays.hashCode(byte[], int start, int end).
>> 
>> Hi team, I am new here, please give me some guidance. Thank you.
>
> Zihao Lin 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:
> 
>  - rename to hashCodeOfRange
>  - Merge branch 'master' into dev
>  - Merge branch 'openjdk:master' into dev
>  - Merge branch 'openjdk:master' into dev
>  - 8352171: Arrays.hashCode for sub-range of byte array API addition

src/java.base/share/classes/java/util/Arrays.java line 4449:

> 4447:      * order. If {@code a} is {@code null}, this method treats the array as
> 4448:      * having length {@code 0} for range checking and returns {@code 0} only
> 4449:      * for the empty range {@code [0,0)}.

"**only** for the empty range" may be misunderstood.
I would also rename the parameter to "array", the simple "a" is confusing to read in the javadoc with only the font change.

Suggestion:

     * order. If {@code a} is {@code null}, this method treats the array as
     * having length {@code 0} for range checking.
     * This method returns {@code 0} if either {@code a} is null or the range is empty {@code [0,0)}.

Separating the statements allows the first to apply to the range checking in the @throws clause.
And the second to make it clearer that zero is returned for empty/null ranges.

src/java.base/share/classes/java/util/Arrays.java line 4455:

> 4453:      * @param toIndex the final index of the range to be hashed, exclusive
> 4454:      * @return a content-based hash code for the specified range of the array,
> 4455:      *         or {@code 0} if {@code a} is {@code null} and the range is empty

Suggestion:

     *         or {@code 0} if either {@code a} is {@code null} or the range is empty

Clarify that either condition is independently sufficient to return 0.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24128#discussion_r2783076663
PR Review Comment: https://git.openjdk.org/jdk/pull/24128#discussion_r2783040185

From stuefe at openjdk.org  Mon Feb  9 21:33:37 2026
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 9 Feb 2026 21:33:37 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v5]
In-Reply-To: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
Message-ID: <yFQp76OS54YtFC7ACRlvgKCuj0SI8UkS54MFEGUaOqg=.f8c3b537-8b89-4a28-bb6a-15a20d9539df@github.com>

> _This patch is not intended for JDK 26_. 
> 
> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
> 
> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
> 
> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
> 
> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
> 
> ### Implementation Notes
> 
> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>   b) 64-bit, COH on
>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
> 
> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
> 
> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>   
> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
> 
> ### Testing
> 
> - tier 1 2 3 locally on Linux x64
> - SAP ran their whole set of tests for all the platforms they support.
> 
> 
> [1] https://bugs.openjdk.org/browse/JDK-8350754
> [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February...

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:

 - Replace Klass::_metadata union with narrowKlass member
 - Ivan: fix various instances of ObjLayout::undefined should assert
 - Ivan: Update src/hotspot/share/oops/instanceKlass.cpp
   
   Co-authored-by: Ivan Walulya <ivan.walulya at oracle.com>
 - David: reduce diff in ObjectCountEventVerifier.java
 - David: minimize change in GetObjectSizeIntrinsicsTest.java
 - David: minimize diffs in TestZGCWithCDS.java
 - David: minimize diffs for runtime/ErrorHandling/TestVMConfigInHsErrFile.java
 - David: revert type change in arguments.cpp
 - David: fix comment in metaspace
 - Merge branch 'master' into JDK-8363996-Obsolete-UseCompressedClassPointers
 - ... and 52 more: https://git.openjdk.org/jdk/compare/ffb6279c...642604ac

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

Changes: https://git.openjdk.org/jdk/pull/28366/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28366&range=04
  Stats: 1702 lines in 141 files changed: 61 ins; 1187 del; 454 mod
  Patch: https://git.openjdk.org/jdk/pull/28366.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28366/head:pull/28366

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

From stuefe at openjdk.org  Mon Feb  9 21:34:02 2026
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 9 Feb 2026 21:34:02 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v4]
In-Reply-To: <jedU_ilFWTbEPv8RFDP9uPw7T9-tO5V_ETTw-2Ial3g=.2a930bec-f4d7-406b-ac29-d64e7b106b03@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <jedU_ilFWTbEPv8RFDP9uPw7T9-tO5V_ETTw-2Ial3g=.2a930bec-f4d7-406b-ac29-d64e7b106b03@github.com>
Message-ID: <4Gh-GUmfW-r3oKKTZy5e4gQVhnVgM3HLCY5OLsA-zgg=.138198d0-0eb6-4c7a-b791-8585483f7744@github.com>

On Thu, 4 Dec 2025 13:36:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> _This patch is not intended for JDK 26_. 
>> 
>> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
>> 
>> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
>> 
>> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
>> 
>> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
>> 
>> ### Implementation Notes
>> 
>> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>>   b) 64-bit, COH on
>>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
>> 
>> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
>> 
>> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>>   
>> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
>> 
>> ### Testing
>> 
>> - tier 1 2 3 locally on Linux x64
>> - SAP ran their whole set of tests for all the platforms they support.
>> 
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8350754
>> [2...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
>   
>   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

@walulyai , @dholmes-ora ; thanks for your reviews. I incorporated the feedback.

In this PR, I will resolve comments I consider as resolved by my answer or by my fix; mostly simple stuff. Whenever I think the Reviewer should confirm my solution, or when I think he might have had something different in mind, I keep the comment open. I will from time to time resolve these old comment threads if no feedback comes on them.

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

PR Comment: https://git.openjdk.org/jdk/pull/28366#issuecomment-3871363998

From stuefe at openjdk.org  Mon Feb  9 21:35:23 2026
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 9 Feb 2026 21:35:23 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v4]
In-Reply-To: <C27hTdtvSPVlY5_SA2im3ONCPPNOloeng31CVDJI7Ok=.70867e89-be37-48d1-ba49-063a6c28ce96@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <jedU_ilFWTbEPv8RFDP9uPw7T9-tO5V_ETTw-2Ial3g=.2a930bec-f4d7-406b-ac29-d64e7b106b03@github.com>
 <C27hTdtvSPVlY5_SA2im3ONCPPNOloeng31CVDJI7Ok=.70867e89-be37-48d1-ba49-063a6c28ce96@github.com>
Message-ID: <eUCHvEbYBWdncYd3-tOx1zgDeUJY0GyV5Q6152PDZXI=.d0edfbbe-9e16-4994-84c8-a7c477b95537@github.com>

On Mon, 8 Dec 2025 04:39:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
>>   
>>   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>
> src/hotspot/share/memory/metaspace.cpp line 661:
> 
>> 659:   MaxMetaspaceSize = MAX2(MaxMetaspaceSize, commit_alignment());
>> 660: 
>> 661:   if (using_class_space()) {
> 
> Shouldn't this now just be a build-time `ifdef _LP64` check?

It is. using_class_space is true on LP64, false on 32-bit. Mostly a matter of taste. I kept the function here since it conveys more information than just a blank ifdef. And this approach (if uses as negation) minimizes compile errors on the other side since nobody bothers to build on 32-bit anymore.

I have no strong emotions, though. If reviewers prefer it, I'll replace it with a blank ifdef _LP64.

> src/hotspot/share/memory/metaspace.cpp line 728:
> 
>> 726:   }
>> 727: 
>> 728:   // a) if CDS is active (runtime, Xshare=on), it will create the class space
> 
> You have left descriptions of a) and b) but now we have no idea what they are referring to. ???

I fixed the comment. I also removed the last sentence (about placing the class space atop of the java heap) since that is not true anymore since https://bugs.openjdk.org/browse/JDK-8312018 .

> src/hotspot/share/runtime/arguments.cpp line 1591:
> 
>> 1589: 
>> 1590:       size_t heap_end = HeapBaseMinAddress + MaxHeapSize;
>> 1591:       size_t max_coop_heap = max_heap_for_compressed_oops();
> 
> Please don't change the types in this PR.

Reverted

> test/hotspot/jtreg/runtime/cds/appcds/TestCombinedCompressedFlags.java line 67:
> 
>> 65:         private void initExecArgs() {
>> 66:             // We fail this test if the UseCompressedOops setting used at dumptime differs from runtime,
>> 67:             // succeed if it is identical
> 
> This test seems to reduce to pretty much nothing. ??

Well, sure. Most of these combinations vanish if you remove compressed oops from the equation. Since it is a constant, it cannot differ between runtime and dumptime, which is what this test checks.

It leaves compressed oops, which can differ, so the test is still not empty.

> test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java line 44:
> 
>> 42:     private final static String UNABLE_TO_USE_ARCHIVE = "Unable to use shared archive.";
>> 43:     private final static String ERR_MSG = "The saved state of UseCompressedOops (0) is different from runtime (1), CDS will be disabled.";
>> 44:     private final static String COMPACT_OBJECT_HEADERS = "-XX:+UseCompactObjectHeaders";
> 
> Again this test seems to have a lot of unrelated changes. This is obscuring the actual differences and makes the review harder.

I rewrote the changes; apart from the string constants (must have been my IDE), most of the changes made sense, though.

With the removal of CompressedClassPointers switch, fewer combinations are to be tested. I removed all that tested -UseCompressedClassPointers, and removed resulting duplicates with +UseCompressedClassPointers.

Unrelated, I also removed the last check (Step 8) because it duplicates Step 1.

Unrelated and preexisting: The test does not check various combinations of UseCompactObjectHeaders, but it should. I opened https://bugs.openjdk.org/browse/JDK-8377454 to track that separately.

> test/jdk/java/lang/instrument/GetObjectSizeIntrinsicsTest.java line 318:
> 
>> 316: 
>> 317:     // Includes length, excludes alignment gap to base
>> 318:     static final int ARRAY_HEADER_SIZE = Platform.is64bit() ? 16 : 12;
> 
> Again unrelated change.

Okay. Array header size was wrong for 32-bit; just factoring CCP==true would have given a hard-coded "16" bytes, always, which seemed off, so I just fixed it. Doesn't matter for the test; just a clarity issue. 

I will reverted the change and opened https://bugs.openjdk.org/browse/JDK-8377456 to track this.

> test/jdk/jdk/jfr/event/gc/objectcount/ObjectCountEventVerifier.java line 75:
> 
>> 73:         final int bytesPerWord = runsOn32Bit ? 4 : 8;
>> 74:         final int objectHeaderSize = runsOn32Bit ? 12 : 16;
>> 75:         final int alignmentGap = runsOn32Bit ? 4 : 0;
> 
> Again unrelated changes.

I reduced the diff. Note that the reason for the change is that the tests using this utility functions all ran with -UseCompressedClassPointers for whatever reason (I assume the tests predate the class space and that when class space was introduced the simplest way to fix the test was to run them without class space). 

I changed the tests to run with +UseCompressedClassPointers, so I need to change this calculation here, too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2780955585
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2781764089
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2781767546
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2781466821
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2781791263
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2781723738
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2781992992

From stuefe at openjdk.org  Mon Feb  9 21:36:43 2026
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 9 Feb 2026 21:36:43 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v4]
In-Reply-To: <8rucmckn4tmJbeg1nUAoywL-Y9ueXAXfnAcEDCk0Uc8=.2db40fe0-c41f-4ffa-a144-a8a883ee5b6a@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <jedU_ilFWTbEPv8RFDP9uPw7T9-tO5V_ETTw-2Ial3g=.2a930bec-f4d7-406b-ac29-d64e7b106b03@github.com>
 <zFfEexmtxjovY_ScXvsWxZSqMEzbN719AAMpC4b2PYI=.50a015c8-c7ae-4ec2-a4d4-4788b8e828da@github.com>
 <8rucmckn4tmJbeg1nUAoywL-Y9ueXAXfnAcEDCk0Uc8=.2db40fe0-c41f-4ffa-a144-a8a883ee5b6a@github.com>
Message-ID: <z7plcEl0YhyknS6dTQEMV5iRSOuAetbMJ-U1r5CfZxE=.d5946184-4f4f-4e1c-b92f-f69d2ec03530@github.com>

On Mon, 9 Feb 2026 11:11:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/oops/oop.inline.hpp line 157:
>> 
>>> 155:   assert(Universe::is_bootstrapping() || (k != nullptr && k->is_klass()), "incorrect Klass");
>>> 156:   assert(!UseCompactObjectHeaders, "don't set Klass* with compact headers");
>>> 157:   _metadata._compressed_klass = CompressedKlassPointers::encode_not_null(k);
>> 
>> We might have to reconsider if we need to maintain the`union _metadata`
>
> Right you are. We only should need narrowKlass now, even on 32-bit.

Fixed: removed union, replaced with narrowKlass

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2782264128

From jbhateja at openjdk.org  Mon Feb  9 21:36:32 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 9 Feb 2026 21:36:32 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v12]
In-Reply-To: <EUYLcTJ-tPZabk2LcLzwYne6MgOdrQ7PDqkx6lOvsJs=.7c5a65d0-0efc-4636-843d-93815f327a25@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <YbIRslmURu8J4TLXTCHEeo7F3IwpvGPiYMDA-6w7_xA=.386a3af7-73ac-42f2-9e05-d34c436872a7@github.com>
 <BCaFfmFgSFPW0kPql80L-9Uic7tu5fwpnXBLpn9uyP8=.b184ac3f-faac-4062-9b15-ad07ac5fe0c0@github.com>
 <EUYLcTJ-tPZabk2LcLzwYne6MgOdrQ7PDqkx6lOvsJs=.7c5a65d0-0efc-4636-843d-93815f327a25@github.com>
Message-ID: <RGiVLE4z-2lp7y5_LjQE-eR88KmRfBt5KVui0F7ZQzU=.2e8afb32-4aa5-43b9-8105-366cd24dbb0c@github.com>

On Mon, 26 Jan 2026 17:43:41 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> LGTM! Thanks for your updating!
>
>> Hi @XiaohongGong , your comments have been addressed. Hi @sviswa7, can you kindly review x86 part.
> 
> Thanks @jatin-bhateja. I will take a look next week.

Hi @sviswa7 , @merykitty , Can you please review x86 backed implementation and approve.

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

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3869485750

From liach at openjdk.org  Mon Feb  9 21:36:06 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Feb 2026 21:36:06 GMT
Subject: RFR: 8352171: Arrays.hashCode for sub-range of byte array API
 addition [v2]
In-Reply-To: <DHO19EafD_p-lodbKi5kcbHxZfv3h8HcftSLZfz91XU=.92f7cea0-2503-4307-abb5-96d19fad3a5b@github.com>
References: <863TowvS917gG9yKE1hbDkd_CeYCwzbSm_mtAcKFTJQ=.f6a72b03-5642-493d-8d2b-48bbf4a3f8b2@github.com>
 <DHO19EafD_p-lodbKi5kcbHxZfv3h8HcftSLZfz91XU=.92f7cea0-2503-4307-abb5-96d19fad3a5b@github.com>
Message-ID: <7gQl1n-MJduqKk69EPDFI-HGRG2KcVYVXp8Ca9TXWLw=.0a399d96-8982-4704-a367-32d8d9b080bb@github.com>

On Sat, 29 Mar 2025 07:51:27 GMT, Zihao Lin <zlin at openjdk.org> wrote:

>> Add the java.util.Arrays.hashCode(byte[], int start, int end).
>> 
>> Hi team, I am new here, please give me some guidance. Thank you.
>
> Zihao Lin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into dev
>  - 8352171: Arrays.hashCode for sub-range of byte array API addition

I still think returning 0 regardless of the input range is wrong. It feels off when clearly incorrect start or end index, such as negative ones or start greater than end, results in 0 return instead of an IOOBE. I think we should reject null or treat null as 0 length to solve this inconsistency.

Also, I think a name like hashCodeOfRange serves better, like copyOfRange.

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

PR Comment: https://git.openjdk.org/jdk/pull/24128#issuecomment-3620446510
PR Comment: https://git.openjdk.org/jdk/pull/24128#issuecomment-3620447793

From zlin at openjdk.org  Mon Feb  9 21:35:33 2026
From: zlin at openjdk.org (Zihao Lin)
Date: Mon, 9 Feb 2026 21:35:33 GMT
Subject: RFR: 8352171: Arrays.hashCode for sub-range of byte array API
 addition [v3]
In-Reply-To: <863TowvS917gG9yKE1hbDkd_CeYCwzbSm_mtAcKFTJQ=.f6a72b03-5642-493d-8d2b-48bbf4a3f8b2@github.com>
References: <863TowvS917gG9yKE1hbDkd_CeYCwzbSm_mtAcKFTJQ=.f6a72b03-5642-493d-8d2b-48bbf4a3f8b2@github.com>
Message-ID: <nxrWw6FZFcRhcLcDU0VhTqy385UMeGfx-YbtS5arZ00=.94edd34b-ef09-472f-9292-71bc0cd6a4b1@github.com>

> Add the java.util.Arrays.hashCode(byte[], int start, int end).
> 
> Hi team, I am new here, please give me some guidance. Thank you.

Zihao Lin 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:

 - rename to hashCodeOfRange
 - Merge branch 'master' into dev
 - Merge branch 'openjdk:master' into dev
 - Merge branch 'openjdk:master' into dev
 - 8352171: Arrays.hashCode for sub-range of byte array API addition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24128/files
  - new: https://git.openjdk.org/jdk/pull/24128/files/57298dc4..25c1765b

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

  Stats: 1315600 lines in 13996 files changed: 758430 ins; 415629 del; 141541 mod
  Patch: https://git.openjdk.org/jdk/pull/24128.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24128/head:pull/24128

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

From stuefe at openjdk.org  Mon Feb  9 21:37:00 2026
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 9 Feb 2026 21:37:00 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v5]
In-Reply-To: <C27hTdtvSPVlY5_SA2im3ONCPPNOloeng31CVDJI7Ok=.70867e89-be37-48d1-ba49-063a6c28ce96@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <jedU_ilFWTbEPv8RFDP9uPw7T9-tO5V_ETTw-2Ial3g=.2a930bec-f4d7-406b-ac29-d64e7b106b03@github.com>
 <C27hTdtvSPVlY5_SA2im3ONCPPNOloeng31CVDJI7Ok=.70867e89-be37-48d1-ba49-063a6c28ce96@github.com>
Message-ID: <ydgTA4xtqdUB9VMypMIyqhrJo4GgjHMq6SCj8OAhYaM=.05f27170-deaa-4fef-9b15-b762495d21ef@github.com>

On Mon, 8 Dec 2025 05:01:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:
>> 
>>  - Replace Klass::_metadata union with narrowKlass member
>>  - Ivan: fix various instances of ObjLayout::undefined should assert
>>  - Ivan: Update src/hotspot/share/oops/instanceKlass.cpp
>>    
>>    Co-authored-by: Ivan Walulya <ivan.walulya at oracle.com>
>>  - David: reduce diff in ObjectCountEventVerifier.java
>>  - David: minimize change in GetObjectSizeIntrinsicsTest.java
>>  - David: minimize diffs in TestZGCWithCDS.java
>>  - David: minimize diffs for runtime/ErrorHandling/TestVMConfigInHsErrFile.java
>>  - David: revert type change in arguments.cpp
>>  - David: fix comment in metaspace
>>  - Merge branch 'master' into JDK-8363996-Obsolete-UseCompressedClassPointers
>>  - ... and 52 more: https://git.openjdk.org/jdk/compare/ffb6279c...642604ac
>
> test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java line 294:
> 
>> 292:     }
>> 293: 
>> 294:     public static void heapBaseMinAddressTestNoCoop() throws Exception {
> 
> It is not obvious to me why this test case was deleted.

Related to the change here: https://github.com/openjdk/jdk/pull/28366/changes#diff-027490ce3f4a92be9b489d9d2e54c7baaea87b7489399b198543c79f1ce1e2e3L1576

This test only worked by accident, and never made sense. 

`HeapBaseMinAddress`: in `+UseCompressedOops` mode, it forces the heap to this address (arguably, the name is a misnomer); failing that, it will treat it as a low barrier in further reservation attempts. But not always: if we cannot get any preferred address, we will use whatever address the OS gives us, which may be lower than a high value for `HeapBaseMinAddress`. (Writing this now, I think that should be a bug).

In `-UseCompressedClassPointers` mode, the flag does nothing. The test always worked because the value of 1M is so low that no OS will accidentally map into that area.

---

Note that it's a different question of whether we *should* honor the flag for `-UseCompressedOops +UseCompressedClassPointers`. Could a barrier like that be useful to keep the heap away from low-address regions to increase the chance for a low-address class space? But looking closely, probably not worth it for two reasons: on all 64-bit platforms, the chance of "OS-determined" mappings to hit the low address regions < 32GB is so rare its not worth the complexity. And low-address heap is more useful performance-wise than low-address class space anyway.

> test/hotspot/jtreg/runtime/ErrorHandling/TestVMConfigInHsErrFile.java line 59:
> 
>> 57:     switch (args[0]) {
>> 58:       case "coh-on" -> testCompactObjectHeaders();
>> 59:       case "coh-off" -> testCompressedClassPointers();
> 
> You seem to have done a complete test rewrite here and it is not obvious to me it follows as part of the obsoletion of UCCP.

Okay, I reverted most of my changes and kept the diff minimal. The test could be cut down a lot more, though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2781257967
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2781772213

From stuefe at openjdk.org  Mon Feb  9 21:36:31 2026
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 9 Feb 2026 21:36:31 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v4]
In-Reply-To: <zFfEexmtxjovY_ScXvsWxZSqMEzbN719AAMpC4b2PYI=.50a015c8-c7ae-4ec2-a4d4-4788b8e828da@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <jedU_ilFWTbEPv8RFDP9uPw7T9-tO5V_ETTw-2Ial3g=.2a930bec-f4d7-406b-ac29-d64e7b106b03@github.com>
 <zFfEexmtxjovY_ScXvsWxZSqMEzbN719AAMpC4b2PYI=.50a015c8-c7ae-4ec2-a4d4-4788b8e828da@github.com>
Message-ID: <8rucmckn4tmJbeg1nUAoywL-Y9ueXAXfnAcEDCk0Uc8=.2db40fe0-c41f-4ffa-a144-a8a883ee5b6a@github.com>

On Mon, 8 Dec 2025 13:26:59 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
>>   
>>   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>
> src/hotspot/share/oops/oop.inline.hpp line 104:
> 
>> 102:       return CompressedKlassPointers::decode_not_null(_metadata._compressed_klass);
>> 103:     default:
>> 104:       return _metadata._klass;
> 
> Suggestion:
> 
>       ShouldNotReachHere();

Fixed

> src/hotspot/share/oops/oop.inline.hpp line 115:
> 
>> 113:       return CompressedKlassPointers::decode(_metadata._compressed_klass);
>> 114:     default:
>> 115:       return _metadata._klass;
> 
> Suggestion:
> 
>       ShouldNotReachHere();

Fixed

> src/hotspot/share/oops/oop.inline.hpp line 128:
> 
>> 126:     }
>> 127:     default:
>> 128:       return AtomicAccess::load_acquire(&_metadata._klass);
> 
> Suggestion:
> 
>       ShouldNotReachHere();

Fixed

> src/hotspot/share/oops/oop.inline.hpp line 139:
> 
>> 137:       return CompressedKlassPointers::decode_without_asserts(_metadata._compressed_klass);
>> 138:     default:
>> 139:       return _metadata._klass;
> 
> klass_mode() is either `Compact` or `Compressed`
> Should be changed to:
> Suggestion:
> 
>       ShouldNotReachHere();

Fixed

> src/hotspot/share/oops/oop.inline.hpp line 157:
> 
>> 155:   assert(Universe::is_bootstrapping() || (k != nullptr && k->is_klass()), "incorrect Klass");
>> 156:   assert(!UseCompactObjectHeaders, "don't set Klass* with compact headers");
>> 157:   _metadata._compressed_klass = CompressedKlassPointers::encode_not_null(k);
> 
> We might have to reconsider if we need to maintain the`union _metadata`

Right you are. We only should need narrowKlass now, even on 32-bit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2782264507
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2782265537
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2782263749
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2782263330
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2782039682

From stuefe at openjdk.org  Mon Feb  9 21:37:05 2026
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 9 Feb 2026 21:37:05 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v5]
In-Reply-To: <ydgTA4xtqdUB9VMypMIyqhrJo4GgjHMq6SCj8OAhYaM=.05f27170-deaa-4fef-9b15-b762495d21ef@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <jedU_ilFWTbEPv8RFDP9uPw7T9-tO5V_ETTw-2Ial3g=.2a930bec-f4d7-406b-ac29-d64e7b106b03@github.com>
 <C27hTdtvSPVlY5_SA2im3ONCPPNOloeng31CVDJI7Ok=.70867e89-be37-48d1-ba49-063a6c28ce96@github.com>
 <ydgTA4xtqdUB9VMypMIyqhrJo4GgjHMq6SCj8OAhYaM=.05f27170-deaa-4fef-9b15-b762495d21ef@github.com>
Message-ID: <_dauNOIJumNvUBbMmYK9BmuST2rdwyB3iRJLRcJ3JxA=.1da49fbf-6ff9-4a6d-9f12-afded3ce0ac3@github.com>

On Mon, 9 Feb 2026 08:25:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java line 294:
>> 
>>> 292:     }
>>> 293: 
>>> 294:     public static void heapBaseMinAddressTestNoCoop() throws Exception {
>> 
>> It is not obvious to me why this test case was deleted.
>
> Related to the change here: https://github.com/openjdk/jdk/pull/28366/changes#diff-027490ce3f4a92be9b489d9d2e54c7baaea87b7489399b198543c79f1ce1e2e3L1576
> 
> This test only worked by accident, and never made sense. 
> 
> `HeapBaseMinAddress`: in `+UseCompressedOops` mode, it forces the heap to this address (arguably, the name is a misnomer); failing that, it will treat it as a low barrier in further reservation attempts. But not always: if we cannot get any preferred address, we will use whatever address the OS gives us, which may be lower than a high value for `HeapBaseMinAddress`. (Writing this now, I think that should be a bug).
> 
> In `-UseCompressedClassPointers` mode, the flag does nothing. The test always worked because the value of 1M is so low that no OS will accidentally map into that area.
> 
> ---
> 
> Note that it's a different question of whether we *should* honor the flag for `-UseCompressedOops +UseCompressedClassPointers`. Could a barrier like that be useful to keep the heap away from low-address regions to increase the chance for a low-address class space? But looking closely, probably not worth it for two reasons: on all 64-bit platforms, the chance of "OS-determined" mappings to hit the low address regions < 32GB is so rare its not worth the complexity. And low-address heap is more useful performance-wise than low-address class space anyway.

I opened https://bugs.openjdk.org/browse/JDK-8377452 to track a possible change to HeapBaseMinAddress.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2781575093

From missa at openjdk.org  Mon Feb  9 21:38:02 2026
From: missa at openjdk.org (Mohamed Issa)
Date: Mon, 9 Feb 2026 21:38:02 GMT
Subject: Integrated: 8371955: Support AVX10 floating point comparison
 instructions
In-Reply-To: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>
References: <xDRJgBQwsegqBOp50pIl-Mzkadb8U-QpYXxSv01Jaxc=.a4cd1675-eb08-4f08-87be-c7f66a88f37e@github.com>
Message-ID: <SbREpUspGgUy66LaHVt7gKTXwNL-kHTpCF0_cL7UgnM=.4efc3bae-e8d0-45b9-be0f-0b00f8dec899@github.com>

On Sun, 16 Nov 2025 03:48:31 GMT, Mohamed Issa <missa at openjdk.org> wrote:

> Intel&reg; AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN.
> 
> Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added.
> 
> This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26).
> 
> 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java`
> 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java`
> 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java`
> 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java`
> 
> Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths.
> 
> 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java`
> 
> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10

This pull request has now been integrated.

Changeset: 161aa5d5
Author:    Mohamed Issa <missa at openjdk.org>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/161aa5d52865295059f9506b2ba4ffc4b98324de
Stats:     876 lines in 10 files changed: 677 ins; 105 del; 94 mod

8371955: Support AVX10 floating point comparison instructions

Reviewed-by: epeter, sviswanathan, sparasa

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

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

From cjplummer at openjdk.org  Mon Feb  9 21:39:04 2026
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 9 Feb 2026 21:39:04 GMT
Subject: RFR: 8376533: Remove test dependencies on ReferenceQueue$Lock in
 preparation for JDK-8376477
In-Reply-To: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com>
References: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com>
Message-ID: <lkzd6kzWH--Hpp_SAZaAVZCCtO8Je9INggzDPnB3JRs=.a2ff8302-17b5-4917-8445-7186a6af20b8@github.com>

On Tue, 27 Jan 2026 21:11:05 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which updates a few JDK tests to not depend on the existence of `java.lang.ref.ReferenceQueue$Lock` and `java.lang.Shutdown$Lock` classes. These are suggested for removal in JDK-8376477, see #29442.
> 
> * `ClhsdbInspect` is updated to use add a nested Lock class in the sample app and use that instead.
> * `ConcurrentAssociateTest` and `Phaser/Basic` are updated to not use lock name when filtering threads to dump for debugging purposes when failing.
> * `ImageReaderBenchmark` micro is updated to remove these classes from the list of expected system image resource names
> 
> I have verified that these tests now run with or without the `Lock` classes present in the JDK. I called the thread dump debug methods manually to verify them since these only run on test failure. GHA run passes.
> 
> Test only change/cleanup. `noreg-self`

SA changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29455#pullrequestreview-3764065817

From eirbjo at openjdk.org  Mon Feb  9 21:39:05 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 9 Feb 2026 21:39:05 GMT
Subject: RFR: 8376533: Remove test dependencies on ReferenceQueue$Lock in
 preparation for JDK-8376477
In-Reply-To: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com>
References: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com>
Message-ID: <H8QHtXu_q1ri9ZNhfY2OSLIXPLvBz-LTbVeYcojnnLo=.8745d74d-0f3e-48c3-97f3-0e093b0026c3@github.com>

On Tue, 27 Jan 2026 21:11:05 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which updates a few JDK tests to not depend on the existence of `java.lang.ref.ReferenceQueue$Lock` and `java.lang.Shutdown$Lock` classes. These are suggested for removal in JDK-8376477, see #29442.
> 
> * `ClhsdbInspect` is updated to use add a nested Lock class in the sample app and use that instead.
> * `ConcurrentAssociateTest` and `Phaser/Basic` are updated to not use lock name when filtering threads to dump for debugging purposes when failing.
> * `ImageReaderBenchmark` micro is updated to remove these classes from the list of expected system image resource names
> 
> I have verified that these tests now run with or without the `Lock` classes present in the JDK. I called the thread dump debug methods manually to verify them since these only run on test failure. GHA run passes.
> 
> Test only change/cleanup. `noreg-self`

Thanks to reviewers for "unlocking" this test cleanup PR :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/29455#issuecomment-3861582795

From swen at openjdk.org  Mon Feb  9 21:40:23 2026
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 9 Feb 2026 21:40:23 GMT
Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and
 parseLong [v28]
In-Reply-To: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
References: <QV_vC9a_Kig5yg-DK1-CUElOpTkKCeYHSHsIIxDcCIU=.88f24419-9cba-458b-bbca-50f0a8b19c0c@github.com>
Message-ID: <AaEvgacAXbfOMAGPr68TSkG28ocHAbpKtZB01ssLwAQ=.b4ff749d-3763-46fb-a8d5-5b8eedc3f7dc@github.com>

> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes:
> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3.
> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1.
> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses.

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

  Optimize parseInt/parseLong by inlining digit2 logic
  
  - Inline DecimalDigits.digit2() to avoid method call overhead
  - Remove dependency on lookup tables, use direct calculation
  - Simplify conditional checks in parsing loops
  - CodeSize remains < 325 (JIT inlineable)
  - Performance: Integer.parseInt +6.7%, Long.parseLong +7.1%
  
  Co-authored-by: Qwen-Coder <qwen-coder at alibabacloud.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22919/files
  - new: https://git.openjdk.org/jdk/pull/22919/files/54a2cbee..1a885c85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=26-27

  Stats: 24 lines in 2 files changed: 12 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/22919.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919

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

From eirbjo at openjdk.org  Mon Feb  9 21:39:06 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 9 Feb 2026 21:39:06 GMT
Subject: Integrated: 8376533: Remove test dependencies on ReferenceQueue$Lock
 in preparation for JDK-8376477
In-Reply-To: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com>
References: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com>
Message-ID: <txebarakGaZIuUjtS1an6qMi-8C4VcAo2ar3vA_-KpI=.6b6a3f03-365a-4ae2-bafe-95888a0d3949@github.com>

On Tue, 27 Jan 2026 21:11:05 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which updates a few JDK tests to not depend on the existence of `java.lang.ref.ReferenceQueue$Lock` and `java.lang.Shutdown$Lock` classes. These are suggested for removal in JDK-8376477, see #29442.
> 
> * `ClhsdbInspect` is updated to use add a nested Lock class in the sample app and use that instead.
> * `ConcurrentAssociateTest` and `Phaser/Basic` are updated to not use lock name when filtering threads to dump for debugging purposes when failing.
> * `ImageReaderBenchmark` micro is updated to remove these classes from the list of expected system image resource names
> 
> I have verified that these tests now run with or without the `Lock` classes present in the JDK. I called the thread dump debug methods manually to verify them since these only run on test failure. GHA run passes.
> 
> Test only change/cleanup. `noreg-self`

This pull request has now been integrated.

Changeset: 986d3772
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/986d3772248098c0ba845861611a5a4ceb7b645a
Stats:     26 lines in 5 files changed: 6 ins; 8 del; 12 mod

8376533: Remove test dependencies on ReferenceQueue$Lock in preparation for JDK-8376477

Reviewed-by: rriggs, shade, cjplummer

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

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

From asemenyuk at openjdk.org  Mon Feb  9 21:39:57 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 9 Feb 2026 21:39:57 GMT
Subject: RFR: 8377331: jpackage: improve sign errors reporting [v2]
In-Reply-To: <aMN_gHTEJE_vS1-K4OdtnVQDSouYr6C4dd-g28RVjIs=.8a86e58a-6972-46a2-a778-e01a7685bc39@github.com>
References: <aMN_gHTEJE_vS1-K4OdtnVQDSouYr6C4dd-g28RVjIs=.8a86e58a-6972-46a2-a778-e01a7685bc39@github.com>
Message-ID: <J6ub2Tv0GLdptE7yAX6AyP8ag799HkvzwTUQHSzxjHA=.cfbb04b9-8b69-4b7e-9f94-407336d8f228@github.com>

> Improve reporting of errors from failed external commands, and signing errors in particular. Use the same formatting for signing errors as for any other errors.
> 
> Instead of printing:
> 
> "codesign" failed with following output:
> jpackage-tests/MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: replacing existing signature
> jpackage-tests/MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: bundle format unrecognized, invalid, or unsuitable
> In subcomponent: jpackage-tests/MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app/Contents/foo.1
> jdk.jpackage.internal.util.function.ExceptionBox: jdk.jpackage.internal.Codesign$CodesignException
>         at jdk.jpackage/jdk.jpackage.internal.util.function.ExceptionBox.toUnchecked(ExceptionBox.java:51)
>         <stack trace omitted>
> Error: jdk.jpackage.internal.Codesign$CodesignException
> 
> 
> jpackage will print:
> 
> Error: Unexpected exit code 1 from executing the command /usr/bin/codesign -s 'Developer ID Application: jpackage.openjdk.java.net' -vvvv --timestamp --options runtime --prefix Hello. --keychain jpackagerTest.keychain --entitlements config/AppContentWarningMacSignTest.entitlements --force MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app
> Command output:
> MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: replacing existing signature
> MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: bundle format unrecognized, invalid, or unsuitable
> In subcomponent: MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app/Contents/foo.1
> 
> 
> As for reporting generic errors from failed external commands, jpackage will always print the command's output, regardless of whether it is running in verbose or quiet mode. Previously, it would print command output only in quiet mode, assuming that in verbose mode, the output would be printed immediately after command execution. However, jpackage runs some commands quietly in verbose mode; if one of them failed, the user didn't see its output. To address this problem, jpackage will print the output of the failed command in both quiet and verbose modes.

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

  Replace "verify" with "validate" in the new code.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29596/files
  - new: https://git.openjdk.org/jdk/pull/29596/files/3d33dd75..2b0533f5

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

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

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

From almatvee at openjdk.org  Mon Feb  9 21:39:58 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 9 Feb 2026 21:39:58 GMT
Subject: RFR: 8377331: jpackage: improve sign errors reporting [v2]
In-Reply-To: <J6ub2Tv0GLdptE7yAX6AyP8ag799HkvzwTUQHSzxjHA=.cfbb04b9-8b69-4b7e-9f94-407336d8f228@github.com>
References: <aMN_gHTEJE_vS1-K4OdtnVQDSouYr6C4dd-g28RVjIs=.8a86e58a-6972-46a2-a778-e01a7685bc39@github.com>
 <J6ub2Tv0GLdptE7yAX6AyP8ag799HkvzwTUQHSzxjHA=.cfbb04b9-8b69-4b7e-9f94-407336d8f228@github.com>
Message-ID: <hBpy9kM7mKlfGOEq3QeenXm5VZISpCnE1rCUKicWH-0=.093c95fd-2e06-4595-9f4c-d28e8d850c17@github.com>

On Sat, 7 Feb 2026 03:27:34 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Improve reporting of errors from failed external commands, and signing errors in particular. Use the same formatting for signing errors as for any other errors.
>> 
>> Instead of printing:
>> 
>> "codesign" failed with following output:
>> jpackage-tests/MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: replacing existing signature
>> jpackage-tests/MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: bundle format unrecognized, invalid, or unsuitable
>> In subcomponent: jpackage-tests/MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app/Contents/foo.1
>> jdk.jpackage.internal.util.function.ExceptionBox: jdk.jpackage.internal.Codesign$CodesignException
>>         at jdk.jpackage/jdk.jpackage.internal.util.function.ExceptionBox.toUnchecked(ExceptionBox.java:51)
>>         <stack trace omitted>
>> Error: jdk.jpackage.internal.Codesign$CodesignException
>> 
>> 
>> jpackage will print:
>> 
>> Error: Unexpected exit code 1 from executing the command /usr/bin/codesign -s 'Developer ID Application: jpackage.openjdk.java.net' -vvvv --timestamp --options runtime --prefix Hello. --keychain jpackagerTest.keychain --entitlements config/AppContentWarningMacSignTest.entitlements --force MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app
>> Command output:
>> MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: replacing existing signature
>> MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: bundle format unrecognized, invalid, or unsuitable
>> In subcomponent: MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app/Contents/foo.1
>> 
>> 
>> As for reporting generic errors from failed external commands, jpackage will always print the command's output, regardless of whether it is running in verbose or quiet mode. Previously, it would print command output only in quiet mode, assuming that in verbose mode, the output would be printed immediately after command execution. However, jpackage runs some commands quietly in verbose mode; if one of them failed, the user didn't see its output. To address this problem, jpackage will print the output of the failed command in both quiet and verbose modes.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace "verify" with "validate" in the new code.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29596#pullrequestreview-3765931710

From asemenyuk at openjdk.org  Mon Feb  9 21:40:01 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 9 Feb 2026 21:40:01 GMT
Subject: Integrated: 8377331: jpackage: improve sign errors reporting
In-Reply-To: <aMN_gHTEJE_vS1-K4OdtnVQDSouYr6C4dd-g28RVjIs=.8a86e58a-6972-46a2-a778-e01a7685bc39@github.com>
References: <aMN_gHTEJE_vS1-K4OdtnVQDSouYr6C4dd-g28RVjIs=.8a86e58a-6972-46a2-a778-e01a7685bc39@github.com>
Message-ID: <J41G_iZORAylaH0HEhBmA5i-cR0I5xKFrYfkKeeEU3g=.e5f13a4e-6eb6-410f-9b4d-4a869eb4a05b@github.com>

On Thu, 5 Feb 2026 23:23:28 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Improve reporting of errors from failed external commands, and signing errors in particular. Use the same formatting for signing errors as for any other errors.
> 
> Instead of printing:
> 
> "codesign" failed with following output:
> jpackage-tests/MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: replacing existing signature
> jpackage-tests/MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: bundle format unrecognized, invalid, or unsuitable
> In subcomponent: jpackage-tests/MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app/Contents/foo.1
> jdk.jpackage.internal.util.function.ExceptionBox: jdk.jpackage.internal.Codesign$CodesignException
>         at jdk.jpackage/jdk.jpackage.internal.util.function.ExceptionBox.toUnchecked(ExceptionBox.java:51)
>         <stack trace omitted>
> Error: jdk.jpackage.internal.Codesign$CodesignException
> 
> 
> jpackage will print:
> 
> Error: Unexpected exit code 1 from executing the command /usr/bin/codesign -s 'Developer ID Application: jpackage.openjdk.java.net' -vvvv --timestamp --options runtime --prefix Hello. --keychain jpackagerTest.keychain --entitlements config/AppContentWarningMacSignTest.entitlements --force MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app
> Command output:
> MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: replacing existing signature
> MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app: bundle format unrecognized, invalid, or unsuitable
> In subcomponent: MacSignTest/testAppContentWarning/output/AppContentWarningMacSignTest.app/Contents/foo.1
> 
> 
> As for reporting generic errors from failed external commands, jpackage will always print the command's output, regardless of whether it is running in verbose or quiet mode. Previously, it would print command output only in quiet mode, assuming that in verbose mode, the output would be printed immediately after command execution. However, jpackage runs some commands quietly in verbose mode; if one of them failed, the user didn't see its output. To address this problem, jpackage will print the output of the failed command in both quiet and verbose modes.

This pull request has now been integrated.

Changeset: 5152fdcd
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5152fdcd490412025ba5f608378982abc1eadc07
Stats:     276 lines in 10 files changed: 203 ins; 33 del; 40 mod

8377331: jpackage: improve sign errors reporting

Reviewed-by: almatvee

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

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

From asemenyuk at openjdk.org  Mon Feb  9 22:00:51 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 9 Feb 2026 22:00:51 GMT
Subject: Integrated: 8377392: jpackage: Fix member function called from the
 CfgFile.Referencies compact canonical constructor
Message-ID: <u4hwlJ66Q6_qagIJGQStoWR869rCkYHWnfDl2sBe27o=.aecf93a2-ddbe-4dee-8c63-05288dd8f47e@github.com>

$subj. Somehow, it will be a problem when JEP 401 is integrated. So get it fixed beforehand.

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

Commit messages:
 - 8377392: jpackage: Fix member function called from the CfgFile.Referencies compact canonical constructor

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

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

From varadam at openjdk.org  Mon Feb  9 22:00:07 2026
From: varadam at openjdk.org (Varada M)
Date: Mon, 9 Feb 2026 22:00:07 GMT
Subject: RFR: 8377355: VectorAPI source generation broken after JDK-8371187
Message-ID: <ufXKssaCGB9gmWLWeWxyGdkkBIlGpaKp824niSfInXA=.18d63ded-551b-487e-a67e-00d7d7bc6369@github.com>

Added the missing definition of 'swapIfNeeded' in X-Vector.java.template 

JBS : [JDK-8377355](https://bugs.openjdk.org/browse/JDK-8377355)

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

Commit messages:
 - JDK-8377355: VectorAPI source generation broken after JDK-8371187
 - JDK-8377355: VectorAPI source generation broken after JDK-8371187

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

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

From liach at openjdk.org  Mon Feb  9 22:00:52 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Feb 2026 22:00:52 GMT
Subject: Integrated: 8377392: jpackage: Fix member function called from the
 CfgFile.Referencies compact canonical constructor
In-Reply-To: <u4hwlJ66Q6_qagIJGQStoWR869rCkYHWnfDl2sBe27o=.aecf93a2-ddbe-4dee-8c63-05288dd8f47e@github.com>
References: <u4hwlJ66Q6_qagIJGQStoWR869rCkYHWnfDl2sBe27o=.aecf93a2-ddbe-4dee-8c63-05288dd8f47e@github.com>
Message-ID: <aUtwougJpCkYBxCAp63zOLnkqnaXvj0EsRAzW5C3qxI=.bd314449-8b7c-40b7-9803-f1d67f866854@github.com>

On Fri, 6 Feb 2026 20:11:28 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> $subj. Somehow, it will be a problem when JEP 401 is integrated. So get it fixed beforehand.

Thanks for this extremely swift fix!

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29615#pullrequestreview-3765037339

From liach at openjdk.org  Mon Feb  9 22:00:13 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Feb 2026 22:00:13 GMT
Subject: RFR: 8377355: VectorAPI source generation broken after JDK-8371187
In-Reply-To: <ufXKssaCGB9gmWLWeWxyGdkkBIlGpaKp824niSfInXA=.18d63ded-551b-487e-a67e-00d7d7bc6369@github.com>
References: <ufXKssaCGB9gmWLWeWxyGdkkBIlGpaKp824niSfInXA=.18d63ded-551b-487e-a67e-00d7d7bc6369@github.com>
Message-ID: <1bXilOxtJCU8PQfVtJa8o1N3yP7kMf4g8EdRt91XHZc=.1ebb2db5-3a5d-4bbb-bce5-1a901923ee8a@github.com>

On Fri, 6 Feb 2026 20:33:32 GMT, Varada M <varadam at openjdk.org> wrote:

> Added the missing definition of 'swapIfNeeded' in X-Vector.java.template 
> 
> JBS : [JDK-8377355](https://bugs.openjdk.org/browse/JDK-8377355)

LGTM, the code is now identical from running the script.

Please wait for another reviewer.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 5396:

> 5394:     }
> 5395: 
> 5396:     @Override

In `ByteVector` there is a `/*package-private*/` comment between these lines.
This is not in the other files.

Can you either:

1. Remove that redundant comment from ByteVector, or
2. Add it here + in non-ByteVector classes

for consistency?

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29616#pullrequestreview-3773093551
PR Review Comment: https://git.openjdk.org/jdk/pull/29616#discussion_r2777580127

From almatvee at openjdk.org  Mon Feb  9 22:00:54 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 9 Feb 2026 22:00:54 GMT
Subject: Integrated: 8377392: jpackage: Fix member function called from the
 CfgFile.Referencies compact canonical constructor
In-Reply-To: <u4hwlJ66Q6_qagIJGQStoWR869rCkYHWnfDl2sBe27o=.aecf93a2-ddbe-4dee-8c63-05288dd8f47e@github.com>
References: <u4hwlJ66Q6_qagIJGQStoWR869rCkYHWnfDl2sBe27o=.aecf93a2-ddbe-4dee-8c63-05288dd8f47e@github.com>
Message-ID: <6iSgF6iy6laZz19Y8kdEpQcF-Weh739S_tGwkP-erfQ=.9f5c8d11-dfc6-4982-8e92-164254493fc9@github.com>

On Fri, 6 Feb 2026 20:11:28 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> $subj. Somehow, it will be a problem when JEP 401 is integrated. So get it fixed beforehand.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29615#pullrequestreview-3765559980

From varadam at openjdk.org  Mon Feb  9 22:00:19 2026
From: varadam at openjdk.org (Varada M)
Date: Mon, 9 Feb 2026 22:00:19 GMT
Subject: RFR: 8377355: VectorAPI source generation broken after JDK-8371187
In-Reply-To: <1bXilOxtJCU8PQfVtJa8o1N3yP7kMf4g8EdRt91XHZc=.1ebb2db5-3a5d-4bbb-bce5-1a901923ee8a@github.com>
References: <ufXKssaCGB9gmWLWeWxyGdkkBIlGpaKp824niSfInXA=.18d63ded-551b-487e-a67e-00d7d7bc6369@github.com>
 <1bXilOxtJCU8PQfVtJa8o1N3yP7kMf4g8EdRt91XHZc=.1ebb2db5-3a5d-4bbb-bce5-1a901923ee8a@github.com>
Message-ID: <SLM6zolaYwNeqrj5z28cd-U3hZ-IqX31ODFAGrA4AEI=.83ec2fb1-824e-4aea-968c-d1c3a292e373@github.com>

On Sat, 7 Feb 2026 13:56:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Added the missing definition of 'swapIfNeeded' in X-Vector.java.template 
>> 
>> JBS : [JDK-8377355](https://bugs.openjdk.org/browse/JDK-8377355)
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 5396:
> 
>> 5394:     }
>> 5395: 
>> 5396:     @Override
> 
> In `ByteVector` there is a `/*package-private*/` comment between these lines.
> This is not in the other files.
> 
> Can you either:
> 
> 1. Remove that redundant comment from ByteVector, or
> 2. Add it here + in non-ByteVector classes
> 
> for consistency?

I have removed the line from ByteVector

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29616#discussion_r2780914756

From asemenyuk at openjdk.org  Mon Feb  9 22:00:56 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 9 Feb 2026 22:00:56 GMT
Subject: Integrated: 8377392: jpackage: Fix member function called from the
 CfgFile.Referencies compact canonical constructor
In-Reply-To: <u4hwlJ66Q6_qagIJGQStoWR869rCkYHWnfDl2sBe27o=.aecf93a2-ddbe-4dee-8c63-05288dd8f47e@github.com>
References: <u4hwlJ66Q6_qagIJGQStoWR869rCkYHWnfDl2sBe27o=.aecf93a2-ddbe-4dee-8c63-05288dd8f47e@github.com>
Message-ID: <3apUdKx2lrzA1FNZW3ciEsXqa5JC0wOUPvgJDzujk9I=.2a008382-5f8e-4991-8ca8-053559f990ef@github.com>

On Fri, 6 Feb 2026 20:11:28 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> $subj. Somehow, it will be a problem when JEP 401 is integrated. So get it fixed beforehand.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/29615#issuecomment-3862909033

From asemenyuk at openjdk.org  Mon Feb  9 22:00:58 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 9 Feb 2026 22:00:58 GMT
Subject: Integrated: 8377392: jpackage: Fix member function called from the
 CfgFile.Referencies compact canonical constructor
In-Reply-To: <u4hwlJ66Q6_qagIJGQStoWR869rCkYHWnfDl2sBe27o=.aecf93a2-ddbe-4dee-8c63-05288dd8f47e@github.com>
References: <u4hwlJ66Q6_qagIJGQStoWR869rCkYHWnfDl2sBe27o=.aecf93a2-ddbe-4dee-8c63-05288dd8f47e@github.com>
Message-ID: <qhTHCfdI3rKGN2Iw-JkJwM-ff0ZmHE_Gc7EIBRzBmDs=.9e93ed2e-41fa-4324-a28a-9aaa7767aae4@github.com>

On Fri, 6 Feb 2026 20:11:28 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> $subj. Somehow, it will be a problem when JEP 401 is integrated. So get it fixed beforehand.

This pull request has now been integrated.

Changeset: 40bf0870
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/40bf0870f788c142f0eb1c2bfbda540ae4a93a08
Stats:     7 lines in 1 file changed: 0 ins; 2 del; 5 mod

8377392: jpackage: Fix member function called from the CfgFile.Referencies compact canonical constructor

Reviewed-by: liach, almatvee

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

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

From almatvee at openjdk.org  Mon Feb  9 22:31:08 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 9 Feb 2026 22:31:08 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v9]
In-Reply-To: <tQbyPxMApNvyu3AUHKl4nbQKYWkoE1ddcosJ9vtq7pg=.e92ce8ca-6579-4e56-9369-581915d40ecb@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <C-8YiKlI0uge38gLDeQRdo7lsr2HBF7PcP0sIkLXLog=.1f55a466-228b-46cc-b444-0bfb21653f9e@github.com>
 <tQbyPxMApNvyu3AUHKl4nbQKYWkoE1ddcosJ9vtq7pg=.e92ce8ca-6579-4e56-9369-581915d40ecb@github.com>
Message-ID: <l1QvX5W43CtmPXEQ1RM0Oo3JILLmLqx18iWINXjUWcw=.ad4bf49a-177a-4417-a95a-09abddccb53e@github.com>

On Thu, 5 Feb 2026 15:35:56 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v8]
>
> test/jdk/tools/jpackage/share/NoMPathRuntimeTest.java line 99:
> 
>> 97:                 Files.createDirectories(workDir.resolve("Contents/MacOS"));
>> 98:             }
>> 99:         }
> 
> I don't understand the comment. Why is this change?

`MacBundle.fromPath()` will fail if we do not have at least "Contents/Home", "Contents/Info.plist" and "Contents/MacOS". `ModuleInfo.fromCookedRuntime()` will be called from this test and it will fail as a result, since `MacBundle.fromPath()` will consider provided by test runtime as image.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2784845661

From asemenyuk at openjdk.org  Tue Feb 10 00:21:11 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 10 Feb 2026 00:21:11 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v9]
In-Reply-To: <l1QvX5W43CtmPXEQ1RM0Oo3JILLmLqx18iWINXjUWcw=.ad4bf49a-177a-4417-a95a-09abddccb53e@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <C-8YiKlI0uge38gLDeQRdo7lsr2HBF7PcP0sIkLXLog=.1f55a466-228b-46cc-b444-0bfb21653f9e@github.com>
 <tQbyPxMApNvyu3AUHKl4nbQKYWkoE1ddcosJ9vtq7pg=.e92ce8ca-6579-4e56-9369-581915d40ecb@github.com>
 <l1QvX5W43CtmPXEQ1RM0Oo3JILLmLqx18iWINXjUWcw=.ad4bf49a-177a-4417-a95a-09abddccb53e@github.com>
Message-ID: <zkIZRRQQbSPQiCLh1vqY77EwWUmrTou2cGQElBsXKAE=.6b21a634-d1f1-4d4d-a50f-88cd64e3a69d@github.com>

On Mon, 9 Feb 2026 22:28:27 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> test/jdk/tools/jpackage/share/NoMPathRuntimeTest.java line 99:
>> 
>>> 97:                 Files.createDirectories(workDir.resolve("Contents/MacOS"));
>>> 98:             }
>>> 99:         }
>> 
>> I don't understand the comment. Why is this change?
>
> `MacBundle.fromPath()` will fail if we do not have at least "Contents/Home", "Contents/Info.plist" and "Contents/MacOS". `ModuleInfo.fromCookedRuntime()` will be called from this test and it will fail as a result, since `MacBundle.fromPath()` will consider provided by test runtime as image.

Oh, so this is a bug in the test. Would you accept an alternative patch that refactors the test?
[NoMPathRuntimeTest.java.patch](https://github.com/user-attachments/files/25196864/NoMPathRuntimeTest.java.patch)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2785168298

From vklang at openjdk.org  Tue Feb 10 00:29:30 2026
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 10 Feb 2026 00:29:30 GMT
Subject: RFR: 8377411:
 java/lang/Thread/virtual/stress/ParkAfterTimedPark.java only testing pinned
 case
In-Reply-To: <8qZaQWwThjatuQE08vr5VRg_kA7bAjcgjAr1i-MEuDQ=.8a8e05f6-d483-428a-a3e4-65d9d4b08a95@github.com>
References: <8qZaQWwThjatuQE08vr5VRg_kA7bAjcgjAr1i-MEuDQ=.8a8e05f6-d483-428a-a3e4-65d9d4b08a95@github.com>
Message-ID: <EJyORHpfmObJ8c7L8e-PpNwc9hWl2smRJ5iBvTIFPyE=.5981e465-9fe3-436b-81b2-b07e11f9f0f5@github.com>

On Mon, 9 Feb 2026 10:29:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Recently added test java/lang/Thread/virtual/stress/ParkAfterTimedPark.java has a parameter to indicate if the target thread is pinned or not. I fat fingered the conversion of a test with the result that the "pinned" parameter is ignored and the tests unconditionally tests the pinned case, not the unpinned case.

LGTM

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

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29633#pullrequestreview-3776108907

From asemenyuk at openjdk.org  Tue Feb 10 00:49:59 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 10 Feb 2026 00:49:59 GMT
Subject: RFR: 8377513: jpackage: fix Win8365790Test test
Message-ID: <F9UyO8Z-PL5VF1mQV_w6C0hQVJjjMlhTQM_67BD7wMU=.ced01011-e004-4159-b27d-61a27ff8bb13@github.com>

- Run the code in the worker thread using the same global variables as in the main thread. The NPE was caused by an attempt to access a global variable non-existing in the worker thread. This change prevents NPEs in the worker thread.
 - Check for a thrown exception in the worker thread from the main thread to make the test fail if the worker thread fails.

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

Commit messages:
 - Win8365790Test: fix test failure

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

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

From almatvee at openjdk.org  Tue Feb 10 01:05:45 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 10 Feb 2026 01:05:45 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v9]
In-Reply-To: <tQbyPxMApNvyu3AUHKl4nbQKYWkoE1ddcosJ9vtq7pg=.e92ce8ca-6579-4e56-9369-581915d40ecb@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <C-8YiKlI0uge38gLDeQRdo7lsr2HBF7PcP0sIkLXLog=.1f55a466-228b-46cc-b444-0bfb21653f9e@github.com>
 <tQbyPxMApNvyu3AUHKl4nbQKYWkoE1ddcosJ9vtq7pg=.e92ce8ca-6579-4e56-9369-581915d40ecb@github.com>
Message-ID: <9wzLDLb7l9iKwz4FMG2GV60x5LqW4BrOnj5KVC2HQpA=.a7317546-f442-4233-9fab-7b86fe01bd31@github.com>

On Thu, 5 Feb 2026 17:19:48 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v8]
>
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacFromOptions.java line 367:
> 
>> 365:             return ver.toComponentsString();
>> 366:         }
>> 367:     }
> 
> Why branching?
> 
> It can be as simple as:
> 
> DottedVersion.lazy(version).trim(3).pad(3).toComponentsString()
> 
> 
> The same comment applies to other locations where `trim()` and `pad()` are used.

1, 2 and 3 components are valid for macOS. I do not see a point to normalized valid versions. For example if we packaging JDK 27, then file name will be myJDK-27.dmg, but if we normalize to 3 components always it will be myJDK-27.0.0.dmg.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2785276432

From asemenyuk at openjdk.org  Tue Feb 10 01:22:37 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 10 Feb 2026 01:22:37 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v9]
In-Reply-To: <9wzLDLb7l9iKwz4FMG2GV60x5LqW4BrOnj5KVC2HQpA=.a7317546-f442-4233-9fab-7b86fe01bd31@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <C-8YiKlI0uge38gLDeQRdo7lsr2HBF7PcP0sIkLXLog=.1f55a466-228b-46cc-b444-0bfb21653f9e@github.com>
 <tQbyPxMApNvyu3AUHKl4nbQKYWkoE1ddcosJ9vtq7pg=.e92ce8ca-6579-4e56-9369-581915d40ecb@github.com>
 <9wzLDLb7l9iKwz4FMG2GV60x5LqW4BrOnj5KVC2HQpA=.a7317546-f442-4233-9fab-7b86fe01bd31@github.com>
Message-ID: <cZu4N5vxS-6Iby1kDCdNdxs176KtVSzNzkyKHoRU-CM=.44869d81-8a37-466a-ad61-745de101b1f5@github.com>

On Tue, 10 Feb 2026 01:02:40 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacFromOptions.java line 367:
>> 
>>> 365:             return ver.toComponentsString();
>>> 366:         }
>>> 367:     }
>> 
>> Why branching?
>> 
>> It can be as simple as:
>> 
>> DottedVersion.lazy(version).trim(3).pad(3).toComponentsString()
>> 
>> 
>> The same comment applies to other locations where `trim()` and `pad()` are used.
>
> 1, 2 and 3 components are valid for macOS. I do not see a point to normalized valid versions. For example if we packaging JDK 27, then file name will be myJDK-27.dmg, but if we normalize to 3 components always it will be myJDK-27.0.0.dmg.

Ok, then it should be no padding, only trimming:

DottedVersion.lazy(version).trim(3).toComponentsString()

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2785312227

From darcy at openjdk.org  Tue Feb 10 02:06:30 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 10 Feb 2026 02:06:30 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v8]
In-Reply-To: <0w6KoryTq1Rb_a-q9eAULoFrGDLN-Jd_N12W-XwA5ns=.91e55f80-2bc0-44e2-be03-52c0cd1d8d07@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <p57-Mga85sxN41Hdd9JTLGNVazIrkfDjNtCIhz70-ME=.86050f09-06e0-4c6e-80ac-39794153f806@github.com>
 <HTq4KPrH8lZTVHT6_D3Gi1gMTzernd90gAPzZVEJT5c=.953c4ce3-6ee4-4d4c-9036-92763471579d@github.com>
 <Zgjlew-K02IYZ-EjoENRQzL8higlLSBGQ3Pr7VzA4CA=.2251ba23-b851-410e-900f-8a9f5a6bd1d7@github.com>
 <0w6KoryTq1Rb_a-q9eAULoFrGDLN-Jd_N12W-XwA5ns=.91e55f80-2bc0-44e2-be03-52c0cd1d8d07@github.com>
Message-ID: <4F7FK2EEtv90y37ECqa2nzt8Hnt7TVi7DNX874B9x94=.eeb5db92-690e-45e9-8ee8-a754f9c69487@github.com>

On Thu, 5 Feb 2026 13:29:48 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> @jddarcy What is the purpose of such methods that do not seem to be invoked?

I'm a bit confused; they do look to be used in that test file; e.g.

https://github.com/openjdk/jdk/blame/f9ded7f88cce75151cec32d1ef1f9662ea10431a/test/jdk/java/lang/Math/HyperbolicTests.java#L251

`            failures += testSinhCaseWithUlpDiff(testCase[0],`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2785405769

From asemenyuk at openjdk.org  Tue Feb 10 02:26:16 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 10 Feb 2026 02:26:16 GMT
Subject: RFR: 8377513: jpackage: fix Win8365790Test test
In-Reply-To: <F9UyO8Z-PL5VF1mQV_w6C0hQVJjjMlhTQM_67BD7wMU=.ced01011-e004-4159-b27d-61a27ff8bb13@github.com>
References: <F9UyO8Z-PL5VF1mQV_w6C0hQVJjjMlhTQM_67BD7wMU=.ced01011-e004-4159-b27d-61a27ff8bb13@github.com>
Message-ID: <0VM3i0KXk1Qgtm-kYNIivAbmTNycAcZpW1VglmenLjA=.a6a1417b-f3fd-4177-8e73-65bbf401c12e@github.com>

On Tue, 10 Feb 2026 00:41:41 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Run the code in the worker thread using the same global variables as in the main thread. The NPE was caused by an attempt to access a global variable non-existing in the worker thread. This change prevents NPEs in the worker thread.
>  - Check for a thrown exception in the worker thread from the main thread to make the test fail if the worker thread fails.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/29642#issuecomment-3874951795

From acobbs at openjdk.org  Tue Feb 10 02:38:09 2026
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 10 Feb 2026 02:38:09 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression [v8]
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <_JCaqe5WEHkjbjttTdOWj_iqkoUJpkMw3KjoVsem_Jg=.3558dcd1-6c15-49e9-adc9-b67ccd282197@github.com>

> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.
> 
> Summary of code changes:
> 
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break
> 
> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 141 commits:

 - Merge branch 'master' into JDK-8344159 to fix conflicts.
 - Merge branch 'master' into JDK-8344159 to fix conflicts.
 - Update copyrights to 2026.
 - Merge branch 'master' into JDK-8344159
 - Merge branch 'master' into JDK-8344159
 - Merge branch 'master' into JDK-8344159
 - Suppress new unnecessary suppresion warnings created by recent commits.
 - Merge branch 'master' into JDK-8344159
 - Merge branch 'master' into JDK-8344159 to fix conflict.
 - Merge branch 'master' into JDK-8344159 to fix conflict.
 - ... and 131 more: https://git.openjdk.org/jdk/compare/57eb9c79...4fa9e3f0

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

Changes: https://git.openjdk.org/jdk/pull/25167/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=07
  Stats: 1695 lines in 37 files changed: 1492 ins; 50 del; 153 mod
  Patch: https://git.openjdk.org/jdk/pull/25167.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167

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

From xgong at openjdk.org  Tue Feb 10 02:42:40 2026
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 10 Feb 2026 02:42:40 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating
 broadcasted inputs
In-Reply-To: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
References: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
Message-ID: <S09FWymoHUyMEhDZNodmP8jQKslTWH5pa1bilHA0I7w=.5e9af240-b87d-4b11-bcc4-8e07d3b9d00b@github.com>

On Tue, 3 Jun 2025 14:54:16 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi all,
> 
> This patch optimizes SIMD kernels making heavy use of broadcasted inputs through following reassociating ideal transformations.
> 
> 
>  VectorOperation (VectorBroadcast INP1,  VectorBroadcast INP2) => 
>                             VectorBroadcast (ScalarOpration INP1, INP2)
> 
>  VectorOperation (VectorBroadcast INP1) (VectorOperation (VectorBroadcast INP2) INP3) => 
>                              VectorOperation INP3 (VectorOperation (VectorBroadcast INP1) (VectorOperation INP2))
> 
> 
> The idea is to push broadcasts across the vector operation and replace the vector with an equivalent, cheaper scalar variant.  Currently, patch handles most common vector operations.
> 
> Following are the performance number of benchmark included with this patch on latest generation x86 targets:- 
> 
> **AMD Turin (2.1GHz)**
> <img width="1122" height="355" alt="image" src="https://github.com/user-attachments/assets/3f5087bf-0e14-4c56-b0c2-3d23253bad54" />
> 
> **Intel Granite Rapids (2.1GHz)**
> <img width="1105" height="325" alt="image" src="https://github.com/user-attachments/assets/c8481f86-4db2-4c4e-bd65-51542c59fe63" />
> 
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Good work @jatin-bhateja ! I left some comments below. Thanks!

src/hotspot/share/opto/vectornode.cpp line 390:

> 388:         case T_BOOLEAN:
> 389:         case T_CHAR:
> 390:           assert(!enable_assertions, "boolean and char are signed, not implemented for Min");

Suggestion:

          assert(!enable_assertions, "boolean and char are unsigned, not implemented for Min");

src/hotspot/share/opto/vectornode.cpp line 411:

> 409:         case T_BOOLEAN:
> 410:         case T_CHAR:
> 411:           assert(!enable_assertions, "boolean and char are signed, not implemented for Max");

ditto

src/hotspot/share/opto/vectornode.cpp line 1317:

> 1315:   }
> 1316:   return nullptr;
> 1317: }

Reassociation can be a separate optimization for vector nodes to me. Do you think it's better to split it as a separate change following the broadcast optimization? We can add specific tests for it.

src/hotspot/share/opto/vectornode.cpp line 1358:

> 1356:       return new ReplicateNode(sop, vect_type());
> 1357:     }
> 1358:   }

Is it better to wrap this transformation as a method?

test/hotspot/jtreg/compiler/vectorapi/TestVectorBroadcastReassociations.java line 136:

> 134:      * ======================= */
> 135: 
> 136:     static final VectorSpecies<Long> LSP = LongVector.SPECIES_256;

Why not using the `SPECIES_PREFERRED` instead like the int species? The max vector size for AArch64 NEON (asimd) is 128-bit. We have to add another condition `MaxVectorSize >= 32` for following IR tests if using `SPECIES_256`.

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

PR Review: https://git.openjdk.org/jdk/pull/25617#pullrequestreview-3776329907
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2785411161
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2785421927
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2785464918
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2785469004
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2785485050

From darcy at openjdk.org  Tue Feb 10 02:43:43 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 10 Feb 2026 02:43:43 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v9]
In-Reply-To: <sBVlHSDyh6khWSX0nGj_OwhQqp2Ap3KF1shY4u2vuaI=.15594e70-4dac-4e15-a234-fb11fa441cb2@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <sBVlHSDyh6khWSX0nGj_OwhQqp2Ap3KF1shY4u2vuaI=.15594e70-4dac-4e15-a234-fb11fa441cb2@github.com>
Message-ID: <s9J8GGUkimagDUVBBdTX1drKGLhAPgi5rl04D8EyHPs=.2f768c98-b648-47b0-9e3d-80c1231867eb@github.com>

On Thu, 5 Feb 2026 08:51:10 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM asinh method.
>> 
>> Original C vs transliteration port:
>> 
>> 
>> $ diff -w fdlib_asinh.c Asinh.translit.java
>> 1c1,3
>> < /* asinh(x)
>> ---
>>> /**
>>> * Return the Inverse Hyperbolic Sine of x
>>> *
>> 2a5
>>> *
>> 10a14,17
>>> private static final class Asinh {
>>>       private static final double one = 1.0;
>>>       private static final double ln2 = 6.93147180559945286227e-01;
>>>       private static final double huge = 1.0e300;
>> 12,29c19
>> < #include "fdlibm.h"
>> <
>> < #ifdef __STDC__
>> < static const double
>> < #else
>> < static double
>> < #endif
>> < one =  1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */
>> < ln2 =  6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */
>> < huge=  1.00000000000000000000e+300;
>> <
>> < #ifdef __STDC__
>> <       double asinh(double x)
>> < #else
>> <       double asinh(x)
>> <       double x;
>> < #endif
>> < {
>> ---
>>>       static double compute(double x) {
>> 39c29
>> <           w = __ieee754_log(fabs(x))+ln2;
>> ---
>>>                       w = log(Math.abs(x))+ln2;
>> 41,42c31,32
>> <           t = fabs(x);
>> <           w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t));
>> ---
>>>                       t = Math.abs(x);
>>>                       w = log(2.0*t+one/(sqrt(x*x+one)+t));
>> 45c35
>> <           w =log1p(fabs(x)+t/(one+sqrt(one+t)));
>> ---
>>>                       w =log1p(Math.abs(x)+t/(one+sqrt(one+t)));
>> 47a38
>>>       }
>> 
>> Transliteration port vs more idiomatic port:
>> 
>> 
>> $ diff -w Asinh.translit.java Asinh.fdlibm.java
>> 6,9c6,12
>> < *  Based on
>> < *    asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ]
>> < *   we have
>> < *   asinh(x) := x  if  1+x*x=1,
>> ---
>>>  *
>>>  *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF
>>>  *      and sinh(asinh(x)) = x, -INF < x  < INF.
>>>  *      It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x  < INF.
>>>  *      1. Replace x by |x| as the function is odd.
>>>  *      2.
>>>  *          asinh(x) := x, if 1+x^2 = 1,
>> 12a16,22
>>>  *
>>>  *
>>>  *
>>>  * Special cases:
>>>  *      only asinh(0)=0 is exact for finite x.
>>>  *      asinh(NaN) is NaN
>>>  *      asinh(INF) is INF
>> 14,15c24
>> < private static final class Asinh {
>> <       private static final double one = 1.0;
>> ---
>>> static final class Asinh {
>> 24c33,35
>> <               if(ix>=0x7ff00000) return x+x;  /* x is inf or NaN */
>> ---
>>>               if(ix >= 0x7ff00000) {
>>>                       return x...
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8375285: Addressed reviewer's comments.

test/jdk/java/lang/StrictMath/HyperbolicTests.java line 511:

> 509:                 {0x1.ffffffffffffep-19, 0x1.fffffffffaaa9p-19},
> 510:                 {0x1.fffffffffffffp-18, 0x1.ffffffffeaaa9p-18},
> 511:                 {0x1p-17, 0x1.ffffffffeaaabp-18},

Nit: I'd prefer if the second values were all aligned even if the first argument didn't take that many characters to initialize.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2785497478

From darcy at openjdk.org  Tue Feb 10 02:46:43 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 10 Feb 2026 02:46:43 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v8]
In-Reply-To: <Zgjlew-K02IYZ-EjoENRQzL8higlLSBGQ3Pr7VzA4CA=.2251ba23-b851-410e-900f-8a9f5a6bd1d7@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <p57-Mga85sxN41Hdd9JTLGNVazIrkfDjNtCIhz70-ME=.86050f09-06e0-4c6e-80ac-39794153f806@github.com>
 <HTq4KPrH8lZTVHT6_D3Gi1gMTzernd90gAPzZVEJT5c=.953c4ce3-6ee4-4d4c-9036-92763471579d@github.com>
 <Zgjlew-K02IYZ-EjoENRQzL8higlLSBGQ3Pr7VzA4CA=.2251ba23-b851-410e-900f-8a9f5a6bd1d7@github.com>
Message-ID: <LRQwNw68EF9YXPXvkdgw2VfqEmbTFN2gIt58gDOZOnw=.9396f5c1-c539-408a-856d-869b24114cbd@github.com>

On Thu, 5 Feb 2026 08:45:09 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> test/jdk/java/lang/StrictMath/HyperbolicTests.java line 29:
>> 
>>> 27: /*
>>> 28:  * @test
>>> 29:  * @bug 4851625 8301444
>> 
>> Not sure if this requires the new bug ID.
>
> I don't think we need to add anything, see above.

Hmm.

I think at least one test should include a bug id for this work.

(jtreg has a feature "run all the tests associated with this bug id." I don't think that feature is widely used, but it is part of the rationale behind the policy.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2785505198

From almatvee at openjdk.org  Tue Feb 10 03:18:29 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 10 Feb 2026 03:18:29 GMT
Subject: RFR: 8377513: jpackage: fix Win8365790Test test
In-Reply-To: <F9UyO8Z-PL5VF1mQV_w6C0hQVJjjMlhTQM_67BD7wMU=.ced01011-e004-4159-b27d-61a27ff8bb13@github.com>
References: <F9UyO8Z-PL5VF1mQV_w6C0hQVJjjMlhTQM_67BD7wMU=.ced01011-e004-4159-b27d-61a27ff8bb13@github.com>
Message-ID: <mFBBLPyfyie_GEPXFW-Ubuvph29iH5pfsuje5LjY978=.00b32180-dcae-45a2-a225-a498cfcf5550@github.com>

On Tue, 10 Feb 2026 00:41:41 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Run the code in the worker thread using the same global variables as in the main thread. The NPE was caused by an attempt to access a global variable non-existing in the worker thread. This change prevents NPEs in the worker thread.
>  - Check for a thrown exception in the worker thread from the main thread to make the test fail if the worker thread fails.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29642#pullrequestreview-3776511319

From syan at openjdk.org  Tue Feb 10 03:26:27 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 10 Feb 2026 03:26:27 GMT
Subject: RFR: 8376023: Reconcile ClassUnloader with ClassUnloadCommon [v2]
In-Reply-To: <M2_xq-zZRd-QlR-eraizOWbVzohTC8rIlo1ZdyOa8fw=.f5feb9df-74e2-436b-a8d4-c7aa4bfe42c2@github.com>
References: <M2_xq-zZRd-QlR-eraizOWbVzohTC8rIlo1ZdyOa8fw=.f5feb9df-74e2-436b-a8d4-c7aa4bfe42c2@github.com>
Message-ID: <DQiE_NMXE9at90pQX_QN-y-lhubuI2VAQjKthhxSr50=.1fe833cd-f739-4ea5-96ba-1367e3776fc9@github.com>

> Hi all,
> 
> This PR merge test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java to test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java, and make the vmTestbase tests use the ClassUnloadCommon.
> 
> The core method in test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java is `boolean unloadClass()`, and the core method in test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java is `Set<String> triggerUnloading(List<String> classNames)`, it's not easy to combile these two methods to one. So I keep all these two methods.
> 
> Additional testing:
> 
> - [x] Full jtreg tests include vmTestbase

SendaoYan 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:

 - Fix missed attempt++
 - Add "import jdk.test.lib.classloader.CustomClassLoader;" for vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t002/TestDescription.java etc..
 - Adapt DEFAULT_BREAKPOINT_LINE from 63 to 65, since two lines added to test/hotspot/jtreg/vmTestbase/nsk/share/jpda/AbstractDebuggeeTest.java
 - Add "import jdk.test.lib.classloader.ClassFileFinder"
 - fix vmTestbase/nsk/jdi/Scenarios/invokeMethod/redefineclasses001/TestDescription.java fails "cannot find symbol ClassFileFind"
 - sed -i "s|import nsk.share.CustomClassLoader;|import jdk.test.lib.classloader.CustomClassLoader;|" `grep nsk.share.CustomClassLoader test/ -rnl `
 - Fix test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadEvent/className/classname001/TestDescription.java fails "cannot find user-defined classloader loaded: nsk.share.CustomClassLoader"
 - Fix javac error: "AbstractDebuggeeTest.java:103: error: cannot find symbol"
 - Merge branch 'openjdk:master' into jbs8376023
 - Fix comment in test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/reflectedType/reflectype002/TestDescription.java
 - ... and 21 more: https://git.openjdk.org/jdk/compare/717f7a39...bff25ebf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29545/files
  - new: https://git.openjdk.org/jdk/pull/29545/files/458fb127..bff25ebf

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

  Stats: 13921 lines in 367 files changed: 7638 ins; 2803 del; 3480 mod
  Patch: https://git.openjdk.org/jdk/pull/29545.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29545/head:pull/29545

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

From dholmes at openjdk.org  Tue Feb 10 03:26:29 2026
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Feb 2026 03:26:29 GMT
Subject: RFR: 8376023: Reconcile ClassUnloader with ClassUnloadCommon [v2]
In-Reply-To: <DQiE_NMXE9at90pQX_QN-y-lhubuI2VAQjKthhxSr50=.1fe833cd-f739-4ea5-96ba-1367e3776fc9@github.com>
References: <M2_xq-zZRd-QlR-eraizOWbVzohTC8rIlo1ZdyOa8fw=.f5feb9df-74e2-436b-a8d4-c7aa4bfe42c2@github.com>
 <DQiE_NMXE9at90pQX_QN-y-lhubuI2VAQjKthhxSr50=.1fe833cd-f739-4ea5-96ba-1367e3776fc9@github.com>
Message-ID: <MqZF4nbmsFc0XksTSrho46d_V0JZgmRPSR0m6uPsj8Y=.1ca436ac-70d3-4099-a424-6d09b2e0f293@github.com>

On Tue, 10 Feb 2026 03:23:11 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR merge test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java to test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java, and make the vmTestbase tests use the ClassUnloadCommon.
>> 
>> The core method in test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java is `boolean unloadClass()`, and the core method in test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java is `Set<String> triggerUnloading(List<String> classNames)`, it's not easy to combile these two methods to one. So I keep all these two methods.
>> 
>> Additional testing:
>> 
>> - [x] Full jtreg tests include vmTestbase
>
> SendaoYan 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:
> 
>  - Fix missed attempt++
>  - Add "import jdk.test.lib.classloader.CustomClassLoader;" for vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t002/TestDescription.java etc..
>  - Adapt DEFAULT_BREAKPOINT_LINE from 63 to 65, since two lines added to test/hotspot/jtreg/vmTestbase/nsk/share/jpda/AbstractDebuggeeTest.java
>  - Add "import jdk.test.lib.classloader.ClassFileFinder"
>  - fix vmTestbase/nsk/jdi/Scenarios/invokeMethod/redefineclasses001/TestDescription.java fails "cannot find symbol ClassFileFind"
>  - sed -i "s|import nsk.share.CustomClassLoader;|import jdk.test.lib.classloader.CustomClassLoader;|" `grep nsk.share.CustomClassLoader test/ -rnl `
>  - Fix test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadEvent/className/classname001/TestDescription.java fails "cannot find user-defined classloader loaded: nsk.share.CustomClassLoader"
>  - Fix javac error: "AbstractDebuggeeTest.java:103: error: cannot find symbol"
>  - Merge branch 'openjdk:master' into jbs8376023
>  - Fix comment in test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/reflectedType/reflectype002/TestDescription.java
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/717f7a39...bff25ebf

Sorry but no. Nothing in test/lib should have a dependency back into the nsk files. vmTestbase is legacy code. If ClassUnloadCommon needs additional nsk classes then they should also be moved into the test library.

test/hotspot/jtreg/runtime/logging/ClassLoadUnloadTest.java line 30:

> 28:  * @requires vm.flagless
> 29:  * @modules java.base/jdk.internal.misc
> 30:  * @library /test/lib /vmTestbase

This test should not be using anything in vmTestbase!

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29545#pullrequestreview-3749331104
PR Review Comment: https://git.openjdk.org/jdk/pull/29545#discussion_r2762489720

From cjplummer at openjdk.org  Tue Feb 10 03:26:31 2026
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 10 Feb 2026 03:26:31 GMT
Subject: RFR: 8376023: Reconcile ClassUnloader with ClassUnloadCommon
In-Reply-To: <M2_xq-zZRd-QlR-eraizOWbVzohTC8rIlo1ZdyOa8fw=.f5feb9df-74e2-436b-a8d4-c7aa4bfe42c2@github.com>
References: <M2_xq-zZRd-QlR-eraizOWbVzohTC8rIlo1ZdyOa8fw=.f5feb9df-74e2-436b-a8d4-c7aa4bfe42c2@github.com>
Message-ID: <fgxo_3IGVnw7ltMRkVQBEE7ZkGQSUIE5Bvfn_mUfKVs=.bc5a871f-579b-4de6-98fc-a9879e2d52fa@github.com>

On Tue, 3 Feb 2026 14:24:21 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This PR merge test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java to test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java, and make the vmTestbase tests use the ClassUnloadCommon.
> 
> The core method in test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java is `boolean unloadClass()`, and the core method in test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java is `Set<String> triggerUnloading(List<String> classNames)`, it's not easy to combile these two methods to one. So I keep all these two methods.
> 
> Additional testing:
> 
> - [x] Full jtreg tests include vmTestbase

Was there any merger of the functionality of these two files, or did you just move the ClassUnloader.java contents into ClassUnloadCommon.java?

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

PR Comment: https://git.openjdk.org/jdk/pull/29545#issuecomment-3843942798

From syan at openjdk.org  Tue Feb 10 03:26:32 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 10 Feb 2026 03:26:32 GMT
Subject: RFR: 8376023: Reconcile ClassUnloader with ClassUnloadCommon
In-Reply-To: <fgxo_3IGVnw7ltMRkVQBEE7ZkGQSUIE5Bvfn_mUfKVs=.bc5a871f-579b-4de6-98fc-a9879e2d52fa@github.com>
References: <M2_xq-zZRd-QlR-eraizOWbVzohTC8rIlo1ZdyOa8fw=.f5feb9df-74e2-436b-a8d4-c7aa4bfe42c2@github.com>
 <fgxo_3IGVnw7ltMRkVQBEE7ZkGQSUIE5Bvfn_mUfKVs=.bc5a871f-579b-4de6-98fc-a9879e2d52fa@github.com>
Message-ID: <VyDUNn129VZ28SqirKNtkRxdHk0IjrqWBVQlZ-HAypo=.83a55056-bddf-466e-98f7-cb993f228771@github.com>

On Tue, 3 Feb 2026 22:10:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Was there any merger of the functionality of these two files, or did you just move the ClassUnloader.java contents into ClassUnloadCommon.java?

I almost just move the ClassUnloader.java contents into ClassUnloaderCommon.java, except for make both file use the same variable `MAX_UNLOAD_ATTEMPS`.

The core method in test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java is `boolean unloadClass()`, it check the classloader has been reclaimed or not to determise the class[es] has been unload or not.
And the core method in test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java is `Set<String> triggerUnloading(List<String> classNames)`, it check the `WhiteBox.isClassAlive(className)`  for every loaded class[es] to determise the loaded class[es] has been unload or not.

These two unload methods has different usages and different ways of classloader technology, we can not combine them to one directively. If we want to combine them to one, we should adapt all the releated tests at the same time.

The classloader in the original test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java only support load the class which locate in the test.class.path, but the classloader in the original test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java can load the class by the given directory. So we can not make the vmTestbase tests use the load/unload method in the original test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java.

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

PR Comment: https://git.openjdk.org/jdk/pull/29545#issuecomment-3845129033

From cjplummer at openjdk.org  Tue Feb 10 03:26:32 2026
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 10 Feb 2026 03:26:32 GMT
Subject: RFR: 8376023: Reconcile ClassUnloader with ClassUnloadCommon
In-Reply-To: <VyDUNn129VZ28SqirKNtkRxdHk0IjrqWBVQlZ-HAypo=.83a55056-bddf-466e-98f7-cb993f228771@github.com>
References: <M2_xq-zZRd-QlR-eraizOWbVzohTC8rIlo1ZdyOa8fw=.f5feb9df-74e2-436b-a8d4-c7aa4bfe42c2@github.com>
 <fgxo_3IGVnw7ltMRkVQBEE7ZkGQSUIE5Bvfn_mUfKVs=.bc5a871f-579b-4de6-98fc-a9879e2d52fa@github.com>
 <VyDUNn129VZ28SqirKNtkRxdHk0IjrqWBVQlZ-HAypo=.83a55056-bddf-466e-98f7-cb993f228771@github.com>
Message-ID: <R3aQicdo53MrNyx0-_H_8tEjbTJj_j6b-6989flP21w=.89d1dc59-7503-4052-8e14-f7ae131f67de@github.com>

On Wed, 4 Feb 2026 04:05:53 GMT, SendaoYan <syan at openjdk.org> wrote:

> > Was there any merger of the functionality of these two files, or did you just move the ClassUnloader.java contents into ClassUnloadCommon.java?
> 
> I almost just move the ClassUnloader.java contents into ClassUnloaderCommon.java, except for make both file use the same variable `MAX_UNLOAD_ATTEMPS`.

I'm just wondering if this change is worth doing if there is no added code sharing going on. What is the motivation for this?

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

PR Comment: https://git.openjdk.org/jdk/pull/29545#issuecomment-3863414401

From syan at openjdk.org  Tue Feb 10 03:26:33 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 10 Feb 2026 03:26:33 GMT
Subject: RFR: 8376023: Reconcile ClassUnloader with ClassUnloadCommon
In-Reply-To: <R3aQicdo53MrNyx0-_H_8tEjbTJj_j6b-6989flP21w=.89d1dc59-7503-4052-8e14-f7ae131f67de@github.com>
References: <M2_xq-zZRd-QlR-eraizOWbVzohTC8rIlo1ZdyOa8fw=.f5feb9df-74e2-436b-a8d4-c7aa4bfe42c2@github.com>
 <fgxo_3IGVnw7ltMRkVQBEE7ZkGQSUIE5Bvfn_mUfKVs=.bc5a871f-579b-4de6-98fc-a9879e2d52fa@github.com>
 <VyDUNn129VZ28SqirKNtkRxdHk0IjrqWBVQlZ-HAypo=.83a55056-bddf-466e-98f7-cb993f228771@github.com>
 <R3aQicdo53MrNyx0-_H_8tEjbTJj_j6b-6989flP21w=.89d1dc59-7503-4052-8e14-f7ae131f67de@github.com>
Message-ID: <jB-Y8IkqujRm1xlSEiO312J1rJ88yOpCQOzPfGLwXE4=.db7f9b33-601a-4f42-9931-35b1f35ba667@github.com>

On Sat, 7 Feb 2026 02:57:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > > Was there any merger of the functionality of these two files, or did you just move the ClassUnloader.java contents into ClassUnloadCommon.java?
> > 
> > 
> > I almost just move the ClassUnloader.java contents into ClassUnloaderCommon.java, except for make both file use the same variable `MAX_UNLOAD_ATTEMPS`.
> 
> I'm just wondering if this change is worth doing if there is no added code sharing going on. What is the motivation for this?

I agree with you. Maybe I misunderstood the intention of [JDK-8376023](https://bugs.openjdk.org/browse/JDK-8376023)

@coleenp Could you give me some advies?

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

PR Comment: https://git.openjdk.org/jdk/pull/29545#issuecomment-3863545626

From syan at openjdk.org  Tue Feb 10 03:26:35 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 10 Feb 2026 03:26:35 GMT
Subject: RFR: 8376023: Reconcile ClassUnloader with ClassUnloadCommon [v2]
In-Reply-To: <MqZF4nbmsFc0XksTSrho46d_V0JZgmRPSR0m6uPsj8Y=.1ca436ac-70d3-4099-a424-6d09b2e0f293@github.com>
References: <M2_xq-zZRd-QlR-eraizOWbVzohTC8rIlo1ZdyOa8fw=.f5feb9df-74e2-436b-a8d4-c7aa4bfe42c2@github.com>
 <DQiE_NMXE9at90pQX_QN-y-lhubuI2VAQjKthhxSr50=.1fe833cd-f739-4ea5-96ba-1367e3776fc9@github.com>
 <MqZF4nbmsFc0XksTSrho46d_V0JZgmRPSR0m6uPsj8Y=.1ca436ac-70d3-4099-a424-6d09b2e0f293@github.com>
Message-ID: <v_Ho0WxDDlO3S7XpiDYyh4OznrS2peu1en4tHv9NfJs=.f122ee02-e794-418a-a7d6-c63c79a98048@github.com>

On Wed, 4 Feb 2026 06:53:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> SendaoYan 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:
>> 
>>  - Fix missed attempt++
>>  - Add "import jdk.test.lib.classloader.CustomClassLoader;" for vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t002/TestDescription.java etc..
>>  - Adapt DEFAULT_BREAKPOINT_LINE from 63 to 65, since two lines added to test/hotspot/jtreg/vmTestbase/nsk/share/jpda/AbstractDebuggeeTest.java
>>  - Add "import jdk.test.lib.classloader.ClassFileFinder"
>>  - fix vmTestbase/nsk/jdi/Scenarios/invokeMethod/redefineclasses001/TestDescription.java fails "cannot find symbol ClassFileFind"
>>  - sed -i "s|import nsk.share.CustomClassLoader;|import jdk.test.lib.classloader.CustomClassLoader;|" `grep nsk.share.CustomClassLoader test/ -rnl `
>>  - Fix test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadEvent/className/classname001/TestDescription.java fails "cannot find user-defined classloader loaded: nsk.share.CustomClassLoader"
>>  - Fix javac error: "AbstractDebuggeeTest.java:103: error: cannot find symbol"
>>  - Merge branch 'openjdk:master' into jbs8376023
>>  - Fix comment in test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/reflectedType/reflectype002/TestDescription.java
>>  - ... and 21 more: https://git.openjdk.org/jdk/compare/717f7a39...bff25ebf
>
> test/hotspot/jtreg/runtime/logging/ClassLoadUnloadTest.java line 30:
> 
>> 28:  * @requires vm.flagless
>> 29:  * @modules java.base/jdk.internal.misc
>> 30:  * @library /test/lib /vmTestbase
> 
> This test should not be using anything in vmTestbase!

I remove the nsk.share dependences in test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java, and this @library /vmTestbase has been removed.
But I need move CustomClassLoader.java/ClassFileFinder.java/Failure.java to test/lib/jdk/test/lib/classloader. There must be some vmTestbase tests needed to adapt since this move. I'am wondering should I continue this PR or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29545#discussion_r2762697432

From cjplummer at openjdk.org  Tue Feb 10 03:59:19 2026
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 10 Feb 2026 03:59:19 GMT
Subject: RFR: 8376023: Reconcile ClassUnloader with ClassUnloadCommon
In-Reply-To: <jB-Y8IkqujRm1xlSEiO312J1rJ88yOpCQOzPfGLwXE4=.db7f9b33-601a-4f42-9931-35b1f35ba667@github.com>
References: <M2_xq-zZRd-QlR-eraizOWbVzohTC8rIlo1ZdyOa8fw=.f5feb9df-74e2-436b-a8d4-c7aa4bfe42c2@github.com>
 <fgxo_3IGVnw7ltMRkVQBEE7ZkGQSUIE5Bvfn_mUfKVs=.bc5a871f-579b-4de6-98fc-a9879e2d52fa@github.com>
 <VyDUNn129VZ28SqirKNtkRxdHk0IjrqWBVQlZ-HAypo=.83a55056-bddf-466e-98f7-cb993f228771@github.com>
 <R3aQicdo53MrNyx0-_H_8tEjbTJj_j6b-6989flP21w=.89d1dc59-7503-4052-8e14-f7ae131f67de@github.com>
 <jB-Y8IkqujRm1xlSEiO312J1rJ88yOpCQOzPfGLwXE4=.db7f9b33-601a-4f42-9931-35b1f35ba667@github.com>
Message-ID: <U3-hqm0aoIvGYErDybpK46hE45rkwljgA41mEpbv-7Q=.24423cfc-2283-4f6e-ac88-d97e9dac369c@github.com>

On Sat, 7 Feb 2026 04:21:41 GMT, SendaoYan <syan at openjdk.org> wrote:

> > I'm just wondering if this change is worth doing if there is no added code sharing going on. What is the motivation for this?
> 
> I agree with you. Maybe I misunderstood the intention of [JDK-8376023](https://bugs.openjdk.org/browse/JDK-8376023)
> 
> @coleenp Could you give me some advies?

I think the suggestion was to merge the functionality, not just combine the similar but different functionality into the same class. In other words, all tests should use common APIs to handle class unloading, not different methods that happen to be in the same class. Given the differences you have found in the two implementations and how they are used by the tests, I'm not so sure the disruption to the tests (and risk of introducing bugs) is worth it.

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

PR Comment: https://git.openjdk.org/jdk/pull/29545#issuecomment-3875177130

From asemenyuk at openjdk.org  Tue Feb 10 04:02:37 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 10 Feb 2026 04:02:37 GMT
Subject: Integrated: 8377513: jpackage: fix Win8365790Test test
In-Reply-To: <F9UyO8Z-PL5VF1mQV_w6C0hQVJjjMlhTQM_67BD7wMU=.ced01011-e004-4159-b27d-61a27ff8bb13@github.com>
References: <F9UyO8Z-PL5VF1mQV_w6C0hQVJjjMlhTQM_67BD7wMU=.ced01011-e004-4159-b27d-61a27ff8bb13@github.com>
Message-ID: <ewrWvBJ2ebqtG64qwnajAzLgkHm296f8Lw5dy2fjSD0=.e56c774b-5911-442e-bae2-bbcf288658f4@github.com>

On Tue, 10 Feb 2026 00:41:41 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Run the code in the worker thread using the same global variables as in the main thread. The NPE was caused by an attempt to access a global variable non-existing in the worker thread. This change prevents NPEs in the worker thread.
>  - Check for a thrown exception in the worker thread from the main thread to make the test fail if the worker thread fails.

This pull request has now been integrated.

Changeset: 87df1bbb
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/87df1bbbe28f2009adda6ca13d0d7e2766c48c88
Stats:     19 lines in 1 file changed: 11 ins; 0 del; 8 mod

8377513: jpackage: fix Win8365790Test test

Reviewed-by: almatvee

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

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

From asemenyuk at openjdk.org  Tue Feb 10 04:26:44 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 10 Feb 2026 04:26:44 GMT
Subject: RFR: 8377514: jpackage: support passing multiple exceptions to the
 top-level error handler
Message-ID: <ZbVqysXuPvRn8fIgCtyQHjWylb9Tn8nKP6cY-gz36eY=.f18c0d3f-70c7-4973-b18a-c0f7eaaee52d@github.com>

Make the top-level error reporter handle suppressed exceptions.

The bundling code may use the suppressed exceptions mechanism to report multiple error conditions.

Rework reporting of multiple signing identity errors using the new mechanism, simplified `MacFromOptions.createMacPkgPackage()`.

Additionally:
 - Simplified AppImageSigningConfigBuilder and SigningIdentityBuilder

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

Commit messages:
 - Improve multiple expired certificate errors reporting in MacFromOptions#createMacPkgPackage(). Streamline SigningIdentityBuilder; Tighten up MacSignTest.
 - cli/Main: support reporting suppressed exceptions. This allows to report all error messages in the cases when they use suppressed exceptions to communicate multiple errors

Changes: https://git.openjdk.org/jdk/pull/29643/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29643&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377514
  Stats: 711 lines in 11 files changed: 444 ins; 80 del; 187 mod
  Patch: https://git.openjdk.org/jdk/pull/29643.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29643/head:pull/29643

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

From asemenyuk at openjdk.org  Tue Feb 10 04:26:45 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 10 Feb 2026 04:26:45 GMT
Subject: RFR: 8377514: jpackage: support passing multiple exceptions to the
 top-level error handler
In-Reply-To: <ZbVqysXuPvRn8fIgCtyQHjWylb9Tn8nKP6cY-gz36eY=.f18c0d3f-70c7-4973-b18a-c0f7eaaee52d@github.com>
References: <ZbVqysXuPvRn8fIgCtyQHjWylb9Tn8nKP6cY-gz36eY=.f18c0d3f-70c7-4973-b18a-c0f7eaaee52d@github.com>
Message-ID: <NgcumDUM1w2lwY1z1HxVIawtAQstWRMDuJiY1jl9xI8=.27832aa7-11e8-4e01-a3f8-aaea59a2bca3@github.com>

On Tue, 10 Feb 2026 01:06:29 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Make the top-level error reporter handle suppressed exceptions.
> 
> The bundling code may use the suppressed exceptions mechanism to report multiple error conditions.
> 
> Rework reporting of multiple signing identity errors using the new mechanism, simplified `MacFromOptions.createMacPkgPackage()`.
> 
> Additionally:
>  - Simplified AppImageSigningConfigBuilder and SigningIdentityBuilder

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/29643#issuecomment-3875237258

From dholmes at openjdk.org  Tue Feb 10 04:50:12 2026
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Feb 2026 04:50:12 GMT
Subject: RFR: 8376023: Reconcile ClassUnloader with ClassUnloadCommon [v2]
In-Reply-To: <DQiE_NMXE9at90pQX_QN-y-lhubuI2VAQjKthhxSr50=.1fe833cd-f739-4ea5-96ba-1367e3776fc9@github.com>
References: <M2_xq-zZRd-QlR-eraizOWbVzohTC8rIlo1ZdyOa8fw=.f5feb9df-74e2-436b-a8d4-c7aa4bfe42c2@github.com>
 <DQiE_NMXE9at90pQX_QN-y-lhubuI2VAQjKthhxSr50=.1fe833cd-f739-4ea5-96ba-1367e3776fc9@github.com>
Message-ID: <ZsL5VBLSvpu_wrEIR2JlK41in1T_5lu7qEoeVsQjwfI=.f0ff439c-1a1c-4c9c-9b90-552b83ecc047@github.com>

On Tue, 10 Feb 2026 03:26:27 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR merge test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java to test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java, and make the vmTestbase tests use the ClassUnloadCommon.
>> 
>> The core method in test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java is `boolean unloadClass()`, and the core method in test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java is `Set<String> triggerUnloading(List<String> classNames)`, it's not easy to combile these two methods to one. So I keep all these two methods.
>> 
>> Additional testing:
>> 
>> - [x] Full jtreg tests include vmTestbase
>
> SendaoYan 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:
> 
>  - Fix missed attempt++
>  - Add "import jdk.test.lib.classloader.CustomClassLoader;" for vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t002/TestDescription.java etc..
>  - Adapt DEFAULT_BREAKPOINT_LINE from 63 to 65, since two lines added to test/hotspot/jtreg/vmTestbase/nsk/share/jpda/AbstractDebuggeeTest.java
>  - Add "import jdk.test.lib.classloader.ClassFileFinder"
>  - fix vmTestbase/nsk/jdi/Scenarios/invokeMethod/redefineclasses001/TestDescription.java fails "cannot find symbol ClassFileFind"
>  - sed -i "s|import nsk.share.CustomClassLoader;|import jdk.test.lib.classloader.CustomClassLoader;|" `grep nsk.share.CustomClassLoader test/ -rnl `
>  - Fix test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadEvent/className/classname001/TestDescription.java fails "cannot find user-defined classloader loaded: nsk.share.CustomClassLoader"
>  - Fix javac error: "AbstractDebuggeeTest.java:103: error: cannot find symbol"
>  - Merge branch 'openjdk:master' into jbs8376023
>  - Fix comment in test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/reflectedType/reflectype002/TestDescription.java
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/2fd75594...bff25ebf

I think the motivation was to avoid needing to (but forgetting to) update both chunks of unloading code at the same time. But we certainly do want any dependencies into the vmTestBase sources.

I wonder whether the vmTestbase version could just delegate the actual functionality to the test library version? Though we would still need to update all the vmTestBase tests that use it to ensure it gets built and is accessible at runtime.

I'm really not sure this is actually worth the upheaval.

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

PR Comment: https://git.openjdk.org/jdk/pull/29545#issuecomment-3875308504

From jbhateja at openjdk.org  Tue Feb 10 05:34:06 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 10 Feb 2026 05:34:06 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating
 broadcasted inputs [v2]
In-Reply-To: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
References: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
Message-ID: <PNW4gxucHTNbKyn34Kdbm4k4GU881SvrVshRPDU9SXA=.3868b71e-95a7-42ea-9159-4a8f08f610ab@github.com>

> Hi all,
> 
> This patch optimizes SIMD kernels making heavy use of broadcasted inputs through following reassociating ideal transformations.
> 
> 
>  VectorOperation (VectorBroadcast INP1,  VectorBroadcast INP2) => 
>                             VectorBroadcast (ScalarOpration INP1, INP2)
> 
>  VectorOperation (VectorBroadcast INP1) (VectorOperation (VectorBroadcast INP2) INP3) => 
>                              VectorOperation INP3 (VectorOperation (VectorBroadcast INP1) (VectorOperation INP2))
> 
> 
> The idea is to push broadcasts across the vector operation and replace the vector with an equivalent, cheaper scalar variant.  Currently, patch handles most common vector operations.
> 
> Following are the performance number of benchmark included with this patch on latest generation x86 targets:- 
> 
> **AMD Turin (2.1GHz)**
> <img width="1122" height="355" alt="image" src="https://github.com/user-attachments/assets/3f5087bf-0e14-4c56-b0c2-3d23253bad54" />
> 
> **Intel Granite Rapids (2.1GHz)**
> <img width="1105" height="325" alt="image" src="https://github.com/user-attachments/assets/c8481f86-4db2-4c4e-bd65-51542c59fe63" />
> 
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

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

  Review comments resolutions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25617/files
  - new: https://git.openjdk.org/jdk/pull/25617/files/eb53527c..2a044457

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

  Stats: 133 lines in 3 files changed: 110 ins; 10 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/25617.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25617/head:pull/25617

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

From jbhateja at openjdk.org  Tue Feb 10 05:38:09 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 10 Feb 2026 05:38:09 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating
 broadcasted inputs [v2]
In-Reply-To: <S09FWymoHUyMEhDZNodmP8jQKslTWH5pa1bilHA0I7w=.5e9af240-b87d-4b11-bcc4-8e07d3b9d00b@github.com>
References: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
 <S09FWymoHUyMEhDZNodmP8jQKslTWH5pa1bilHA0I7w=.5e9af240-b87d-4b11-bcc4-8e07d3b9d00b@github.com>
Message-ID: <8NV2dH7Ingzw2y7E4MEflV9bipfpei8MYIgA9ErG_AI=.ab852238-f137-4f22-8247-28758c57c1e2@github.com>

On Tue, 10 Feb 2026 02:29:11 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions
>
> src/hotspot/share/opto/vectornode.cpp line 1317:
> 
>> 1315:   }
>> 1316:   return nullptr;
>> 1317: }
> 
> Reassociation can be a separate optimization for vector nodes to me. Do you think it's better to split it as a separate change following the broadcast optimization? We can add specific tests for it.

Reassociation are only applicable to integral vector operation, for vector API we only use fp-fast model semantics for reductions of floating point vector, I have now added tests to cover all possible transformations so that we can include both associated transforms in same patch.

> test/hotspot/jtreg/compiler/vectorapi/TestVectorBroadcastReassociations.java line 136:
> 
>> 134:      * ======================= */
>> 135: 
>> 136:     static final VectorSpecies<Long> LSP = LongVector.SPECIES_256;
> 
> Why not using the `SPECIES_PREFERRED` instead like the int species? The max vector size for AArch64 NEON (asimd) is 128-bit. We have to add another condition `MaxVectorSize >= 32` for following IR tests if using `SPECIES_256`.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2785891612
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2785892467

From dholmes at openjdk.org  Tue Feb 10 05:43:50 2026
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Feb 2026 05:43:50 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v5]
In-Reply-To: <yFQp76OS54YtFC7ACRlvgKCuj0SI8UkS54MFEGUaOqg=.f8c3b537-8b89-4a28-bb6a-15a20d9539df@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <yFQp76OS54YtFC7ACRlvgKCuj0SI8UkS54MFEGUaOqg=.f8c3b537-8b89-4a28-bb6a-15a20d9539df@github.com>
Message-ID: <gi_a5BIZQT9G1f8dMAwZw-JqqKIOkS9vZv6ZSQAkw14=.9f539313-930f-455d-887d-08d705919c3c@github.com>

On Mon, 9 Feb 2026 21:33:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> _This patch is not intended for JDK 26_. 
>> 
>> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens.
>> 
>> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch.
>> 
>> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2].
>> 
>> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review.
>> 
>> ### Implementation Notes
>> 
>> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit):
>>   a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default.
>>   b) 64-bit, COH on
>>   c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR.
>> 
>> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything).
>> 
>> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in.
>>   
>> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch.
>> 
>> ### Testing
>> 
>> - tier 1 2 3 locally on Linux x64
>> - SAP ran their whole set of tests for all the platforms they support.
>> 
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8350754
>> [2...
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:
> 
>  - Replace Klass::_metadata union with narrowKlass member
>  - Ivan: fix various instances of ObjLayout::undefined should assert
>  - Ivan: Update src/hotspot/share/oops/instanceKlass.cpp
>    
>    Co-authored-by: Ivan Walulya <ivan.walulya at oracle.com>
>  - David: reduce diff in ObjectCountEventVerifier.java
>  - David: minimize change in GetObjectSizeIntrinsicsTest.java
>  - David: minimize diffs in TestZGCWithCDS.java
>  - David: minimize diffs for runtime/ErrorHandling/TestVMConfigInHsErrFile.java
>  - David: revert type change in arguments.cpp
>  - David: fix comment in metaspace
>  - Merge branch 'master' into JDK-8363996-Obsolete-UseCompressedClassPointers
>  - ... and 52 more: https://git.openjdk.org/jdk/compare/ffb6279c...642604ac

A couple of minor follow up comments below, but otherwise this all seems okay. Thanks

src/hotspot/cpu/x86/macroAssembler_x86.hpp line 354:

> 352:   void store_klass(Register dst, Register src, Register tmp);
> 353: 
> 354:   // Compares the narrow Klass pointer of an object to a given narrow Klass (which might be narrow

Suggestion:

  // Compares the narrow Klass pointer of an object to a given narrow Klass.

??

test/jdk/jdk/jfr/event/gc/objectcount/ObjectCountEventVerifier.java line 73:

> 71:         boolean runsOn32Bit = System.getProperty("sun.arch.data.model").equals("32");
> 72:         int bytesPerWord = runsOn32Bit ? 4 : 8;
> 73:         int objectHeaderSize = runsOn32Bit ? 12 : 16;

This seems a separate bug fix. ??

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

PR Review: https://git.openjdk.org/jdk/pull/28366#pullrequestreview-3776771990
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2785847854
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2785905985

From dholmes at openjdk.org  Tue Feb 10 05:43:53 2026
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Feb 2026 05:43:53 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v5]
In-Reply-To: <crsYU_Tu05BFWgbBK3eFianA3GQ1zHl3Og9EgY7FRtI=.4976b9da-ef03-4f7e-b84c-12bbd8136b23@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <V-Whc7AbQjp9KB3mixDSUX0MTDBgVLZreyI_PVIZdX0=.e4ebc8f5-a9c4-441d-8382-5ad65121dfad@github.com>
 <crsYU_Tu05BFWgbBK3eFianA3GQ1zHl3Og9EgY7FRtI=.4976b9da-ef03-4f7e-b84c-12bbd8136b23@github.com>
Message-ID: <V9lEofSjDK3H28hnL0NCJrtwlZQ-eqO-uHfkvnIUAYs=.489e1be2-8c88-4774-9f6d-dc68c28577a0@github.com>

On Thu, 4 Dec 2025 07:02:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/cds/archiveBuilder.cpp line 653:
>> 
>>> 651:       dump_region->allocate(sizeof(address));
>>> 652:     }
>>> 653: #ifdef _LP64
>> 
>> Not obvious this isn't still needed.
>
> That is a small simplification that should have been part of https://bugs.openjdk.org/browse/JDK-8363998. The test
> 
> 
> alignment = nth_bit(ArchiveBuilder::precomputed_narrow_klass_shift());
> 
> 
> can be applied to 32-bit, too. There, precomputed_narrow_klass_shift() is zero.

Okay

>> src/hotspot/share/cds/archiveBuilder.cpp line 1120:
>> 
>>> 1118: };
>>> 1119: 
>>> 1120: #ifdef _LP64
>> 
>> Again not clear why this can be removed.
>
> Same reasoning. 32-bit now also uses narrow Klass pointers, so that code can be made unconditionally compilable.

Okay

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2785855099
PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2785855868

From dholmes at openjdk.org  Tue Feb 10 05:43:55 2026
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Feb 2026 05:43:55 GMT
Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v4]
In-Reply-To: <eUCHvEbYBWdncYd3-tOx1zgDeUJY0GyV5Q6152PDZXI=.d0edfbbe-9e16-4994-84c8-a7c477b95537@github.com>
References: <sfR3V8hppzb78GCUTQfsY0dd8LCgzWvMc_l05UKdSgk=.fde4f120-ba87-4de7-9a81-d28a50a492ef@github.com>
 <jedU_ilFWTbEPv8RFDP9uPw7T9-tO5V_ETTw-2Ial3g=.2a930bec-f4d7-406b-ac29-d64e7b106b03@github.com>
 <C27hTdtvSPVlY5_SA2im3ONCPPNOloeng31CVDJI7Ok=.70867e89-be37-48d1-ba49-063a6c28ce96@github.com>
 <eUCHvEbYBWdncYd3-tOx1zgDeUJY0GyV5Q6152PDZXI=.d0edfbbe-9e16-4994-84c8-a7c477b95537@github.com>
Message-ID: <WpAblfbv3agTBuRux5VZWR5zXw1f_rQRUDEGntWe1fY=.edf3d581-67f0-4a85-b37a-6259d4011e56@github.com>

On Mon, 9 Feb 2026 07:03:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/memory/metaspace.cpp line 661:
>> 
>>> 659:   MaxMetaspaceSize = MAX2(MaxMetaspaceSize, commit_alignment());
>>> 660: 
>>> 661:   if (using_class_space()) {
>> 
>> Shouldn't this now just be a build-time `ifdef _LP64` check?
>
> It is. using_class_space is true on LP64, false on 32-bit. Mostly a matter of taste. I kept the function here since it conveys more information than just a blank ifdef. And this approach (if uses as negation) minimizes compile errors on the other side since nobody bothers to build on 32-bit anymore.
> 
> I have no strong emotions, though. If reviewers prefer it, I'll replace it with a blank ifdef _LP64.

I prefer it simply so we can see this is truly a build-time check and not a run-time check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2785863849

From duke at openjdk.org  Tue Feb 10 06:00:16 2026
From: duke at openjdk.org (Harshit470250)
Date: Tue, 10 Feb 2026 06:00:16 GMT
Subject: RFR: 8377035: [s390x] Disable JSR166 test cases which uses virtual
 threads [v2]
In-Reply-To: <UiSM3r5RcrgWM8pOA7yDk7BU6yCxi5N48vBqKVBE0oc=.beb187c2-f639-44d1-94bc-50f8589389d1@github.com>
References: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
 <UiSM3r5RcrgWM8pOA7yDk7BU6yCxi5N48vBqKVBE0oc=.beb187c2-f639-44d1-94bc-50f8589389d1@github.com>
Message-ID: <eN43jMNcDvSaMOsKH9jYBaH8OqkztSD4OQtBgx9alvM=.fe67ff5f-8f82-4ffd-9802-264c3d8bd05d@github.com>

On Fri, 6 Feb 2026 05:45:09 GMT, Harshit470250 <duke at openjdk.org> wrote:

>> ReentrantReadWriteLock20Test.java is failing on s390 due to virtual threads which are not yet implemented on s390. 
>> SynchronousQueue20Test.java also uses virtual thread so I am also disabling it.
>
> Harshit470250 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change to use Platform.isS390

STARTED    ReentrantReadWriteLock20Test::test66kReadersFair 'test66kReadersFair'
java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached

Yes, this test also fails on my Mac with these flags(-XX:+UnlockExperimentalVMOptions -XX:-VMContinuations) with fastdebug.

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

PR Comment: https://git.openjdk.org/jdk/pull/29555#issuecomment-3875498699

From jbhateja at openjdk.org  Tue Feb 10 06:01:42 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 10 Feb 2026 06:01:42 GMT
Subject: RFR: 8377355: VectorAPI source generation broken after JDK-8371187
In-Reply-To: <ufXKssaCGB9gmWLWeWxyGdkkBIlGpaKp824niSfInXA=.18d63ded-551b-487e-a67e-00d7d7bc6369@github.com>
References: <ufXKssaCGB9gmWLWeWxyGdkkBIlGpaKp824niSfInXA=.18d63ded-551b-487e-a67e-00d7d7bc6369@github.com>
Message-ID: <GLHOOBPoBY73LdCgLpVn4pv0gZVMXJD5ZjAIi6m5IAU=.5bbe5a09-499d-485a-a39e-8c69f32b4c01@github.com>

On Fri, 6 Feb 2026 20:33:32 GMT, Varada M <varadam at openjdk.org> wrote:

> Added the missing definition of 'swapIfNeeded' in X-Vector.java.template 
> 
> JBS : [JDK-8377355](https://bugs.openjdk.org/browse/JDK-8377355)

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 5396:

> 5394:     }
> 5395: 
> 5396:     @Override

For sake of uniformity you should add /*package-private*/ comment over newly defined swapIfNeeded method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29616#discussion_r2785954622

From eirbjo at openjdk.org  Tue Feb 10 06:05:15 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 10 Feb 2026 06:05:15 GMT
Subject: RFR: 8377461: Add ZipFile test for incorrect number of entries
 reported in ENDTOT [v2]
In-Reply-To: <HNKqPs_z16aAUi5uScwFT9ICjbLZDGZEJOSF-kuHdNo=.249a67d7-a6c1-4991-9777-f2e8f1d85c72@github.com>
References: <HNKqPs_z16aAUi5uScwFT9ICjbLZDGZEJOSF-kuHdNo=.249a67d7-a6c1-4991-9777-f2e8f1d85c72@github.com>
Message-ID: <RqlFKeEz2JQJ78l19QbBposccrVjxN1dZ4Dzcneiorc=.a1baf880-345e-483c-97ca-7a45b5da4938@github.com>

> Please review this PR introducing a test to verify that `ZipFile::size` reports the actual number of CEN entries in a ZIP file, despite an incorrect number being reported in the END header.
> 
> Background:
> 
> The `ZipFile` implementation treats `ENDTOT` as an indication, but falls back to counting CEN entries if this number is too low. After parsing the CEN, there is also code to adjust the total down to the actual count of CEN entries.
> 
> The behavior of always reporting the actual number of CEN entries has no current test coverage in the JDK. It seems good to have tests excercising these code paths and protecting against regressions in this area.
> 
> Verification:
> 
> Verified that the new test catches introduced regressions in handling over- and underreported numbers in ENDTOT and that no existing test catches such regressions.
> 
> Test-only change, `noreg-self`.

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

 - Add case: Empty ZIP, correct ENDTOT
 - Copyright 2026 for new test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29635/files
  - new: https://git.openjdk.org/jdk/pull/29635/files/c499a9c5..5bc8b762

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

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

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

From eirbjo at openjdk.org  Tue Feb 10 06:05:17 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 10 Feb 2026 06:05:17 GMT
Subject: RFR: 8377461: Add ZipFile test for incorrect number of entries
 reported in ENDTOT [v2]
In-Reply-To: <p6Jh-wvi1qCsE6wo0jPOYEO5hgzfpMZR98mr-aYqgaU=.63f89763-7388-4f7f-be27-d5b45973aca7@github.com>
References: <HNKqPs_z16aAUi5uScwFT9ICjbLZDGZEJOSF-kuHdNo=.249a67d7-a6c1-4991-9777-f2e8f1d85c72@github.com>
 <p6Jh-wvi1qCsE6wo0jPOYEO5hgzfpMZR98mr-aYqgaU=.63f89763-7388-4f7f-be27-d5b45973aca7@github.com>
Message-ID: <72zd0w0OOvd4Pr5mOx4JgVpml0J2FuoEfpyOq23T8Vo=.72e93aca-9ec0-466e-aec5-3f70444b9c6a@github.com>

On Mon, 9 Feb 2026 19:02:45 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add case: Empty ZIP, correct ENDTOT
>>  - Copyright 2026 for new test
>
> test/jdk/java/util/zip/ZipFile/IncorrectEndTot.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> I believe this is a new Test so 2026 is what we need for the copyright

Thanks for catching this copy/paste :-)

> test/jdk/java/util/zip/ZipFile/IncorrectEndTot.java line 60:
> 
>> 58:                 Arguments.of(10, 11), // CEN has one less than ENDTOT
>> 59:                 Arguments.of(11, 10), // CEN has one more than ENDTOT
>> 60:                 Arguments.of(0, 10)   // No CEN entries (empty ZIP)
> 
> Should you include Arguments.of(0, 0) to test an empty ZIP?

Good idea. Added a normal case for empty ZIP.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29635#discussion_r2785963555
PR Review Comment: https://git.openjdk.org/jdk/pull/29635#discussion_r2785964614

From syan at openjdk.org  Tue Feb 10 06:10:43 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 10 Feb 2026 06:10:43 GMT
Subject: RFR: 8376023: Reconcile ClassUnloader with ClassUnloadCommon [v2]
In-Reply-To: <DQiE_NMXE9at90pQX_QN-y-lhubuI2VAQjKthhxSr50=.1fe833cd-f739-4ea5-96ba-1367e3776fc9@github.com>
References: <M2_xq-zZRd-QlR-eraizOWbVzohTC8rIlo1ZdyOa8fw=.f5feb9df-74e2-436b-a8d4-c7aa4bfe42c2@github.com>
 <DQiE_NMXE9at90pQX_QN-y-lhubuI2VAQjKthhxSr50=.1fe833cd-f739-4ea5-96ba-1367e3776fc9@github.com>
Message-ID: <790OnwGGtKfojNljcln--Fbvtt9d_ceUVwAE_ObRJ0k=.cb2bfb7a-799c-4b99-b406-cac19aa69590@github.com>

On Tue, 10 Feb 2026 03:26:27 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR merge test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java to test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java, and make the vmTestbase tests use the ClassUnloadCommon.
>> 
>> The core method in test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java is `boolean unloadClass()`, and the core method in test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java is `Set<String> triggerUnloading(List<String> classNames)`, it's not easy to combile these two methods to one. So I keep all these two methods.
>> 
>> Additional testing:
>> 
>> - [x] Full jtreg tests include vmTestbase
>
> SendaoYan 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:
> 
>  - Fix missed attempt++
>  - Add "import jdk.test.lib.classloader.CustomClassLoader;" for vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t002/TestDescription.java etc..
>  - Adapt DEFAULT_BREAKPOINT_LINE from 63 to 65, since two lines added to test/hotspot/jtreg/vmTestbase/nsk/share/jpda/AbstractDebuggeeTest.java
>  - Add "import jdk.test.lib.classloader.ClassFileFinder"
>  - fix vmTestbase/nsk/jdi/Scenarios/invokeMethod/redefineclasses001/TestDescription.java fails "cannot find symbol ClassFileFind"
>  - sed -i "s|import nsk.share.CustomClassLoader;|import jdk.test.lib.classloader.CustomClassLoader;|" `grep nsk.share.CustomClassLoader test/ -rnl `
>  - Fix test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadEvent/className/classname001/TestDescription.java fails "cannot find user-defined classloader loaded: nsk.share.CustomClassLoader"
>  - Fix javac error: "AbstractDebuggeeTest.java:103: error: cannot find symbol"
>  - Merge branch 'openjdk:master' into jbs8376023
>  - Fix comment in test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/reflectedType/reflectype002/TestDescription.java
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/9c96cfff...bff25ebf

I think we should close this PR, and I will unassign the JBS issue to myself. But I still interesting does the issue has more elegant solution.

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

PR Comment: https://git.openjdk.org/jdk/pull/29545#issuecomment-3875526960

From syan at openjdk.org  Tue Feb 10 06:10:44 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 10 Feb 2026 06:10:44 GMT
Subject: Withdrawn: 8376023: Reconcile ClassUnloader with ClassUnloadCommon
In-Reply-To: <M2_xq-zZRd-QlR-eraizOWbVzohTC8rIlo1ZdyOa8fw=.f5feb9df-74e2-436b-a8d4-c7aa4bfe42c2@github.com>
References: <M2_xq-zZRd-QlR-eraizOWbVzohTC8rIlo1ZdyOa8fw=.f5feb9df-74e2-436b-a8d4-c7aa4bfe42c2@github.com>
Message-ID: <PgMgReLj31r5W05SBvcSB--E-t2kZ9fSpIwKPllWf4U=.8e4a70ce-cdcb-460f-b027-6c13629bbb66@github.com>

On Tue, 3 Feb 2026 14:24:21 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This PR merge test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java to test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java, and make the vmTestbase tests use the ClassUnloadCommon.
> 
> The core method in test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java is `boolean unloadClass()`, and the core method in test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java is `Set<String> triggerUnloading(List<String> classNames)`, it's not easy to combile these two methods to one. So I keep all these two methods.
> 
> Additional testing:
> 
> - [x] Full jtreg tests include vmTestbase

This pull request has been closed without being integrated.

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

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

From liach at openjdk.org  Tue Feb 10 06:12:40 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 10 Feb 2026 06:12:40 GMT
Subject: RFR: 8377355: VectorAPI source generation broken after JDK-8371187
In-Reply-To: <GLHOOBPoBY73LdCgLpVn4pv0gZVMXJD5ZjAIi6m5IAU=.5bbe5a09-499d-485a-a39e-8c69f32b4c01@github.com>
References: <ufXKssaCGB9gmWLWeWxyGdkkBIlGpaKp824niSfInXA=.18d63ded-551b-487e-a67e-00d7d7bc6369@github.com>
 <GLHOOBPoBY73LdCgLpVn4pv0gZVMXJD5ZjAIi6m5IAU=.5bbe5a09-499d-485a-a39e-8c69f32b4c01@github.com>
Message-ID: <u6ZpsEujm_mwJAgAAGIpwP6RsSEC1o5n4eS_-tePOKA=.5e1fd123-d0dd-4bb1-b90c-0329665ed468@github.com>

On Tue, 10 Feb 2026 05:57:47 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Added the missing definition of 'swapIfNeeded' in X-Vector.java.template 
>> 
>> JBS : [JDK-8377355](https://bugs.openjdk.org/browse/JDK-8377355)
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 5396:
> 
>> 5394:     }
>> 5395: 
>> 5396:     @Override
> 
> For sake of uniformity you should add /*package-private*/ comment over newly defined swapIfNeeded method.

I think not having that is fine, the classes already have many package-private method without such a comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29616#discussion_r2785991455

From eirbjo at openjdk.org  Tue Feb 10 06:13:47 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 10 Feb 2026 06:13:47 GMT
Subject: RFR: 8377461: Add ZipFile test for incorrect number of entries
 reported in ENDTOT [v2]
In-Reply-To: <p6Jh-wvi1qCsE6wo0jPOYEO5hgzfpMZR98mr-aYqgaU=.63f89763-7388-4f7f-be27-d5b45973aca7@github.com>
References: <HNKqPs_z16aAUi5uScwFT9ICjbLZDGZEJOSF-kuHdNo=.249a67d7-a6c1-4991-9777-f2e8f1d85c72@github.com>
 <p6Jh-wvi1qCsE6wo0jPOYEO5hgzfpMZR98mr-aYqgaU=.63f89763-7388-4f7f-be27-d5b45973aca7@github.com>
Message-ID: <WXCOodSWElZ_td3l9WkJaNRR_1UuMKlGqxMUs03P-3Q=.f3625451-06af-4661-aba1-38b64f7f1a80@github.com>

On Mon, 9 Feb 2026 21:10:22 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> A follow one would be to also check:
> 
> 4.3.15 Zip64 end of central directory locator
> 
> but can be a follow on project

I considered ZIP64, but found that the code under test  is blissfully unaware of the source of the ENDOT number.

So adding cases for Zip64 would complicate the test without adding test coverage for initCEN (it would test findEND instead which is a different issue). 

This analysis leans on a white-box view of the implementation, but I think that should be okay for this test since the behavior for this edge case seems unspecified anyhow.

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

PR Comment: https://git.openjdk.org/jdk/pull/29635#issuecomment-3875535012

From alanb at openjdk.org  Tue Feb 10 06:19:40 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Feb 2026 06:19:40 GMT
Subject: Integrated: 8377411:
 java/lang/Thread/virtual/stress/ParkAfterTimedPark.java only testing pinned
 case
In-Reply-To: <8qZaQWwThjatuQE08vr5VRg_kA7bAjcgjAr1i-MEuDQ=.8a8e05f6-d483-428a-a3e4-65d9d4b08a95@github.com>
References: <8qZaQWwThjatuQE08vr5VRg_kA7bAjcgjAr1i-MEuDQ=.8a8e05f6-d483-428a-a3e4-65d9d4b08a95@github.com>
Message-ID: <ihXMgyCqXKZ9R3BPrmPFZZqg29K-EJ1Sdbk-G3SfAmU=.b2cadb22-0535-49a3-88c7-c914bc663033@github.com>

On Mon, 9 Feb 2026 10:29:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Recently added test java/lang/Thread/virtual/stress/ParkAfterTimedPark.java has a parameter to indicate if the target thread is pinned or not. I fat fingered the conversion of a test with the result that the "pinned" parameter is ignored and the tests unconditionally tests the pinned case, not the unpinned case.

This pull request has now been integrated.

Changeset: 996ca4b4
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/996ca4b44bff2f782b775ee7ca496544e5982774
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8377411: java/lang/Thread/virtual/stress/ParkAfterTimedPark.java only testing pinned case

Reviewed-by: vklang

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

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

From jpai at openjdk.org  Tue Feb 10 06:45:10 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Feb 2026 06:45:10 GMT
Subject: RFR: 8377457: java/util/logging/ParentLoggersTest.java failed
 intermittently
In-Reply-To: <svnEUsJ4X3Jx0e9XbXVSvYZa4sIGS2z6CgDLLEj1uP0=.f34489e6-9b0c-4b53-a79a-e896a8c0062d@github.com>
References: <svnEUsJ4X3Jx0e9XbXVSvYZa4sIGS2z6CgDLLEj1uP0=.f34489e6-9b0c-4b53-a79a-e896a8c0062d@github.com>
Message-ID: <vP_21tu5kDNsRjnd0-61u_VJD4yErKoYu7F2vx8Wx0U=.d28eaa8c-9bb6-4cb8-8800-b7ed1c51ba73@github.com>

On Mon, 9 Feb 2026 10:35:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> `java/util/logging/ParentLoggersTest.java` has been observed failing intermittently - nut rarely - in the loom repo.
> After inspection of the code Logger::doSetParent was found to do multiple read of the volatile `parent` field. After changing the method to do a single read the test has no longer been observed failing.

Hello Daniel, the `volatile` `parent` is only set in the `doSetParent()` method - the one which is being updated in this PR. That update to `parent` happens within a `synchronized` block. Even the read of that `parent` happens after acquiring that monitor. Given this, I don't see why reading that value multiple times (after the monitor lock is acquired) would cause the issue. The existing test that is failing is a bit involved and this is the first time I'm looking at it, so I haven't yet understood what the failure is.

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

PR Comment: https://git.openjdk.org/jdk/pull/29634#issuecomment-3875663421

From jbhateja at openjdk.org  Tue Feb 10 07:09:40 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 10 Feb 2026 07:09:40 GMT
Subject: RFR: 8377355: VectorAPI source generation broken after JDK-8371187
In-Reply-To: <ufXKssaCGB9gmWLWeWxyGdkkBIlGpaKp824niSfInXA=.18d63ded-551b-487e-a67e-00d7d7bc6369@github.com>
References: <ufXKssaCGB9gmWLWeWxyGdkkBIlGpaKp824niSfInXA=.18d63ded-551b-487e-a67e-00d7d7bc6369@github.com>
Message-ID: <LyvprdPgcZnbYzvA9JpYY9MP8oiN5_vxxh3G_xx84aw=.44a731d9-9e73-4ed4-a880-994518b7daaf@github.com>

On Fri, 6 Feb 2026 20:33:32 GMT, Varada M <varadam at openjdk.org> wrote:

> Added the missing definition of 'swapIfNeeded' in X-Vector.java.template 
> 
> JBS : [JDK-8377355](https://bugs.openjdk.org/browse/JDK-8377355)

Marked as reviewed by jbhateja (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29616#pullrequestreview-3777092868

From jbhateja at openjdk.org  Tue Feb 10 07:09:43 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 10 Feb 2026 07:09:43 GMT
Subject: RFR: 8377355: VectorAPI source generation broken after JDK-8371187
In-Reply-To: <u6ZpsEujm_mwJAgAAGIpwP6RsSEC1o5n4eS_-tePOKA=.5e1fd123-d0dd-4bb1-b90c-0329665ed468@github.com>
References: <ufXKssaCGB9gmWLWeWxyGdkkBIlGpaKp824niSfInXA=.18d63ded-551b-487e-a67e-00d7d7bc6369@github.com>
 <GLHOOBPoBY73LdCgLpVn4pv0gZVMXJD5ZjAIi6m5IAU=.5bbe5a09-499d-485a-a39e-8c69f32b4c01@github.com>
 <u6ZpsEujm_mwJAgAAGIpwP6RsSEC1o5n4eS_-tePOKA=.5e1fd123-d0dd-4bb1-b90c-0329665ed468@github.com>
Message-ID: <sLF7cYIKL92Oj1DZcZ9Z46eDovkIw5mQjJCDIJoITMw=.227f2c9e-8e9a-483d-9552-69758a8aa0f3@github.com>

On Tue, 10 Feb 2026 06:10:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 5396:
>> 
>>> 5394:     }
>>> 5395: 
>>> 5396:     @Override
>> 
>> For sake of uniformity you should add /*package-private*/ comment over newly defined swapIfNeeded method.
>
> I think not having that is fine, the classes already have many package-private method without such a comment.

Sounds reasonable. Not a blocker.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29616#discussion_r2786172501

From jbhateja at openjdk.org  Tue Feb 10 07:14:14 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 10 Feb 2026 07:14:14 GMT
Subject: RFR: 8376794: Enable copy and mismatch Partial Inlining for AMD
 AVX512 targets
In-Reply-To: <LIdQi9c0pTKY9GZJoZVnpKC7DRYZYaATzujDQTPSyvY=.b0d8ee2f-bc7b-4174-b7f4-6e3cddc4721d@github.com>
References: <LIdQi9c0pTKY9GZJoZVnpKC7DRYZYaATzujDQTPSyvY=.b0d8ee2f-bc7b-4174-b7f4-6e3cddc4721d@github.com>
Message-ID: <TLUC4N2g4DgI-OjjibNAM-Oyc-GI4NU6oG519ucCqUk=.5b8f213d-8ea0-467e-9dc0-3962a7c287a8@github.com>

On Mon, 2 Feb 2026 10:37:16 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Partial in-lining handles copy and mismatch for small array sizes less than -XX:ArrayOperationPartialInlineSize bytes through JIT code rather than calling optimized stubs thereby saving costly call overhead.
> 
> Enabling partial in-lining optimization for AMD EPYC servers supporting AVX-512 feature.
> 
> Following are the performance numbers on Turin at fixed frequency of 2.1GHz
> 
> <img width="440" height="440" alt="image" src="https://github.com/user-attachments/assets/14b55ee3-b65c-4247-8739-67f1b94dceb4" />
> <img width="440" height="300" alt="image" src="https://github.com/user-attachments/assets/c00d6443-45a2-4277-961d-580ceea5da88" />
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Hi @TobiHartmann , Can you kindly run this through oracle test infra and approve.

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

PR Comment: https://git.openjdk.org/jdk/pull/29519#issuecomment-3875769947

From jpai at openjdk.org  Tue Feb 10 07:18:29 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Feb 2026 07:18:29 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v2]
In-Reply-To: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
Message-ID: <uCBWCGwiMKmxpiZA5p0WizHWKYrjU0xhhxP0T6QMhVg=.318915fb-5a88-416a-bb02-8066ac8baff3@github.com>

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?
> 
> The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.
> 
> When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.
> 
> When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.
> 
> Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `OutputStream` is a `Bu...

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

  add comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29638/files
  - new: https://git.openjdk.org/jdk/pull/29638/files/6cef01f3..f8b8165d

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

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

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

From jpai at openjdk.org  Tue Feb 10 07:22:24 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Feb 2026 07:22:24 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v2]
In-Reply-To: <uCBWCGwiMKmxpiZA5p0WizHWKYrjU0xhhxP0T6QMhVg=.318915fb-5a88-416a-bb02-8066ac8baff3@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
 <uCBWCGwiMKmxpiZA5p0WizHWKYrjU0xhhxP0T6QMhVg=.318915fb-5a88-416a-bb02-8066ac8baff3@github.com>
Message-ID: <-XwpFAkqFhgwzBpfWlVM-cZvIHN-B1u4YSI4dTjp7FQ=.3bddcc52-8d0f-4e70-9cbf-aaf14084411a@github.com>

On Tue, 10 Feb 2026 07:18:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?
>> 
>> The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.
>> 
>> When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.
>> 
>> When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.
>> 
>> Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `Outp...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comment

Thank you Weibing for running your test and thank you Daniel and Michael for the inputs. I've updated this PR to not rely on `useable` field and instead rely on the `com.sun.jndi.ldap.LdapRequest` itself to decide whether or not to send an "abandon request" message over the connection. The `LdapRequest` has the necessary detail whether a connection is closed or not and if the connection is closed then we skip the BER message creation and sending of that message over the stream.

> The BER stream is dumped to tracefile although not request is being sent, that is wrong.

As a separate activity, I will check other places where this might be happening. With the current proposed update to the PR, this no longer happens for the abandon request.

With the changes in this PR, tier1, tier2 and tier3 tests passed and test repeat of 50 for `test/jdk/com/sun/jndi/ldap/` too completed without issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/29638#issuecomment-3875796425

From varadam at openjdk.org  Tue Feb 10 07:31:51 2026
From: varadam at openjdk.org (Varada M)
Date: Tue, 10 Feb 2026 07:31:51 GMT
Subject: RFR: 8377355: VectorAPI source generation broken after JDK-8371187
In-Reply-To: <1bXilOxtJCU8PQfVtJa8o1N3yP7kMf4g8EdRt91XHZc=.1ebb2db5-3a5d-4bbb-bce5-1a901923ee8a@github.com>
References: <ufXKssaCGB9gmWLWeWxyGdkkBIlGpaKp824niSfInXA=.18d63ded-551b-487e-a67e-00d7d7bc6369@github.com>
 <1bXilOxtJCU8PQfVtJa8o1N3yP7kMf4g8EdRt91XHZc=.1ebb2db5-3a5d-4bbb-bce5-1a901923ee8a@github.com>
Message-ID: <Xf8Vb5V990rR-fq-FePn4qyLHbX2A4qP9kGCN3tEgks=.abbeb7f3-663c-4365-9966-cba56b73dc38@github.com>

On Mon, 9 Feb 2026 12:44:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Added the missing definition of 'swapIfNeeded' in X-Vector.java.template 
>> 
>> JBS : [JDK-8377355](https://bugs.openjdk.org/browse/JDK-8377355)
>
> LGTM, the code is now identical from running the script.
> 
> Please wait for another reviewer.

Thank you @liach and @jatin-bhateja

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

PR Comment: https://git.openjdk.org/jdk/pull/29616#issuecomment-3875827008

From varadam at openjdk.org  Tue Feb 10 07:31:53 2026
From: varadam at openjdk.org (Varada M)
Date: Tue, 10 Feb 2026 07:31:53 GMT
Subject: Integrated: 8377355: VectorAPI source generation broken after
 JDK-8371187
In-Reply-To: <ufXKssaCGB9gmWLWeWxyGdkkBIlGpaKp824niSfInXA=.18d63ded-551b-487e-a67e-00d7d7bc6369@github.com>
References: <ufXKssaCGB9gmWLWeWxyGdkkBIlGpaKp824niSfInXA=.18d63ded-551b-487e-a67e-00d7d7bc6369@github.com>
Message-ID: <ZFppFoybdg6NqKZ1uon-qqDhguQ_hSwSwbhaFAlR3o8=.5e97dca0-1000-448b-ae79-e3b86f3b5e00@github.com>

On Fri, 6 Feb 2026 20:33:32 GMT, Varada M <varadam at openjdk.org> wrote:

> Added the missing definition of 'swapIfNeeded' in X-Vector.java.template 
> 
> JBS : [JDK-8377355](https://bugs.openjdk.org/browse/JDK-8377355)

This pull request has now been integrated.

Changeset: b8088941
Author:    Varada M <varadam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8088941c8f1ef803bd0592b945d3e1ab5c15bee
Stats:     17 lines in 2 files changed: 16 ins; 1 del; 0 mod

8377355: VectorAPI source generation broken after JDK-8371187

Reviewed-by: liach, jbhateja

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

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

From aartemov at openjdk.org  Tue Feb 10 09:02:16 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 10 Feb 2026 09:02:16 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v8]
In-Reply-To: <4F7FK2EEtv90y37ECqa2nzt8Hnt7TVi7DNX874B9x94=.eeb5db92-690e-45e9-8ee8-a754f9c69487@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <p57-Mga85sxN41Hdd9JTLGNVazIrkfDjNtCIhz70-ME=.86050f09-06e0-4c6e-80ac-39794153f806@github.com>
 <HTq4KPrH8lZTVHT6_D3Gi1gMTzernd90gAPzZVEJT5c=.953c4ce3-6ee4-4d4c-9036-92763471579d@github.com>
 <Zgjlew-K02IYZ-EjoENRQzL8higlLSBGQ3Pr7VzA4CA=.2251ba23-b851-410e-900f-8a9f5a6bd1d7@github.com>
 <0w6KoryTq1Rb_a-q9eAULoFrGDLN-Jd_N12W-XwA5ns=.91e55f80-2bc0-44e2-be03-52c0cd1d8d07@github.com>
 <4F7FK2EEtv90y37ECqa2nzt8Hnt7TVi7DNX874B9x94=.eeb5db92-690e-45e9-8ee8-a754f9c69487@github.com>
Message-ID: <ajKha_CVvbtAdedXtB-bgPRJpXPWiy56moPMG61ttmk=.33eb9dd6-a521-4621-897d-e9f1f21c4dec@github.com>

On Tue, 10 Feb 2026 02:03:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> @jddarcy What is the purpose of such methods that do not seem to be invoked?
>
>> @jddarcy What is the purpose of such methods that do not seem to be invoked?
> 
> I'm a bit confused; they do look to be used in that test file; e.g.
> 
> https://github.com/openjdk/jdk/blame/f9ded7f88cce75151cec32d1ef1f9662ea10431a/test/jdk/java/lang/Math/HyperbolicTests.java#L251
> 
> `            failures += testSinhCaseWithUlpDiff(testCase[0],`

@jddarcy The concern is methods testing with tolerance, e.g. `testSinhCaseWithTolerance`. That one is never used. Same for `testCoshCaseWithTolerance`, `testTanhCaseWithTolerance`. If they are to be removed, I suggest to make is in a separate cleanup PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2786675697

From cushon at openjdk.org  Tue Feb 10 09:12:45 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 10 Feb 2026 09:12:45 GMT
Subject: Integrated: 8208752: Calling a deserialized Lambda might fail with
 ClassCastException
In-Reply-To: <XymdjugFQvrNU3zsz9KekcQ_WAEragtZv5dcGRAJjFM=.d718ce22-a12b-484d-87d1-c6e387759f2d@github.com>
References: <XymdjugFQvrNU3zsz9KekcQ_WAEragtZv5dcGRAJjFM=.d718ce22-a12b-484d-87d1-c6e387759f2d@github.com>
Message-ID: <if5QS3Wjz-JbWAMm_8lS0XRH1v9h3MHmD9MpeCgwSFU=.ba46010f-69b5-4149-bcf7-e1a6484f0a22@github.com>

On Sun, 21 Dec 2025 14:02:55 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> See [JDK-8208752: Calling a deserialized Lambda might fail with ClassCastException](https://bugs.openjdk.org/browse/JDK-8208752).
> 
> Lambda deserialization currently does not consider `SerializedLambda#getInstantiatedMethodType` when deserializing lambdas, which can lead to method references that differ only in `getInstantiatedMethodType` being merged into the same lambda instance, and can result in `ClassCastException`s like the one reported in the bug.
> 
> This depends on the fix for [JDK-8374654: Inconsistent handling of lambda deserialization for Object method references on interfaces](https://bugs.openjdk.org/browse/JDK-8374654) in https://github.com/openjdk/jdk/pull/29075.

This pull request has now been integrated.

Changeset: 665dc490
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/665dc490c2a1bcaa1fa1cf6f0ea2396ce4b31863
Stats:     188 lines in 8 files changed: 163 ins; 0 del; 25 mod

8208752: Calling a deserialized Lambda might fail with ClassCastException
8374654: Inconsistent handling of lambda deserialization for Object method references on interfaces

Reviewed-by: vromero, jlahoda

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

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

From aartemov at openjdk.org  Tue Feb 10 09:14:39 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 10 Feb 2026 09:14:39 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v10]
In-Reply-To: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
Message-ID: <HxqaYXjh3-BJhluIVcNN6pZrIKE826oIVuFPguO4H7Y=.f7a696d9-6753-48ca-9c70-bea1b0972bd6@github.com>

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM asinh method.
> 
> Original C vs transliteration port:
> 
> 
> $ diff -w fdlib_asinh.c Asinh.translit.java
> 1c1,3
> < /* asinh(x)
> ---
>> /**
>> * Return the Inverse Hyperbolic Sine of x
>> *
> 2a5
>> *
> 10a14,17
>> private static final class Asinh {
>>       private static final double one = 1.0;
>>       private static final double ln2 = 6.93147180559945286227e-01;
>>       private static final double huge = 1.0e300;
> 12,29c19
> < #include "fdlibm.h"
> <
> < #ifdef __STDC__
> < static const double
> < #else
> < static double
> < #endif
> < one =  1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */
> < ln2 =  6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */
> < huge=  1.00000000000000000000e+300;
> <
> < #ifdef __STDC__
> <       double asinh(double x)
> < #else
> <       double asinh(x)
> <       double x;
> < #endif
> < {
> ---
>>       static double compute(double x) {
> 39c29
> <           w = __ieee754_log(fabs(x))+ln2;
> ---
>>                       w = log(Math.abs(x))+ln2;
> 41,42c31,32
> <           t = fabs(x);
> <           w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t));
> ---
>>                       t = Math.abs(x);
>>                       w = log(2.0*t+one/(sqrt(x*x+one)+t));
> 45c35
> <           w =log1p(fabs(x)+t/(one+sqrt(one+t)));
> ---
>>                       w =log1p(Math.abs(x)+t/(one+sqrt(one+t)));
> 47a38
>>       }
> 
> Transliteration port vs more idiomatic port:
> 
> 
> $ diff -w Asinh.translit.java Asinh.fdlibm.java
> 6,9c6,12
> < *  Based on
> < *    asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ]
> < *   we have
> < *   asinh(x) := x  if  1+x*x=1,
> ---
>>  *
>>  *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF
>>  *      and sinh(asinh(x)) = x, -INF < x  < INF.
>>  *      It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x  < INF.
>>  *      1. Replace x by |x| as the function is odd.
>>  *      2.
>>  *          asinh(x) := x, if 1+x^2 = 1,
> 12a16,22
>>  *
>>  *
>>  *
>>  * Special cases:
>>  *      only asinh(0)=0 is exact for finite x.
>>  *      asinh(NaN) is NaN
>>  *      asinh(INF) is INF
> 14,15c24
> < private static final class Asinh {
> <       private static final double one = 1.0;
> ---
>> static final class Asinh {
> 24c33,35
> <               if(ix>=0x7ff00000) return x+x;  /* x is inf or NaN */
> ---
>>               if(ix >= 0x7ff00000) {
>>                       return x + x;                       /* x is inf or NaN */
>>               }
> 26c37,39
> <                       if(huge+x>one) return x;    /* return x inexact except 0...

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

  8375285: Addressed reviewer's comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29273/files
  - new: https://git.openjdk.org/jdk/pull/29273/files/7c48fec0..d81af7e9

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

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

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

From aartemov at openjdk.org  Tue Feb 10 09:14:40 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 10 Feb 2026 09:14:40 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v8]
In-Reply-To: <LRQwNw68EF9YXPXvkdgw2VfqEmbTFN2gIt58gDOZOnw=.9396f5c1-c539-408a-856d-869b24114cbd@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <p57-Mga85sxN41Hdd9JTLGNVazIrkfDjNtCIhz70-ME=.86050f09-06e0-4c6e-80ac-39794153f806@github.com>
 <HTq4KPrH8lZTVHT6_D3Gi1gMTzernd90gAPzZVEJT5c=.953c4ce3-6ee4-4d4c-9036-92763471579d@github.com>
 <Zgjlew-K02IYZ-EjoENRQzL8higlLSBGQ3Pr7VzA4CA=.2251ba23-b851-410e-900f-8a9f5a6bd1d7@github.com>
 <LRQwNw68EF9YXPXvkdgw2VfqEmbTFN2gIt58gDOZOnw=.9396f5c1-c539-408a-856d-869b24114cbd@github.com>
Message-ID: <MCjIzBCAdB0jo9fFOMO3n_fyuaz0S5J375nBje4B_jw=.01068adf-1bf1-4117-95a0-37b0b51e300b@github.com>

On Tue, 10 Feb 2026 02:44:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> I don't think we need to add anything, see above.
>
> Hmm.
> 
> I think at least one test should include a bug id for this work.
> 
> (jtreg has a feature "run all the tests associated with this bug id." I don't think that feature is widely used, but it is part of the rationale behind the policy.)

Added the umbrella issue ID there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2786726136

From aartemov at openjdk.org  Tue Feb 10 09:14:43 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 10 Feb 2026 09:14:43 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v9]
In-Reply-To: <s9J8GGUkimagDUVBBdTX1drKGLhAPgi5rl04D8EyHPs=.2f768c98-b648-47b0-9e3d-80c1231867eb@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <sBVlHSDyh6khWSX0nGj_OwhQqp2Ap3KF1shY4u2vuaI=.15594e70-4dac-4e15-a234-fb11fa441cb2@github.com>
 <s9J8GGUkimagDUVBBdTX1drKGLhAPgi5rl04D8EyHPs=.2f768c98-b648-47b0-9e3d-80c1231867eb@github.com>
Message-ID: <6SNa_nAO4BsIiiJGBU5cRCOQ9QIR1jin8nUjsHfiEC0=.395b290d-a94a-4d01-8cef-92dd1c1cf0aa@github.com>

On Tue, 10 Feb 2026 02:41:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8375285: Addressed reviewer's comments.
>
> test/jdk/java/lang/StrictMath/HyperbolicTests.java line 511:
> 
>> 509:                 {0x1.ffffffffffffep-19, 0x1.fffffffffaaa9p-19},
>> 510:                 {0x1.fffffffffffffp-18, 0x1.ffffffffeaaa9p-18},
>> 511:                 {0x1p-17, 0x1.ffffffffeaaabp-18},
> 
> Nit: I'd prefer if the second values were all aligned even if the first argument didn't take that many characters to initialize.

Noted!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2786732766

From jpai at openjdk.org  Tue Feb 10 09:41:28 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Feb 2026 09:41:28 GMT
Subject: RFR: 8377049: (zipfs) ZipException in
 ZipFileSystemProvider.newFileSystem() is swallowed
Message-ID: <C6FZXA0K-y26r8STKLd0p3IhHVMsRG2Eg9QifDPamt4=.33b07157-895b-4aab-8c51-ab5458c51630@github.com>

Can I please get a review of this change which proposes to improve the exception reported by `jdk.nio.zipfs.ZipFileSystemProvider.newFileSystem(...)` methods when a `ZipException` occurs for invalid ZIP files? This addresses https://bugs.openjdk.org/browse/JDK-8377049.

As noted in that issue the file whose `ZipException` wasn't being propagated was a JMOD file. The change here will now propagate the `ZipException` for JMOD files similar to ZIP and JAR files. The comments in that JBS issue has additional discussion about this change.

A new jtreg test has been introduced to verify this change.

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

Commit messages:
 - 8377049: (zipfs) ZipException in ZipFileSystemProvider.newFileSystem() is swallowed

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

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

From thartmann at openjdk.org  Tue Feb 10 10:00:19 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 10 Feb 2026 10:00:19 GMT
Subject: RFR: 8376794: Enable copy and mismatch Partial Inlining for AMD
 AVX512 targets
In-Reply-To: <LIdQi9c0pTKY9GZJoZVnpKC7DRYZYaATzujDQTPSyvY=.b0d8ee2f-bc7b-4174-b7f4-6e3cddc4721d@github.com>
References: <LIdQi9c0pTKY9GZJoZVnpKC7DRYZYaATzujDQTPSyvY=.b0d8ee2f-bc7b-4174-b7f4-6e3cddc4721d@github.com>
Message-ID: <E708AlnV8T1i1fLw0e8gQX9sLEw46Ssy5IGZ7gxuxtA=.16133384-0992-4636-abca-d2913e78cfdb@github.com>

On Mon, 2 Feb 2026 10:37:16 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Partial in-lining handles copy and mismatch for small array sizes less than -XX:ArrayOperationPartialInlineSize bytes through JIT code rather than calling optimized stubs thereby saving costly call overhead.
> 
> Enabling partial in-lining optimization for AMD EPYC servers supporting AVX-512 feature.
> 
> Following are the performance numbers on Turin at fixed frequency of 2.1GHz
> 
> <img width="440" height="440" alt="image" src="https://github.com/user-attachments/assets/14b55ee3-b65c-4247-8739-67f1b94dceb4" />
> <img width="440" height="300" alt="image" src="https://github.com/user-attachments/assets/c00d6443-45a2-4277-961d-580ceea5da88" />
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Sure, I'll report back once it passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/29519#issuecomment-3876578739

From jpai at openjdk.org  Tue Feb 10 10:14:43 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Feb 2026 10:14:43 GMT
Subject: RFR: 8377486: com.sun.jndi.ldap.sasl.SaslOutputStream.write() throws
 NullPointerException if it is already closed
Message-ID: <VFzdzYDNfmT0HY9lw6GHmfVQ4--FvIw8kpSyNOflHwM=.dbe7fcf4-9368-4d77-943b-b04102dbf17f@github.com>

Can I please get a review of this change which proposes to prevent the `NullPointerException` thrown from `com.sun.jndi.ldap.sasl.SaslOutputStream.write()` methods when the stream is already closed? This addresses https://bugs.openjdk.org/browse/JDK-8377486.

As noted in that issue, `OutputStream.write(...)` is specified to throw an `IOException` in such cases. The change in this PR updates the `SaslOutputStream.write()` methods to throw an `IOException` when closed.

A new test has been introduced to verify this change.

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

Commit messages:
 - add a test
 - 8377486: com.sun.jndi.ldap.sasl.SaslOutputStream.write() throws NullPointerException if it is already closed

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

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

From alanb at openjdk.org  Tue Feb 10 10:36:10 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Feb 2026 10:36:10 GMT
Subject: RFR: 8377049: (zipfs) ZipException in
 ZipFileSystemProvider.newFileSystem() is swallowed
In-Reply-To: <C6FZXA0K-y26r8STKLd0p3IhHVMsRG2Eg9QifDPamt4=.33b07157-895b-4aab-8c51-ab5458c51630@github.com>
References: <C6FZXA0K-y26r8STKLd0p3IhHVMsRG2Eg9QifDPamt4=.33b07157-895b-4aab-8c51-ab5458c51630@github.com>
Message-ID: <bQKoQLPPly4kB7Eb2-CeTrNHKE-OIU1im0xpr0mOGrI=.c362f3fe-4457-4b3d-9b06-1c849f9aebc7@github.com>

On Tue, 10 Feb 2026 09:33:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to improve the exception reported by `jdk.nio.zipfs.ZipFileSystemProvider.newFileSystem(...)` methods when a `ZipException` occurs for invalid ZIP files? This addresses https://bugs.openjdk.org/browse/JDK-8377049.
> 
> As noted in that issue the file whose `ZipException` wasn't being propagated was a JMOD file. The change here will now propagate the `ZipException` for JMOD files similar to ZIP and JAR files. The comments in that JBS issue has additional discussion about this change.
> 
> A new jtreg test has been introduced to verify this change.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java line 125:

> 123:             // file. for others, raise a UnsupportedOperationException.
> 124:             String fname = path.getFileName().toString();
> 125:             // JMOD files are expected to have (case sensitive) .jmod extension

I don't think this is strictly true but unlikely that there are JMOD files with the extension in upper case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29646#discussion_r2787147737

From jpai at openjdk.org  Tue Feb 10 10:55:57 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Feb 2026 10:55:57 GMT
Subject: RFR: 8377049: (zipfs) ZipException in
 ZipFileSystemProvider.newFileSystem() is swallowed
In-Reply-To: <bQKoQLPPly4kB7Eb2-CeTrNHKE-OIU1im0xpr0mOGrI=.c362f3fe-4457-4b3d-9b06-1c849f9aebc7@github.com>
References: <C6FZXA0K-y26r8STKLd0p3IhHVMsRG2Eg9QifDPamt4=.33b07157-895b-4aab-8c51-ab5458c51630@github.com>
 <bQKoQLPPly4kB7Eb2-CeTrNHKE-OIU1im0xpr0mOGrI=.c362f3fe-4457-4b3d-9b06-1c849f9aebc7@github.com>
Message-ID: <FLfUGoDyKlWcWAi68F64mc2ctjTssf-EKbWuhSwMB2k=.654955b7-695c-4007-940d-fcdcf6f4e2a9@github.com>

On Tue, 10 Feb 2026 10:32:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to improve the exception reported by `jdk.nio.zipfs.ZipFileSystemProvider.newFileSystem(...)` methods when a `ZipException` occurs for invalid ZIP files? This addresses https://bugs.openjdk.org/browse/JDK-8377049.
>> 
>> As noted in that issue the file whose `ZipException` wasn't being propagated was a JMOD file. The change here will now propagate the `ZipException` for JMOD files similar to ZIP and JAR files. The comments in that JBS issue has additional discussion about this change.
>> 
>> A new jtreg test has been introduced to verify this change.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java line 125:
> 
>> 123:             // file. for others, raise a UnsupportedOperationException.
>> 124:             String fname = path.getFileName().toString();
>> 125:             // JMOD files are expected to have (case sensitive) .jmod extension
> 
> I don't think this is strictly true but unlikely that there are JMOD files with the extension in upper case.

Hello Alan, I came to that conclusion based on what I see in `JmodArchive` https://github.com/openjdk/jdk/blob/master/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JmodArchive.java#L78 which rejects any file that doesn't have a case sensitive `.jmod` extension.

Would you prefer if we did a case insensitive check in this exception block like we do for ZIP and JAR files?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29646#discussion_r2787239673

From alanb at openjdk.org  Tue Feb 10 11:02:26 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Feb 2026 11:02:26 GMT
Subject: RFR: 8377049: (zipfs) ZipException in
 ZipFileSystemProvider.newFileSystem() is swallowed
In-Reply-To: <FLfUGoDyKlWcWAi68F64mc2ctjTssf-EKbWuhSwMB2k=.654955b7-695c-4007-940d-fcdcf6f4e2a9@github.com>
References: <C6FZXA0K-y26r8STKLd0p3IhHVMsRG2Eg9QifDPamt4=.33b07157-895b-4aab-8c51-ab5458c51630@github.com>
 <bQKoQLPPly4kB7Eb2-CeTrNHKE-OIU1im0xpr0mOGrI=.c362f3fe-4457-4b3d-9b06-1c849f9aebc7@github.com>
 <FLfUGoDyKlWcWAi68F64mc2ctjTssf-EKbWuhSwMB2k=.654955b7-695c-4007-940d-fcdcf6f4e2a9@github.com>
Message-ID: <MpqD4Ku9zfQzZk0k4QEvAQ5VVC_EYKtuEsXN7wJ3Sbo=.1f9fbc66-ab54-4805-97ef-a9d4f1e7cd34@github.com>

On Tue, 10 Feb 2026 10:52:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java line 125:
>> 
>>> 123:             // file. for others, raise a UnsupportedOperationException.
>>> 124:             String fname = path.getFileName().toString();
>>> 125:             // JMOD files are expected to have (case sensitive) .jmod extension
>> 
>> I don't think this is strictly true but unlikely that there are JMOD files with the extension in upper case.
>
> Hello Alan, I came to that conclusion based on what I see in `JmodArchive` https://github.com/openjdk/jdk/blob/master/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JmodArchive.java#L78 which rejects any file that doesn't have a case sensitive `.jmod` extension.
> 
> Would you prefer if we did a case insensitive check in this exception block like we do for ZIP and JAR files?

TBH, I don't think the zip provider should know anything about JMOD files, it's just unfortunate that javac relies on this to access JMOD files. I need to think about this more as it might be that the right thing is to include a simple file system provider in jdk.compiler for javac to be able to access the contents of a JMOD file as a file system.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29646#discussion_r2787276808

From dfuchs at openjdk.org  Tue Feb 10 11:05:05 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 10 Feb 2026 11:05:05 GMT
Subject: RFR: 8377457: java/util/logging/ParentLoggersTest.java failed
 intermittently
In-Reply-To: <svnEUsJ4X3Jx0e9XbXVSvYZa4sIGS2z6CgDLLEj1uP0=.f34489e6-9b0c-4b53-a79a-e896a8c0062d@github.com>
References: <svnEUsJ4X3Jx0e9XbXVSvYZa4sIGS2z6CgDLLEj1uP0=.f34489e6-9b0c-4b53-a79a-e896a8c0062d@github.com>
Message-ID: <7TjvOgnBF2Z8pXgM_bkpqkCGYYR_P26T_i_BGQVwpbQ=.b45d9c32-5078-46ec-b1f8-cf8ea9c4faf1@github.com>

On Mon, 9 Feb 2026 10:35:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> `java/util/logging/ParentLoggersTest.java` has been observed failing intermittently - nut rarely - in the loom repo.
> After inspection of the code Logger::doSetParent was found to do multiple read of the volatile `parent` field. After changing the method to do a single read the test has no longer been observed failing.

Unfortunately the logs for the failures have been lost - but IIRC the issue was that the list of expected loggers did not match the list of returned loggers. At the time the initial loggers were not printed - so I had a suspicion that the issue might have laid there. In any case, I believe the change I am proposing is a good change: the `parent` field should only be read once. The additional logging in the test may help if the test fails again, so I would like to push this change, even if the issue was effectively elsewhere.

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

PR Comment: https://git.openjdk.org/jdk/pull/29634#issuecomment-3876910746

From alanb at openjdk.org  Tue Feb 10 11:09:04 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Feb 2026 11:09:04 GMT
Subject: RFR: 8377457: java/util/logging/ParentLoggersTest.java failed
 intermittently
In-Reply-To: <svnEUsJ4X3Jx0e9XbXVSvYZa4sIGS2z6CgDLLEj1uP0=.f34489e6-9b0c-4b53-a79a-e896a8c0062d@github.com>
References: <svnEUsJ4X3Jx0e9XbXVSvYZa4sIGS2z6CgDLLEj1uP0=.f34489e6-9b0c-4b53-a79a-e896a8c0062d@github.com>
Message-ID: <wjkMdKf8HhSoOdBnjgIqu07j9nT-W-JlWcpdp0pYQWw=.fa75641c-faf4-49c8-b3e1-2034640cad83@github.com>

On Mon, 9 Feb 2026 10:35:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> `java/util/logging/ParentLoggersTest.java` has been observed failing intermittently - nut rarely - in the loom repo.
> After inspection of the code Logger::doSetParent was found to do multiple read of the volatile `parent` field. After changing the method to do a single read the test has no longer been observed failing.

The intermittent failures were with JTREG_TEST_THREAD_FACTORY=Virtual runs and it was indeed that the returned list of loggers didn't match. It was changed to read the parent field once in the loom repo and the test no longer fails.

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

PR Comment: https://git.openjdk.org/jdk/pull/29634#issuecomment-3876933536

From eirbjo at gmail.com  Tue Feb 10 11:38:46 2026
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 10 Feb 2026 12:38:46 +0100
Subject: RFD: A plan to untangle ZipFile.Source.initCEN
Message-ID: <CA+pBWhsOxYX7+efPQVMk8c_XWBf5sG0oDrVURq1kM5xAocKiGA@mail.gmail.com>

Hi,

*Summary*

Relieve ZipFile.Source.initCEN from non-parsing related responsibilities,
such that it can become a pure function for parsing and validating CEN
directories. Make it return Source, such that instance fields of this class
may become final, immutable and accessible without synchronization.

*Motivation*

The method ZipFile.Source.initCEN has been the cause of a good amount of
head-scratching over the years. It was brought over from the native
implementation when this was transitioned to Java in Java 9.

Risk assessments at that time probably constrained the code to closely
align with the native code, which together with interpreter-friendliness in
early startup have affected the current shape of this code.

It is hard to summarize the responsibilities of this method, but I'll try:

o Call findEND() to read metadata from the (Zip64) END headers in the ZIP
file, validate fields and reject invalid values
o Determine the position of the first LOC header
o Read the CEN byte array from the ZIP file
o Construct hash table data structures
o Assign these to instance fields in Source
o Parse and validate the CEN structure and populate hash table structures
o Detect manifest file(s), signature related files and multi-release JAR
versions
o Detect when a ZIP has more CEN entries than declared by the END header
and restart parsing by invoking itself recursively after counting the
actual number of CEN entries
o Detect when it is being invoked recursively to avoid reading the END and
CEN headers twice

It's been obvious for a while that this method performs an excessive number
of unrelated tasks, knows too much about the state of the object being
constructed and handles a disproportionate amount of funky control flow. It
calls out to a number of helper methods to perform parsing and validation,
some of them static, some relying on instance state.

The amount of synchronization in ZipFile today is probably excessive for
the current implementation. It made more sense back when ZipFile was backed
by native code and resources. In particular, lookup misses pay a high
relative cost to synchronization which is probably not needed.

Making Source fields final moves us in a direction which may allow us to
eventually remove synchronization for operations that only touch a parsed,
immutable CEN.

*Ideas and plan for improvements*

I think we can improve the current situation by:

o Moving END header parsing and validation out of initCEN
o Moving CEN byte array reading out of initCEN
o Making all helper methods static (it's a mix today)

At this point, initCEN will almost, but not quite be a pure function for
parsing the CEN byte array. So the next natural step is to actually make it
a pure function by:

o Making it static
o Having it return a Source instance instead of assigning to the instance
being constructed
o Making Source (mostly) immutable by marking parsed instance fields as
'final'

Rather than a big bang change, I see this effort as a step-by-step
refactoring, probably over several PRs, each focusing on a smaller aspect
of refactoring, hopefully making them easier to review. This is not an
all-or-nothing effort, most of these changes will be incremental
improvements on their own merit. If we don't get all the way, that's also
okay.

*Feedback?*

Input to this idea/plan is welcome. If someone sees reasons this may not be
a good idea, it's better to raise such concern here and now.

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260210/8af4ff27/attachment-0001.htm>

From jpai at openjdk.org  Tue Feb 10 11:43:49 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Feb 2026 11:43:49 GMT
Subject: RFR: 8377457: java/util/logging/ParentLoggersTest.java failed
 intermittently
In-Reply-To: <svnEUsJ4X3Jx0e9XbXVSvYZa4sIGS2z6CgDLLEj1uP0=.f34489e6-9b0c-4b53-a79a-e896a8c0062d@github.com>
References: <svnEUsJ4X3Jx0e9XbXVSvYZa4sIGS2z6CgDLLEj1uP0=.f34489e6-9b0c-4b53-a79a-e896a8c0062d@github.com>
Message-ID: <Ui_0W22VN3oDCjfwBvUzX3dUGq141zGG9bqZXV4jsC4=.aa74424d-b11d-4b6e-abb1-a0ba2d51f13d@github.com>

On Mon, 9 Feb 2026 10:35:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> `java/util/logging/ParentLoggersTest.java` has been observed failing intermittently - nut rarely - in the loom repo.
> After inspection of the code Logger::doSetParent was found to do multiple read of the volatile `parent` field. After changing the method to do a single read the test has no longer been observed failing.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29634#pullrequestreview-3778440655

From jpai at openjdk.org  Tue Feb 10 11:43:52 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Feb 2026 11:43:52 GMT
Subject: RFR: 8377457: java/util/logging/ParentLoggersTest.java failed
 intermittently
In-Reply-To: <7TjvOgnBF2Z8pXgM_bkpqkCGYYR_P26T_i_BGQVwpbQ=.b45d9c32-5078-46ec-b1f8-cf8ea9c4faf1@github.com>
References: <svnEUsJ4X3Jx0e9XbXVSvYZa4sIGS2z6CgDLLEj1uP0=.f34489e6-9b0c-4b53-a79a-e896a8c0062d@github.com>
 <7TjvOgnBF2Z8pXgM_bkpqkCGYYR_P26T_i_BGQVwpbQ=.b45d9c32-5078-46ec-b1f8-cf8ea9c4faf1@github.com>
Message-ID: <8P-UfWmhZaB1fmHKIAmgX7hk7g_biWwDvd2xiuC78EU=.7a71106e-e00f-4eea-9564-dea5301922bb@github.com>

On Tue, 10 Feb 2026 11:01:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> In any case, I believe the change I am proposing is a good change: the parent field should only be read once.

Yes, I agree - reading that `volatile` field just once is a good thing.

> The additional logging in the test may help if the test fails again, so I would like to push this change, even if the issue was effectively elsewhere.

That sounds fine to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/29634#issuecomment-3877080144

From jpai at openjdk.org  Tue Feb 10 11:47:09 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Feb 2026 11:47:09 GMT
Subject: RFR: 8219203: Use StringBuilder instead of StringBuffer in
 com.sun.jndi.dns.ResourceRecord
Message-ID: <c4mWSSOXzKmr0F94rqJ3I66rGNIE973qpOjOCoNFxoM=.fac4bf4e-4926-46b1-94c3-7fd2d4918079@github.com>

Can I please get a review of this change which replaces the usage of `StringBuffer` with `StringBuilder` in the methods of `com.sun.jndi.dns.ResourceRecord`? This addresses https://bugs.openjdk.org/browse/JDK-8219203.

Given the nature of the change, no new tests have been introduced.

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

Commit messages:
 - 8219203: Use Unsynchronized StringBuilder in com.sun.jndi.dns.ResourceRecord.java

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

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

From eirbjo at openjdk.org  Tue Feb 10 12:23:45 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 10 Feb 2026 12:23:45 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
Message-ID: <A2xDvWF2qEEuWMg1SzSyEWxkr4YgNAott_4A4IwLt_g=.93ab86c5-c061-4bee-a39d-775eeeccb0cd@github.com>

On Fri, 30 Jan 2026 15:56:20 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background.
>> 
>> ---
>> 
>> 
>> Benchmark                              (encoding)  (stringLength)   Mode  Cnt          Score          Error  Units
>> StringLoopJmhBenchmark.getBytes             ASCII              10  thrpt    5  406782650.595 ? 16960032.852  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII             100  thrpt    5  172936926.189 ?  4532029.201  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII            1000  thrpt    5   38830681.232 ?  2413274.766  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII          100000  thrpt    5     458881.155 ?    12818.317  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1              10  thrpt    5   37193762.990 ?  3962947.391  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1             100  thrpt    5   55400876.236 ?  1267331.434  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1            1000  thrpt    5   11104514.001 ?    41718.545  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1          100000  thrpt    5     182535.414 ?    10296.120  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16              10  thrpt    5  113474681.457 ?  8326589.199  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16             100  thrpt    5   37854103.127 ?  4808526.773  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16            1000  thrpt    5    4139833.009 ?    70636.784  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16          100000  thrpt    5      57644.637 ?     1887.112  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII              10  thrpt    5  946701647.247 ? 76938927.141  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII             100  thrpt    5  396615374.479 ? 15167234.884  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII            1000  thrpt    5  100464784.979 ?   794027.897  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII          100000  thrpt    5    1215487.689 ?     1916.468  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1              10  thrpt    5  221265102.323 ? 17013983.056  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1             100  thrpt    5  137617873.887 ?  5842185.781  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1            1000  thrpt    5   92540259.1...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename getBytesLength to getByteLength

> For completeness, here's a demo of it in `CharsetEncoder` (#29639). As expected it's possible to implement it that way and preserve equivalent performance, by adding a package visibility method to `String` and using `JavaLangAccess`. With that change, `string.getByteLength(UTF_8)` could be expressed as:
> 
> ```java
>     try {
>         int byteLength = StandardCharsets.UTF_8.newEncoder()
>                 .onUnmappableCharacter(CodingErrorAction.REPLACE)
>                 .onMalformedInput(CodingErrorAction.REPLACE)
>                 .getByteLength(stringData);
>     } catch (CharacterCodingException e) {
>         throw new IllegalStateException(e);
>     }
> ```
> 
> I can update the CSR to document this as an alternative.

This looks verbose at first sight. But I like how it allows control over coding error actions. This enables input validation and computing length in a single pass.

Your demo seems to optimize only for `CodingErrorAction.REPLACE`, but that's probably more of an implementation detail than a limiting factor of API design, right?

The demo focuses on the encoding side, but for completeness I guess the decoding side (with validation) could look like:

> ```java
>     try {
>         int stringLength = StandardCharsets.UTF_8.newDecoder()
>                 .onUnmappableCharacter(CodingErrorAction.REPORT)
>                 .onMalformedInput(CodingErrorAction.REPORT)
>                 .getDecodedLength(stringData);
>     } catch (CharacterCodingException e) {
>         throw new IllegalStateException(e);
>     }
> ``` 

Did the stateful `CharsetEncoder` created meaningfully affect your performance benchmarking?

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

PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3877259235

From cushon at openjdk.org  Tue Feb 10 13:20:31 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 10 Feb 2026 13:20:31 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
Message-ID: <zn6gQYQ3oJwF96UJFBk6GCUsanFzJQlfYhXBXb0Z_Y4=.7b1a040a-a52a-4186-a696-282d9e43cdfa@github.com>

On Fri, 30 Jan 2026 15:56:20 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background.
>> 
>> ---
>> 
>> 
>> Benchmark                              (encoding)  (stringLength)   Mode  Cnt          Score          Error  Units
>> StringLoopJmhBenchmark.getBytes             ASCII              10  thrpt    5  406782650.595 ? 16960032.852  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII             100  thrpt    5  172936926.189 ?  4532029.201  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII            1000  thrpt    5   38830681.232 ?  2413274.766  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII          100000  thrpt    5     458881.155 ?    12818.317  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1              10  thrpt    5   37193762.990 ?  3962947.391  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1             100  thrpt    5   55400876.236 ?  1267331.434  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1            1000  thrpt    5   11104514.001 ?    41718.545  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1          100000  thrpt    5     182535.414 ?    10296.120  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16              10  thrpt    5  113474681.457 ?  8326589.199  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16             100  thrpt    5   37854103.127 ?  4808526.773  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16            1000  thrpt    5    4139833.009 ?    70636.784  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16          100000  thrpt    5      57644.637 ?     1887.112  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII              10  thrpt    5  946701647.247 ? 76938927.141  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII             100  thrpt    5  396615374.479 ? 15167234.884  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII            1000  thrpt    5  100464784.979 ?   794027.897  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII          100000  thrpt    5    1215487.689 ?     1916.468  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1              10  thrpt    5  221265102.323 ? 17013983.056  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1             100  thrpt    5  137617873.887 ?  5842185.781  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1            1000  thrpt    5   92540259.1...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename getBytesLength to getByteLength

I've updated the CSR to incorporate some of the additional alternatives that were raised.
* `getEncodedLength`: both `getEncodedLength` and `getByteLength` seem like viable options. I'd appreciate input from core-libs reviewers on preferences.
* discussion of moving this to `CharsetEncoder`. My opinion is that `String` seems like a better location for this API at this point, but that both are viable options if core-libs team prefers `CharsetEncoder`.

I suggest leaving `getDecodedLength` as separate possible future work. I don't think anything in this change forecloses on the possibility of adding it later, if there are enough use-cases for it.

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

PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3877545589

From alanb at openjdk.org  Tue Feb 10 13:53:37 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Feb 2026 13:53:37 GMT
Subject: RFR: 8219203: Use StringBuilder instead of StringBuffer in
 com.sun.jndi.dns.ResourceRecord
In-Reply-To: <c4mWSSOXzKmr0F94rqJ3I66rGNIE973qpOjOCoNFxoM=.fac4bf4e-4926-46b1-94c3-7fd2d4918079@github.com>
References: <c4mWSSOXzKmr0F94rqJ3I66rGNIE973qpOjOCoNFxoM=.fac4bf4e-4926-46b1-94c3-7fd2d4918079@github.com>
Message-ID: <0cyrgCyzT0oo_i0RHenfpMJU_WHQrm5g019IGqGmYzs=.3845b3d8-88c1-4873-be2e-6cf2665861d8@github.com>

On Tue, 10 Feb 2026 11:39:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which replaces the usage of `StringBuffer` with `StringBuilder` in the methods of `com.sun.jndi.dns.ResourceRecord`? This addresses https://bugs.openjdk.org/browse/JDK-8219203.
> 
> Given the nature of the change, no new tests have been introduced.

Looks safe.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29652#pullrequestreview-3779095259

From rgiulietti at openjdk.org  Tue Feb 10 13:57:51 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 10 Feb 2026 13:57:51 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v10]
In-Reply-To: <HxqaYXjh3-BJhluIVcNN6pZrIKE826oIVuFPguO4H7Y=.f7a696d9-6753-48ca-9c70-bea1b0972bd6@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <HxqaYXjh3-BJhluIVcNN6pZrIKE826oIVuFPguO4H7Y=.f7a696d9-6753-48ca-9c70-bea1b0972bd6@github.com>
Message-ID: <JGV25vIo70QgbOzU9kj2lzxY-ryFKjcUTm2i5NUd6BQ=.7c61eec8-c36a-4dc4-822c-23842c0f723b@github.com>

On Tue, 10 Feb 2026 09:14:39 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM asinh method.
>> 
>> Original C vs transliteration port:
>> 
>> 
>> $ diff -w fdlib_asinh.c Asinh.translit.java
>> 1c1,3
>> < /* asinh(x)
>> ---
>>> /**
>>> * Return the Inverse Hyperbolic Sine of x
>>> *
>> 2a5
>>> *
>> 10a14,17
>>> private static final class Asinh {
>>>       private static final double one = 1.0;
>>>       private static final double ln2 = 6.93147180559945286227e-01;
>>>       private static final double huge = 1.0e300;
>> 12,29c19
>> < #include "fdlibm.h"
>> <
>> < #ifdef __STDC__
>> < static const double
>> < #else
>> < static double
>> < #endif
>> < one =  1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */
>> < ln2 =  6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */
>> < huge=  1.00000000000000000000e+300;
>> <
>> < #ifdef __STDC__
>> <       double asinh(double x)
>> < #else
>> <       double asinh(x)
>> <       double x;
>> < #endif
>> < {
>> ---
>>>       static double compute(double x) {
>> 39c29
>> <           w = __ieee754_log(fabs(x))+ln2;
>> ---
>>>                       w = log(Math.abs(x))+ln2;
>> 41,42c31,32
>> <           t = fabs(x);
>> <           w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t));
>> ---
>>>                       t = Math.abs(x);
>>>                       w = log(2.0*t+one/(sqrt(x*x+one)+t));
>> 45c35
>> <           w =log1p(fabs(x)+t/(one+sqrt(one+t)));
>> ---
>>>                       w =log1p(Math.abs(x)+t/(one+sqrt(one+t)));
>> 47a38
>>>       }
>> 
>> Transliteration port vs more idiomatic port:
>> 
>> 
>> $ diff -w Asinh.translit.java Asinh.fdlibm.java
>> 6,9c6,12
>> < *  Based on
>> < *    asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ]
>> < *   we have
>> < *   asinh(x) := x  if  1+x*x=1,
>> ---
>>>  *
>>>  *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF
>>>  *      and sinh(asinh(x)) = x, -INF < x  < INF.
>>>  *      It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x  < INF.
>>>  *      1. Replace x by |x| as the function is odd.
>>>  *      2.
>>>  *          asinh(x) := x, if 1+x^2 = 1,
>> 12a16,22
>>>  *
>>>  *
>>>  *
>>>  * Special cases:
>>>  *      only asinh(0)=0 is exact for finite x.
>>>  *      asinh(NaN) is NaN
>>>  *      asinh(INF) is INF
>> 14,15c24
>> < private static final class Asinh {
>> <       private static final double one = 1.0;
>> ---
>>> static final class Asinh {
>> 24c33,35
>> <               if(ix>=0x7ff00000) return x+x;  /* x is inf or NaN */
>> ---
>>>               if(ix >= 0x7ff00000) {
>>>                       return x...
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8375285: Addressed reviewer's comments.

Look good

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

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29273#pullrequestreview-3779116499

From alanb at openjdk.org  Tue Feb 10 13:59:14 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Feb 2026 13:59:14 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <A2xDvWF2qEEuWMg1SzSyEWxkr4YgNAott_4A4IwLt_g=.93ab86c5-c061-4bee-a39d-775eeeccb0cd@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
 <A2xDvWF2qEEuWMg1SzSyEWxkr4YgNAott_4A4IwLt_g=.93ab86c5-c061-4bee-a39d-775eeeccb0cd@github.com>
Message-ID: <aq9YGcwLT5wyByncd0kaeXSiby1fQUU_hASe8XGzcXw=.e556a250-af09-45f1-88f4-e0dc7ecdbd0a@github.com>

On Tue, 10 Feb 2026 12:20:36 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Your demo seems to optimize only for `CodingErrorAction.REPLACE`, but that's probably more of an implementation detail than a limiting factor of API design, right?

String.getBytes(Charset) uses REPLACE action, it doesn't ignore (which would change the length) or throw.

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

PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3877788819

From aartemov at openjdk.org  Tue Feb 10 14:08:08 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 10 Feb 2026 14:08:08 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v10]
In-Reply-To: <HxqaYXjh3-BJhluIVcNN6pZrIKE826oIVuFPguO4H7Y=.f7a696d9-6753-48ca-9c70-bea1b0972bd6@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <HxqaYXjh3-BJhluIVcNN6pZrIKE826oIVuFPguO4H7Y=.f7a696d9-6753-48ca-9c70-bea1b0972bd6@github.com>
Message-ID: <zLteeGppI7k_Zyf9tCt2KlOuGhsfvNj9q9id4J46uvQ=.cf045ff6-cddf-46f1-b3f5-c836faed81b6@github.com>

On Tue, 10 Feb 2026 09:14:39 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM asinh method.
>> 
>> Original C vs transliteration port:
>> 
>> 
>> $ diff -w fdlib_asinh.c Asinh.translit.java
>> 1c1,3
>> < /* asinh(x)
>> ---
>>> /**
>>> * Return the Inverse Hyperbolic Sine of x
>>> *
>> 2a5
>>> *
>> 10a14,17
>>> private static final class Asinh {
>>>       private static final double one = 1.0;
>>>       private static final double ln2 = 6.93147180559945286227e-01;
>>>       private static final double huge = 1.0e300;
>> 12,29c19
>> < #include "fdlibm.h"
>> <
>> < #ifdef __STDC__
>> < static const double
>> < #else
>> < static double
>> < #endif
>> < one =  1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */
>> < ln2 =  6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */
>> < huge=  1.00000000000000000000e+300;
>> <
>> < #ifdef __STDC__
>> <       double asinh(double x)
>> < #else
>> <       double asinh(x)
>> <       double x;
>> < #endif
>> < {
>> ---
>>>       static double compute(double x) {
>> 39c29
>> <           w = __ieee754_log(fabs(x))+ln2;
>> ---
>>>                       w = log(Math.abs(x))+ln2;
>> 41,42c31,32
>> <           t = fabs(x);
>> <           w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t));
>> ---
>>>                       t = Math.abs(x);
>>>                       w = log(2.0*t+one/(sqrt(x*x+one)+t));
>> 45c35
>> <           w =log1p(fabs(x)+t/(one+sqrt(one+t)));
>> ---
>>>                       w =log1p(Math.abs(x)+t/(one+sqrt(one+t)));
>> 47a38
>>>       }
>> 
>> Transliteration port vs more idiomatic port:
>> 
>> 
>> $ diff -w Asinh.translit.java Asinh.fdlibm.java
>> 6,9c6,12
>> < *  Based on
>> < *    asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ]
>> < *   we have
>> < *   asinh(x) := x  if  1+x*x=1,
>> ---
>>>  *
>>>  *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF
>>>  *      and sinh(asinh(x)) = x, -INF < x  < INF.
>>>  *      It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x  < INF.
>>>  *      1. Replace x by |x| as the function is odd.
>>>  *      2.
>>>  *          asinh(x) := x, if 1+x^2 = 1,
>> 12a16,22
>>>  *
>>>  *
>>>  *
>>>  * Special cases:
>>>  *      only asinh(0)=0 is exact for finite x.
>>>  *      asinh(NaN) is NaN
>>>  *      asinh(INF) is INF
>> 14,15c24
>> < private static final class Asinh {
>> <       private static final double one = 1.0;
>> ---
>>> static final class Asinh {
>> 24c33,35
>> <               if(ix>=0x7ff00000) return x+x;  /* x is inf or NaN */
>> ---
>>>               if(ix >= 0x7ff00000) {
>>>                       return x...
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8375285: Addressed reviewer's comments.

Thanks for reviews,

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

PR Comment: https://git.openjdk.org/jdk/pull/29273#issuecomment-3877849468

From aefimov at openjdk.org  Tue Feb 10 14:15:40 2026
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 10 Feb 2026 14:15:40 GMT
Subject: RFR: 8219203: Use StringBuilder instead of StringBuffer in
 com.sun.jndi.dns.ResourceRecord
In-Reply-To: <c4mWSSOXzKmr0F94rqJ3I66rGNIE973qpOjOCoNFxoM=.fac4bf4e-4926-46b1-94c3-7fd2d4918079@github.com>
References: <c4mWSSOXzKmr0F94rqJ3I66rGNIE973qpOjOCoNFxoM=.fac4bf4e-4926-46b1-94c3-7fd2d4918079@github.com>
Message-ID: <t-gv89tfjgpvDL6afIyR2-iBEtiYeQ3FVNtJxdIMyyo=.176fbd9d-ced9-4a52-95e4-d82e62c3a5c4@github.com>

On Tue, 10 Feb 2026 11:39:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which replaces the usage of `StringBuffer` with `StringBuilder` in the methods of `com.sun.jndi.dns.ResourceRecord`? This addresses https://bugs.openjdk.org/browse/JDK-8219203.
> 
> Given the nature of the change, no new tests have been introduced.

Looks good

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

Marked as reviewed by aefimov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29652#pullrequestreview-3779226189

From rriggs at openjdk.org  Tue Feb 10 14:24:52 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 10 Feb 2026 14:24:52 GMT
Subject: RFR: 8219203: Use StringBuilder instead of StringBuffer in
 com.sun.jndi.dns.ResourceRecord
In-Reply-To: <c4mWSSOXzKmr0F94rqJ3I66rGNIE973qpOjOCoNFxoM=.fac4bf4e-4926-46b1-94c3-7fd2d4918079@github.com>
References: <c4mWSSOXzKmr0F94rqJ3I66rGNIE973qpOjOCoNFxoM=.fac4bf4e-4926-46b1-94c3-7fd2d4918079@github.com>
Message-ID: <FO7YShIApEGUtowD1izv-u-dAer6GWEtzDeLzD4nMRU=.503e92c8-51ec-492e-b649-a60d51b423ac@github.com>

On Tue, 10 Feb 2026 11:39:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which replaces the usage of `StringBuffer` with `StringBuilder` in the methods of `com.sun.jndi.dns.ResourceRecord`? This addresses https://bugs.openjdk.org/browse/JDK-8219203.
> 
> Given the nature of the change, no new tests have been introduced.

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29652#pullrequestreview-3779285822

From dfuchs at openjdk.org  Tue Feb 10 14:26:54 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 10 Feb 2026 14:26:54 GMT
Subject: RFR: 8377457: java/util/logging/ParentLoggersTest.java failed
 intermittently
In-Reply-To: <wjkMdKf8HhSoOdBnjgIqu07j9nT-W-JlWcpdp0pYQWw=.fa75641c-faf4-49c8-b3e1-2034640cad83@github.com>
References: <svnEUsJ4X3Jx0e9XbXVSvYZa4sIGS2z6CgDLLEj1uP0=.f34489e6-9b0c-4b53-a79a-e896a8c0062d@github.com>
 <wjkMdKf8HhSoOdBnjgIqu07j9nT-W-JlWcpdp0pYQWw=.fa75641c-faf4-49c8-b3e1-2034640cad83@github.com>
Message-ID: <drGSDBXLxi33CyAb96WWFMPoSGp4UXv-JPBzVkjOVKc=.6fe86a94-05ae-4a64-97b6-3366278598b7@github.com>

On Tue, 10 Feb 2026 11:06:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> `java/util/logging/ParentLoggersTest.java` has been observed failing intermittently - nut rarely - in the loom repo.
>> After inspection of the code Logger::doSetParent was found to do multiple read of the volatile `parent` field. After changing the method to do a single read the test has no longer been observed failing.
>
> The intermittent failures were with JTREG_TEST_THREAD_FACTORY=Virtual runs and it was indeed that the returned list of loggers didn't match. It was changed to read the parent field once in the loom repo and the test no longer fails.

Thanks @AlanBateman and @jaikiran for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/29634#issuecomment-3877941367

From dfuchs at openjdk.org  Tue Feb 10 14:26:57 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 10 Feb 2026 14:26:57 GMT
Subject: Integrated: 8377457: java/util/logging/ParentLoggersTest.java failed
 intermittently
In-Reply-To: <svnEUsJ4X3Jx0e9XbXVSvYZa4sIGS2z6CgDLLEj1uP0=.f34489e6-9b0c-4b53-a79a-e896a8c0062d@github.com>
References: <svnEUsJ4X3Jx0e9XbXVSvYZa4sIGS2z6CgDLLEj1uP0=.f34489e6-9b0c-4b53-a79a-e896a8c0062d@github.com>
Message-ID: <MU25F6UYnv1IFtFh4TCerYudILojFGcb_Kr8FgrhUxo=.0a2a9ff7-759d-4785-8903-39eff3eb7491@github.com>

On Mon, 9 Feb 2026 10:35:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> `java/util/logging/ParentLoggersTest.java` has been observed failing intermittently - nut rarely - in the loom repo.
> After inspection of the code Logger::doSetParent was found to do multiple read of the volatile `parent` field. After changing the method to do a single read the test has no longer been observed failing.

This pull request has now been integrated.

Changeset: ef345e78
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef345e78797026b946aa5d91d5f6101ef3ad30bf
Stats:     13 lines in 2 files changed: 6 ins; 0 del; 7 mod

8377457: java/util/logging/ParentLoggersTest.java failed intermittently

Reviewed-by: alanb, jpai

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

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

From eirbjo at openjdk.org  Tue Feb 10 15:28:57 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 10 Feb 2026 15:28:57 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <zn6gQYQ3oJwF96UJFBk6GCUsanFzJQlfYhXBXb0Z_Y4=.7b1a040a-a52a-4186-a696-282d9e43cdfa@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
 <zn6gQYQ3oJwF96UJFBk6GCUsanFzJQlfYhXBXb0Z_Y4=.7b1a040a-a52a-4186-a696-282d9e43cdfa@github.com>
Message-ID: <IjpM_zKysafiFhYcuoVOLZdz7vHA19X1h4Tey69xqow=.39ad3c80-3156-4429-8bdb-f097f964edb3@github.com>

On Tue, 10 Feb 2026 13:17:40 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> I've updated the CSR to incorporate some of the additional alternatives that were raised.

Thanks Liam for taking time to review my comments, exploring options in the demo and documenting alternatives in the CSR.

My opinions here are loosely held and to a large degree formed from the perspective of an armchair. I'm happy that alternatives have been raised and will take a step back now to let the PR proceed with input from experts with bigger shoes than me :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3878510280

From lance.andersen at oracle.com  Tue Feb 10 18:24:11 2026
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 10 Feb 2026 18:24:11 +0000
Subject: RFD: A plan to untangle ZipFile.Source.initCEN
In-Reply-To: <CA+pBWhsOxYX7+efPQVMk8c_XWBf5sG0oDrVURq1kM5xAocKiGA@mail.gmail.com>
References: <CA+pBWhsOxYX7+efPQVMk8c_XWBf5sG0oDrVURq1kM5xAocKiGA@mail.gmail.com>
Message-ID: <A29CA46B-32BB-41D0-8B09-871296A8E2E7@oracle.com>

Hi Eirik,

While I think there may be some merit/benefit to what your suggesting, I think we should take a step back and also look at ZipFS to see what we might be able to share as part of a refactoring as there is a somewhat similar flow to ZipFS initCEN

The benefit would be reducing the need to have to maintain somewhat duplicate code across both APIs.

Best,
Lance

On Feb 10, 2026, at 6:38?AM, Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:

Hi,

Summary

Relieve ZipFile.Source.initCEN from non-parsing related responsibilities, such that it can become a pure function for parsing and validating CEN directories. Make it return Source, such that instance fields of this class may become final, immutable and accessible without synchronization.

Motivation

The method ZipFile.Source.initCEN has been the cause of a good amount of head-scratching over the years. It was brought over from the native implementation when this was transitioned to Java in Java 9.

Risk assessments at that time probably constrained the code to closely align with the native code, which together with interpreter-friendliness in early startup have affected the current shape of this code.

It is hard to summarize the responsibilities of this method, but I'll try:

o Call findEND() to read metadata from the (Zip64) END headers in the ZIP file, validate fields and reject invalid values
o Determine the position of the first LOC header
o Read the CEN byte array from the ZIP file
o Construct hash table data structures
o Assign these to instance fields in Source
o Parse and validate the CEN structure and populate hash table structures
o Detect manifest file(s), signature related files and multi-release JAR versions
o Detect when a ZIP has more CEN entries than declared by the END header and restart parsing by invoking itself recursively after counting the actual number of CEN entries
o Detect when it is being invoked recursively to avoid reading the END and CEN headers twice

It's been obvious for a while that this method performs an excessive number of unrelated tasks, knows too much about the state of the object being constructed and handles a disproportionate amount of funky control flow. It calls out to a number of helper methods to perform parsing and validation, some of them static, some relying on instance state.

The amount of synchronization in ZipFile today is probably excessive for the current implementation. It made more sense back when ZipFile was backed by native code and resources. In particular, lookup misses pay a high relative cost to synchronization which is probably not needed.

Making Source fields final moves us in a direction which may allow us to eventually remove synchronization for operations that only touch a parsed, immutable CEN.

Ideas and plan for improvements

I think we can improve the current situation by:

o Moving END header parsing and validation out of initCEN
o Moving CEN byte array reading out of initCEN
o Making all helper methods static (it's a mix today)

At this point, initCEN will almost, but not quite be a pure function for parsing the CEN byte array. So the next natural step is to actually make it a pure function by:

o Making it static
o Having it return a Source instance instead of assigning to the instance being constructed
o Making Source (mostly) immutable by marking parsed instance fields as 'final'

Rather than a big bang change, I see this effort as a step-by-step refactoring, probably over several PRs, each focusing on a smaller aspect of refactoring, hopefully making them easier to review. This is not an all-or-nothing effort, most of these changes will be incremental improvements on their own merit. If we don't get all the way, that's also okay.

Feedback?

Input to this idea/plan is welcome. If someone sees reasons this may not be a good idea, it's better to raise such concern here and now.

Eirik.



[oracle_sig_logo.gif]

Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260210/78aff6b8/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260210/78aff6b8/oracle_sig_logo-0001.gif>

From eirbjo at gmail.com  Tue Feb 10 19:08:55 2026
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 10 Feb 2026 20:08:55 +0100
Subject: RFD: A plan to untangle ZipFile.Source.initCEN
In-Reply-To: <A29CA46B-32BB-41D0-8B09-871296A8E2E7@oracle.com>
References: <CA+pBWhsOxYX7+efPQVMk8c_XWBf5sG0oDrVURq1kM5xAocKiGA@mail.gmail.com>
 <A29CA46B-32BB-41D0-8B09-871296A8E2E7@oracle.com>
Message-ID: <CA+pBWhsidXG_fHeCWNeQ373NjbZgQSRsQkBWKRg9XgeEqjnyhA@mail.gmail.com>

On Tue, Feb 10, 2026 at 7:24?PM Lance Andersen <lance.andersen at oracle.com>
wrote:


> While I think there may be some merit/benefit to what your suggesting, I
> think we should take a step back and also look at ZipFS to see what we
> might be able to share as part of a refactoring as there is a somewhat
> similar flow to ZipFS initCEN
>
> The benefit would be reducing the need to have to maintain somewhat
> duplicate code across both APIs.
>

I have less intimate experience with the ZipFS implementation. But
ZipFile's initCEN is so convoluted with various responsibilities, state
management and control flow that every time I take a step back from it I
immediately lose track of whatever understanding I just had about how this
method actually works :)

If anything, peeling apart the various layers of this very big onion should
make it easier to see which parts are reusable, and which parts are better
maintained in each implementation. Perhaps we could eventually extract the
CEN parsing and validation into a little utility library, reusable from
ZipFS?

ZipFs includes write support, needs to fit within the FileSystem API,
supports Posix attributes etc. But sure, there may be some synergies.

I don't see how the refactorings and enhancements in code organization
proposed here would make such synergies less achievable. On the contrary, I
think peeling the onion may be a necessary precondition.

Or did you have more specific ideas in mind when suggesting we "take a step
back"?

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260210/97cf5ffd/attachment.htm>

From lancea at openjdk.org  Wed Feb 11 09:28:47 2026
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 11 Feb 2026 09:28:47 GMT
Subject: RFR: 8377461: Add ZipFile test for incorrect number of entries
 reported in ENDTOT [v2]
In-Reply-To: <RqlFKeEz2JQJ78l19QbBposccrVjxN1dZ4Dzcneiorc=.a1baf880-345e-483c-97ca-7a45b5da4938@github.com>
References: <HNKqPs_z16aAUi5uScwFT9ICjbLZDGZEJOSF-kuHdNo=.249a67d7-a6c1-4991-9777-f2e8f1d85c72@github.com>
 <RqlFKeEz2JQJ78l19QbBposccrVjxN1dZ4Dzcneiorc=.a1baf880-345e-483c-97ca-7a45b5da4938@github.com>
Message-ID: <ACaWUiL67uHLBNRry9IraNYTdaXAWXeaAvJdshWfV0U=.b707af29-db56-41ba-a845-ff3df9ad1bd9@github.com>

On Tue, 10 Feb 2026 06:05:15 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR introducing a test to verify that `ZipFile::size` reports the actual number of CEN entries in a ZIP file, despite an incorrect number being reported in the END header.
>> 
>> Background:
>> 
>> The `ZipFile` implementation treats `ENDTOT` as an indication, but falls back to counting CEN entries if this number is too low. After parsing the CEN, there is also code to adjust the total down to the actual count of CEN entries.
>> 
>> The behavior of always reporting the actual number of CEN entries has no current test coverage in the JDK. It seems good to have tests excercising these code paths and protecting against regressions in this area.
>> 
>> Verification:
>> 
>> Verified that the new test catches introduced regressions in handling over- and underreported numbers in ENDTOT and that no existing test catches such regressions.
>> 
>> Test-only change, `noreg-self`.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add case: Empty ZIP, correct ENDTOT
>  - Copyright 2026 for new test

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29635#pullrequestreview-3780655590

From psandoz at openjdk.org  Wed Feb 11 09:29:16 2026
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 11 Feb 2026 09:29:16 GMT
Subject: RFR: 8376186: [VectorAPI] Nomenclature change for concrete vector
 classes
In-Reply-To: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
References: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
Message-ID: <pZ_uBB3lTA1-0rXSDLbQqiA1iGOI86qudnUTzJDHTx8=.ea2c285b-a6cb-492d-a2ea-dcb5e0999837@github.com>

On Fri, 6 Feb 2026 18:33:17 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
> 
> In preparation of Float16 vector API support, changes to nomenclature of concrete vector class by suffixing the vector type with vector bit sizes e.g. FloatVector256 so that we don't end up generating names like Float16256Vector.
> 
> All existing Vector API jtreg test are passing with the patch.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

test/jdk/jdk/incubator/vector/gen-tests.sh line 61:

> 59:   args="-K$type -Dtype=$type -DType=$Type -DTYPE=$TYPE"
> 60: 
> 61:   VectorPrefix=$Type

This seems unnecessary - why do we need it?

test/jdk/jdk/incubator/vector/gen-tests.sh line 127:

> 125:   abstractvectortype=${typeprefix}${VectorPrefix}Vector
> 126:   abstractvectorteststype=${typeprefix}${VectorPrefix}VectorTests
> 127:   abstractbitsvectortype=${typeprefix}${VectorPrefixe}Vector

Suggestion:

  abstractbitsvectortype=${typeprefix}${VectorPrefix}Vector

But, why is it changed from ${Bitstype}?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29614#discussion_r2789562537
PR Review Comment: https://git.openjdk.org/jdk/pull/29614#discussion_r2789551075

From jpai at openjdk.org  Wed Feb 11 09:29:53 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Feb 2026 09:29:53 GMT
Subject: RFR: 8377035: [s390x] Disable JSR166 test cases which uses virtual
 threads [v2]
In-Reply-To: <UiSM3r5RcrgWM8pOA7yDk7BU6yCxi5N48vBqKVBE0oc=.beb187c2-f639-44d1-94bc-50f8589389d1@github.com>
References: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
 <UiSM3r5RcrgWM8pOA7yDk7BU6yCxi5N48vBqKVBE0oc=.beb187c2-f639-44d1-94bc-50f8589389d1@github.com>
Message-ID: <Sm-fJUfcMCAGObCZ_YLzNbZsKc-PYSBsoV-_OPC2Cgk=.2f002deb-6ad0-487f-8cac-5cc3b4bb95ce@github.com>

On Fri, 6 Feb 2026 05:45:09 GMT, Harshit470250 <duke at openjdk.org> wrote:

>> ReentrantReadWriteLock20Test.java is failing on s390 due to virtual threads which are not yet implemented on s390. 
>> SynchronousQueue20Test.java also uses virtual thread so I am also disabling it.
>
> Harshit470250 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change to use Platform.isS390

This looks OK to me. For each of the `@test` definitions in this file, please also add a `@build jdk.test.lib.Platform` for this change.

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

PR Review: https://git.openjdk.org/jdk/pull/29555#pullrequestreview-3782961903

From asemenyuk at openjdk.org  Wed Feb 11 09:34:01 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 11 Feb 2026 09:34:01 GMT
Subject: RFR: 8377629: jpackage: Tighten up output validation in tests
Message-ID: <YC1d5DOWUhhgexyqfObG14ud4LeOdD6oDKwlAgKZWyI=.49769a63-3d02-47bc-92fa-27295c3e95e9@github.com>

Tighten up jpackage's output validation.

 - Support separate validation of jpackage's stdout and stderr. Previously, validation was applied to the merged stdout and stderr output, so errors were not detected when jpackage expected to write to stdout but wrote to stderr instead
- 99% of test cases in ErrorTest will check that jpackage's stderr contains exact expected error messages and doesn't contain additional text lines
- Use `String.equals()` instead of `String.contains()` when validating strings from jpackage string bundles in jpackage output

Replace TKit.TextStreamVerifier.Group class with a more capable JPackageOutputValidator.

Fix revealed issues:
 - jdk.jpackage.internal.AppImageSigner: use `Log.fatalError()` to report a fatal signing error instead of `Log.info()`. This change directs signing error messages to stderr, where all warnings and errors belong, rather than stdout.
 - On macOS, when the value of the "--app-image" option is not a directory, jpackage used to report two errors: that the value is not a directory and that it is not a macOS bundle. This behavior has changed: jpackage will report only the first error. If the value of the "--app-image" option is a directory that is not a valid macOS bundle, jpackage will fail with the corresponding error.

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

Commit messages:
 - JPackageCommand: split validateOutput() in validateOut() and validateErr(); add convenience makeError() and makeAdvice() methods; fix cannedArgument() signature; Add JPackageOutputValidator for finer control of jpackage output validation; Use String#equals() instead of String#contains() predicate when validating canned formatted strings in jpackage output; TKit.TextStreamVerifier: remove Group class. It duplicates JPackageOutputValidator functionality and can be replaced with Stream.reduce() where JPackageOutputValidator is not applicable.
 - Validator: Split and() into andGreedy() and andLazy(); On macOS, when the value of the "--app-image" option is not a directory, don't report two errors that it is not a directory and not a valid macOS bundle, report on;y the first error.
 - JPackageCommand: fix ReadOnlyPathAssert.Builder.create(): it should check that jpackage command line contains configured option before running the enabling predicate.
 - MacSign: fix a typo: CODE_SIGND -> CODE_SIGN
 - AppImageSigner: report signing error into stderr instead of stdout

Changes: https://git.openjdk.org/jdk/pull/29644/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29644&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377629
  Stats: 965 lines in 27 files changed: 635 ins; 118 del; 212 mod
  Patch: https://git.openjdk.org/jdk/pull/29644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29644/head:pull/29644

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

From asemenyuk at openjdk.org  Wed Feb 11 09:34:05 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 11 Feb 2026 09:34:05 GMT
Subject: RFR: 8377629: jpackage: Tighten up output validation in tests
In-Reply-To: <YC1d5DOWUhhgexyqfObG14ud4LeOdD6oDKwlAgKZWyI=.49769a63-3d02-47bc-92fa-27295c3e95e9@github.com>
References: <YC1d5DOWUhhgexyqfObG14ud4LeOdD6oDKwlAgKZWyI=.49769a63-3d02-47bc-92fa-27295c3e95e9@github.com>
Message-ID: <EYyEXALoIvLY077pIjigvWfEt4gHjDktK304gE9Be3w=.fcb71cc8-dfee-4a98-bebe-a1415e2f3e7c@github.com>

On Tue, 10 Feb 2026 03:04:18 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Tighten up jpackage's output validation.
> 
>  - Support separate validation of jpackage's stdout and stderr. Previously, validation was applied to the merged stdout and stderr output, so errors were not detected when jpackage expected to write to stdout but wrote to stderr instead
> - 99% of test cases in ErrorTest will check that jpackage's stderr contains exact expected error messages and doesn't contain additional text lines
> - Use `String.equals()` instead of `String.contains()` when validating strings from jpackage string bundles in jpackage output
> 
> Replace TKit.TextStreamVerifier.Group class with a more capable JPackageOutputValidator.
> 
> Fix revealed issues:
>  - jdk.jpackage.internal.AppImageSigner: use `Log.fatalError()` to report a fatal signing error instead of `Log.info()`. This change directs signing error messages to stderr, where all warnings and errors belong, rather than stdout.
>  - On macOS, when the value of the "--app-image" option is not a directory, jpackage used to report two errors: that the value is not a directory and that it is not a macOS bundle. This behavior has changed: jpackage will report only the first error. If the value of the "--app-image" option is a directory that is not a valid macOS bundle, jpackage will fail with the corresponding error.

@sashamatveev PTAL

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

PR Comment: https://git.openjdk.org/jdk/pull/29644#issuecomment-3882081288

From aartemov at openjdk.org  Wed Feb 11 09:35:44 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 11 Feb 2026 09:35:44 GMT
Subject: RFR: 8376665: Port fdlibm acosh to Java [v4]
In-Reply-To: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
References: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
Message-ID: <Q3XsqAjjS1gUFCprX52bO5d42y6gzXKBvYEdRPC0Wjg=.4e9fb8f5-88ed-4698-8f0e-b7d6e536ccca@github.com>

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM acosh method.
> 
> Original C vs transliteration port:
> 
> 
> $ diff -w fdlib_acosh.c.txt Acosh.translit.java
> 1c1,3
> < /* __ieee754_acosh(x)
> ---
>> /**
>>  * Return the Inverse Hyperbolic Cosine of x
>>  *
> 7,8c9,10
> <  *            acosh(x) := log(2x-1/(sqrt(x*x-1)+x)) if x>2; else
> <  *            acosh(x) := log1p(t+sqrt(2.0*t+t*t)); where t=x-1.
> ---
>>  *            := log(2x-1/(sqrt(x*x-1)+x)) if x>2; else
>>  *            := log1p(t+sqrt(2.0*t+t*t)); where t=x-1.
> 14,31c16,19
> <
> < #include "fdlibm.h"
> <
> < #ifdef __STDC__
> < static const double
> < #else
> < static double
> < #endif
> < one   = 1.0,
> < ln2   = 6.93147180559945286227e-01;  /* 0x3FE62E42, 0xFEFA39EF */
> <
> < #ifdef __STDC__
> <       double __ieee754_acosh(double x)
> < #else
> <       double __ieee754_acosh(x)
> <       double x;
> < #endif
> < {
> ---
>> private static final class Acosh {
>>       private static final double one = 1.0;
>>       private static final double ln2 = 6.93147180559945286227e-01;
>>       static double compute(double x) {
> 41c29
> <               return __ieee754_log(x)+ln2;    /* acosh(huge)=log(2x) */
> ---
>>                               return log(x)+ln2;   /* acosh(huge)=log(2x) */
> 46c34
> <           return __ieee754_log(2.0*x-one/(x+sqrt(t-one)));
> ---
>>                       return log(2.0*x-one/(x+sqrt(t-one)));
> 49a38
>>               }
> 
> 
> 
> Transliteration vs more idiomatic port:
> 
> $ diff -w Acosh.translit.java Acosh.fdlibm.java
> 5,7c5,9
> <  * Based on
> <  *  acosh(x) = log [ x + sqrt(x*x-1) ]
> <  *  we have
> ---
>>  *
>>  *
>>  *      acosh(x) is defined so that acosh(cosh(alpha)) = alpha, -INF < alpha < < INF
>>  *      and cosh(acosh(x)) = x, 1 <= x  < INF.
>>  *      It can be written as acosh(x) = ln(x + sqrt(x^2 - 1)), 1 <= x  < INF.
> 11a14,15
>>  *
>>  *
> 16,17c20
> < private static final class Acosh {
> <       private static final double one = 1.0;
> ---
>> static final class Acosh {
> 18a22
>>
> 23c27
> <               if(hx<0x3ff00000) {      /* x < 1 */
> ---
>>               if(hx < 0x3ff00000) {                           // x < 1 */
> 25,26c29,30
> <               } else if(hx >=0x41b00000) {    /* x > 2**28 */
> <                       if(hx >=0x7ff00000) {    /* x is inf of NaN */
> ---
>>               } else if (hx >= 0x41b00000) {                  // x > 2**28
>>                       if(hx >= 0x7ff00000) {                      // x is inf of NaN
> 28,29c32,34
> <                       } else
> <                               return log(x)+ln2;   /* acosh(huge)=log(2x) *...

Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - 8376665: Resolved merge conflicts.
 - 8376665: Fixed definition of inverse cosh.
 - 8376665: Fixed range, added special test case.
 - 8376665: Fixed whitespaces.
 - 8376665: Fixed whitespaces.
 - 8376665: Ported fdlibm acosh function. Added tests.
 - Merge remote-tracking branch 'origin/master' into JDK-8375285-port-fdlibm-asinh-to-java
 - 8375285: Added versions.
 - 8375285: Addressed the reviewer's comments, fixed year in the copyright notice.
 - 8375285: Addressed the reviewer's comments.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/56afb460...32e51c37

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

Changes: https://git.openjdk.org/jdk/pull/29488/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29488&range=03
  Stats: 582 lines in 7 files changed: 573 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/29488.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29488/head:pull/29488

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

From aartemov at openjdk.org  Wed Feb 11 09:35:54 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 11 Feb 2026 09:35:54 GMT
Subject: RFR: 8376665: Port fdlibm acosh to Java [v4]
In-Reply-To: <Q3XsqAjjS1gUFCprX52bO5d42y6gzXKBvYEdRPC0Wjg=.4e9fb8f5-88ed-4698-8f0e-b7d6e536ccca@github.com>
References: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
 <Q3XsqAjjS1gUFCprX52bO5d42y6gzXKBvYEdRPC0Wjg=.4e9fb8f5-88ed-4698-8f0e-b7d6e536ccca@github.com>
Message-ID: <HPjYOh_nRuV8Qfp0swDD_ma4_5AFewq8tpYO3RixvRc=.019ae8da-4481-4dcf-9273-71392110bb19@github.com>

On Wed, 11 Feb 2026 09:26:25 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM acosh method.
>> 
>> Original C vs transliteration port:
>> 
>> 
>> $ diff -w fdlib_acosh.c.txt Acosh.translit.java
>> 1c1,3
>> < /* __ieee754_acosh(x)
>> ---
>>> /**
>>>  * Return the Inverse Hyperbolic Cosine of x
>>>  *
>> 7,8c9,10
>> <  *            acosh(x) := log(2x-1/(sqrt(x*x-1)+x)) if x>2; else
>> <  *            acosh(x) := log1p(t+sqrt(2.0*t+t*t)); where t=x-1.
>> ---
>>>  *            := log(2x-1/(sqrt(x*x-1)+x)) if x>2; else
>>>  *            := log1p(t+sqrt(2.0*t+t*t)); where t=x-1.
>> 14,31c16,19
>> <
>> < #include "fdlibm.h"
>> <
>> < #ifdef __STDC__
>> < static const double
>> < #else
>> < static double
>> < #endif
>> < one   = 1.0,
>> < ln2   = 6.93147180559945286227e-01;  /* 0x3FE62E42, 0xFEFA39EF */
>> <
>> < #ifdef __STDC__
>> <       double __ieee754_acosh(double x)
>> < #else
>> <       double __ieee754_acosh(x)
>> <       double x;
>> < #endif
>> < {
>> ---
>>> private static final class Acosh {
>>>       private static final double one = 1.0;
>>>       private static final double ln2 = 6.93147180559945286227e-01;
>>>       static double compute(double x) {
>> 41c29
>> <               return __ieee754_log(x)+ln2;    /* acosh(huge)=log(2x) */
>> ---
>>>                               return log(x)+ln2;   /* acosh(huge)=log(2x) */
>> 46c34
>> <           return __ieee754_log(2.0*x-one/(x+sqrt(t-one)));
>> ---
>>>                       return log(2.0*x-one/(x+sqrt(t-one)));
>> 49a38
>>>               }
>> 
>> 
>> 
>> Transliteration vs more idiomatic port:
>> 
>> $ diff -w Acosh.translit.java Acosh.fdlibm.java
>> 5,7c5,9
>> <  * Based on
>> <  *  acosh(x) = log [ x + sqrt(x*x-1) ]
>> <  *  we have
>> ---
>>>  *
>>>  *
>>>  *      acosh(x) is defined so that acosh(cosh(alpha)) = alpha, -INF < alpha < < INF
>>>  *      and cosh(acosh(x)) = x, 1 <= x  < INF.
>>>  *      It can be written as acosh(x) = ln(x + sqrt(x^2 - 1)), 1 <= x  < INF.
>> 11a14,15
>>>  *
>>>  *
>> 16,17c20
>> < private static final class Acosh {
>> <       private static final double one = 1.0;
>> ---
>>> static final class Acosh {
>> 18a22
>>>
>> 23c27
>> <               if(hx<0x3ff00000) {      /* x < 1 */
>> ---
>>>               if(hx < 0x3ff00000) {                           // x < 1 */
>> 25,26c29,30
>> <               } else if(hx >=0x41b00000) {    /* x > 2**28 */
>> <                       if(hx >=0x7ff00000) {    /* x is inf of NaN */
>> ---
>>>               } else if (hx >= 0x41b00000) {                  // x > 2**28
>>>                       if(hx >= 0x7ff00000) {     ...
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - 8376665: Resolved merge conflicts.
>  - 8376665: Fixed definition of inverse cosh.
>  - 8376665: Fixed range, added special test case.
>  - 8376665: Fixed whitespaces.
>  - 8376665: Fixed whitespaces.
>  - 8376665: Ported fdlibm acosh function. Added tests.
>  - Merge remote-tracking branch 'origin/master' into JDK-8375285-port-fdlibm-asinh-to-java
>  - 8375285: Added versions.
>  - 8375285: Addressed the reviewer's comments, fixed year in the copyright notice.
>  - 8375285: Addressed the reviewer's comments.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/56afb460...32e51c37

Original C vs transliteration port:


$ diff -w fdlib_acosh.c.txt Acosh.translit.java
1c1,3
< /* __ieee754_acosh(x)
---
> /**
>  * Return the Inverse Hyperbolic Cosine of x
>  *
7,8c9,10
<  *            acosh(x) := log(2x-1/(sqrt(x*x-1)+x)) if x>2; else
<  *            acosh(x) := log1p(t+sqrt(2.0*t+t*t)); where t=x-1.
---
>  *            := log(2x-1/(sqrt(x*x-1)+x)) if x>2; else
>  *            := log1p(t+sqrt(2.0*t+t*t)); where t=x-1.
14,31c16,19
<
< #include "fdlibm.h"
<
< #ifdef __STDC__
< static const double
< #else
< static double
< #endif
< one   = 1.0,
< ln2   = 6.93147180559945286227e-01;  /* 0x3FE62E42, 0xFEFA39EF */
<
< #ifdef __STDC__
<       double __ieee754_acosh(double x)
< #else
<       double __ieee754_acosh(x)
<       double x;
< #endif
< {
---
> private static final class Acosh {
>       private static final double one = 1.0;
>       private static final double ln2 = 6.93147180559945286227e-01;
>       static double compute(double x) {
41c29
<               return __ieee754_log(x)+ln2;    /* acosh(huge)=log(2x) */
---
>                               return log(x)+ln2;   /* acosh(huge)=log(2x) */
46c34
<           return __ieee754_log(2.0*x-one/(x+sqrt(t-one)));
---
>                       return log(2.0*x-one/(x+sqrt(t-one)));
49a38
>               }



Transliteration vs more idiomatic port:

$ diff -w Acosh.translit.java Acosh.fdlibm.java
5,7c5,9
<  * Based on
<  *  acosh(x) = log [ x + sqrt(x*x-1) ]
<  *  we have
---
>  *
>  *
>  *      acosh(x) is defined so that acosh(cosh(alpha)) = alpha, -INF < alpha < < INF
>  *      and cosh(acosh(x)) = x, 1 <= x  < INF.
>  *      It can be written as acosh(x) = ln(x + sqrt(x^2 - 1)), 1 <= x  < INF.
11a14,15
>  *
>  *
16,17c20
< private static final class Acosh {
<       private static final double one = 1.0;
---
> static final class Acosh {
18a22
>
23c27
<               if(hx<0x3ff00000) {      /* x < 1 */
---
>               if(hx < 0x3ff00000) {                           // x < 1 */
25,26c29,30
<               } else if(hx >=0x41b00000) {    /* x > 2**28 */
<                       if(hx >=0x7ff00000) {    /* x is inf of NaN */
---
>               } else if (hx >= 0x41b00000) {                  // x > 2**28
>                       if(hx >= 0x7ff00000) {                      // x is inf of NaN
28,29c32,34
<                       } else
<                               return log(x)+ln2;   /* acosh(huge)=log(2x) */
---
>                       } else {
>                               return Log.compute(x) + ln2;            // acosh(huge) = log(2x)
>                       }
31,32c36,37
<                       return 0.0;         /* acosh(1) = 0 */
<               } else if (hx > 0x40000000) {   /* 2**28 > x > 2 */
---
>                       return 0.0;                                 // acosh(1) = 0
>               } else if (hx > 0x40000000) {                   // 2**28 > x > 2
34,37c39,42
<                       return log(2.0*x-one/(x+sqrt(t-one)));
<               } else {            /* 1<x<2 */
<                       t = x-one;
<                       return log1p(t+sqrt(2.0*t+t*t));
---
>                       return Log.compute(2.0 * x - 1.0 / (x + Sqrt.compute(t - 1.0)));
>               } else {                                        // 1< x <2
>                       t = x - 1.0;
>                       return Log1p.compute(t + Sqrt.compute(2.0 * t + t * t));

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

PR Comment: https://git.openjdk.org/jdk/pull/29488#issuecomment-3883252611

From dfenacci at openjdk.org  Wed Feb 11 09:35:35 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 11 Feb 2026 09:35:35 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics
In-Reply-To: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
Message-ID: <KeNqd83bGg0oPTyA4m5C8HB_F5q5r4jcY_ac96NNMI4=.74f069e3-4ba1-44b2-b9ac-6d84a745d8cb@github.com>

On Mon, 15 Dec 2025 20:30:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Moves input validation checks to Java for `java.lang.StringLatin1` intrinsics. While doing so, affected `java.lang.StringUTF16` methods needed to be updated due to relaxed checks at intrinsics. The javadocs of the touched methods are extensively overhauled.

Thanks for looking into this @vy! I left a couple of comments/questions (I've mostly checked the intrinsic part).

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

> 400:    do_signature(indexOfChar_signature,                           "([BIII)I")                                            \
> 401:   do_intrinsic(_equalsL,                  java_lang_StringLatin1,equalsS_name, equalsB_signature,                 F_S)  \
> 402:     do_name(    equalsS_name,                                    "equals0")                                             \

Suggestion:

   do_name(    equalsS_name,                                     "equals0")                                             \

src/java.base/share/classes/java/lang/StringLatin1.java line 2:

> 1: /*
> 2:  * Copyright (c) 2015, 2025, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2015, 2026, Oracle and/or its affiliates. All rights reserved.

src/java.base/share/classes/java/lang/StringLatin1.java line 172:

> 170:         Objects.requireNonNull(other);
> 171:         String.checkOffset(len1, length(value));
> 172:         String.checkOffset(len2, length(other));

Are these additional checks? I'm asking because I was expecting them to "replace" intrinsics ones but couldn't find where/how (if so I'm also wondering why they were not there before: did all callers ensure that?).

src/java.base/share/classes/java/lang/StringLatin1.java line 220:

> 218:     static int compareToUTF16(byte[] value, byte[] other, int len1, int len2) {
> 219:         Objects.requireNonNull(value);
> 220:         Objects.requireNonNull(other);

[Similar question](https://github.com/openjdk/jdk/pull/28832/changes#r2788781455)

src/java.base/share/classes/java/lang/StringLatin1.java line 266:

> 264:     static int compareToCI_UTF16(byte[] value, byte[] other) {
> 265:         Objects.requireNonNull(value);
> 266:         Objects.requireNonNull(other);

[Similar question](https://github.com/openjdk/jdk/pull/28832/changes#r2788781455)

src/java.base/share/classes/java/lang/StringUTF16.java line 2:

> 1: /*
> 2:  * Copyright (c) 2015, 2025, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2015, 2026, Oracle and/or its affiliates. All rights reserved.

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

PR Review: https://git.openjdk.org/jdk/pull/28832#pullrequestreview-3777437085
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2786516405
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2786502065
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2788781455
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2788831821
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2788869295
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2786504049

From rriggs at openjdk.org  Wed Feb 11 09:36:40 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 11 Feb 2026 09:36:40 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics
In-Reply-To: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
Message-ID: <3ui4ZV1EWo2YpaqabNnOSHlCWN3QJKVBFbYs4fb8hPE=.b8bdb195-43c5-4900-ad61-09b575f3a212@github.com>

On Mon, 15 Dec 2025 20:30:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Moves input validation checks to Java for `java.lang.StringLatin1` intrinsics. While doing so, affected `java.lang.StringUTF16` methods needed to be updated due to relaxed checks at intrinsics. The javadocs of the touched methods are extensively overhauled.

Mostly comments about new comments.
Also name scoping of VM intrinsic functions.

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

> 361:                                                                                                                         \
> 362:   do_intrinsic(_compressStringC,          java_lang_StringUTF16,  compressS_name, encodeISOArray_signature,      F_S)   \
> 363:    do_name(     compressS_name,                                  "compress0")                                           \

_compressS_name doesn't seem to follow the naming pattern.

src/java.base/share/classes/java/lang/StringLatin1.java line 112:

> 110:     }
> 111: 
> 112:     // inline_string_equals

Is there a HotSpot specific namespace qualifier that can make it easier to cross reference this?
Ditto the other hotspot names below.

src/java.base/share/classes/java/lang/StringLatin1.java line 207:

> 205: 
> 206:     /**
> 207:      * Lexicographically compares a Latin-1 string sub-range to a UTF-16

It would be more specific to say it compares a "prefix" since the start is always 0.

src/java.base/share/classes/java/lang/StringUTF16.java line 398:

> 396: 
> 397:     /**
> 398:      * Exhaustively copies Latin-1 characters from a {@code char} array

The word Exhaustively does not fit here because it stops copying for > 0xff.
Perhaps:   "Copies the prefix of Latin-1 characters".

src/java.base/share/classes/java/lang/StringUTF16.java line 457:

> 455:         Objects.requireNonNull(src);
> 456:         checkBoundsOffCount(srcOff, len, src);
> 457:         String.checkBoundsOffCount(dstOff, len, dst.length);    // Implicit null check on `dst`

This bouncing around between source files for methods of the same name `checkBoundsOffCout` is bound to confuse the reader.
Be consistent, either now or later, use the local one in this file or remove the utility method.

src/java.base/share/classes/java/lang/StringUTF16.java line 603:

> 601: 
> 602:     /**
> 603:      * Lexicographically compares a UTF-16 string sub-range to a Latin-1 one as

It isn't a full sub-range, the start index is 0, use prefix instead.

src/java.base/share/classes/java/lang/StringUTF16.java line 950:

> 948:     }
> 949: 
> 950: 

Extra blank line.

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

PR Review: https://git.openjdk.org/jdk/pull/28832#pullrequestreview-3779872520
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2789222662
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2788770299
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2788844019
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2789099768
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2789136344
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2789162215
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2789185291

From duke at openjdk.org  Wed Feb 11 09:42:45 2026
From: duke at openjdk.org (Benjamin Peterson)
Date: Wed, 11 Feb 2026 09:42:45 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v10]
In-Reply-To: <SotyG_PrqFiheXATqZGApiOXxW5H5pMarR9Nuu1TEmM=.1f1715d8-67b7-4f76-8360-32295e21c488@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <SotyG_PrqFiheXATqZGApiOXxW5H5pMarR9Nuu1TEmM=.1f1715d8-67b7-4f76-8360-32295e21c488@github.com>
Message-ID: <wwoAvG8T39O4pmKnlKoq2nwl9oduDA46DhgeeF3Ey2U=.5908e39a-392d-43ed-8c18-81374bf0bf80@github.com>

On Mon, 15 Dec 2025 17:31:20 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 in Windows' `os::dll_load`. 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 pull request now contains 16 commits:
> 
>  - Merge branch 'master' into nativelibraries-fix
>  - add test showing loading symlinked libraries with various combinations
>  - revert dll_load fix
>  - Merge branch 'master' into nativelibraries-fix
>  - add cast
>  - use os::malloc
>  - Merge branch 'master' into nativelibraries-fix
>  - fix compilation
>  - fix grammar
>  - add dot in os::dll_load rather than NativeLibraries.java
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/ad29642d...d03535ce

Any indications from security?

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

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3882424498

From cstein at openjdk.org  Wed Feb 11 09:45:31 2026
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 11 Feb 2026 09:45:31 GMT
Subject: Integrated: 8376355: Update to use jtreg 8.2.1
In-Reply-To: <dyYpHQfiCIDTwVouMHgEd7tIH2ZODtzHHmbkvi0gNF8=.1471e4d3-d4b0-4117-9257-c929480a59e0@github.com>
References: <dyYpHQfiCIDTwVouMHgEd7tIH2ZODtzHHmbkvi0gNF8=.1471e4d3-d4b0-4117-9257-c929480a59e0@github.com>
Message-ID: <Qc8BiqFzKgGKu3sbcXkQ17iG2yDpFuzxy1F7q6a7bw4=.37fd3647-ed16-41fe-92f7-d44640476f86@github.com>

On Tue, 27 Jan 2026 15:26:20 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.2.1.
> 
> 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 pull request has now been integrated.

Changeset: 1e99cc48
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e99cc4880f695c12705d849d41609f176f897bd
Stats:     17 lines in 9 files changed: 0 ins; 0 del; 17 mod

8376355: Update to use jtreg 8.2.1

Reviewed-by: iris, erikj, shade

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

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

From bpb at openjdk.org  Wed Feb 11 09:45:44 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Feb 2026 09:45:44 GMT
Subject: RFR: 8219203: Use StringBuilder instead of StringBuffer in
 com.sun.jndi.dns.ResourceRecord
In-Reply-To: <c4mWSSOXzKmr0F94rqJ3I66rGNIE973qpOjOCoNFxoM=.fac4bf4e-4926-46b1-94c3-7fd2d4918079@github.com>
References: <c4mWSSOXzKmr0F94rqJ3I66rGNIE973qpOjOCoNFxoM=.fac4bf4e-4926-46b1-94c3-7fd2d4918079@github.com>
Message-ID: <lFSFGOhiiv4VOuusChmc852y4ShErV0h_cUpZRw11yo=.576b08e5-7300-4574-afee-d80185a82350@github.com>

On Tue, 10 Feb 2026 11:39:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which replaces the usage of `StringBuffer` with `StringBuilder` in the methods of `com.sun.jndi.dns.ResourceRecord`? This addresses https://bugs.openjdk.org/browse/JDK-8219203.
> 
> Given the nature of the change, no new tests have been introduced.

Looks fine.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29652#pullrequestreview-3780199138

From darcy at openjdk.org  Wed Feb 11 09:46:15 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 11 Feb 2026 09:46:15 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v10]
In-Reply-To: <HxqaYXjh3-BJhluIVcNN6pZrIKE826oIVuFPguO4H7Y=.f7a696d9-6753-48ca-9c70-bea1b0972bd6@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <HxqaYXjh3-BJhluIVcNN6pZrIKE826oIVuFPguO4H7Y=.f7a696d9-6753-48ca-9c70-bea1b0972bd6@github.com>
Message-ID: <iltpboLwvVfEcQCExw_ybqDLaRw87H93ZnX8NSGNPyE=.55dac267-63bf-4bad-a4da-67b87ad89b44@github.com>

On Tue, 10 Feb 2026 09:14:39 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM asinh method.
>> 
>> Original C vs transliteration port:
>> 
>> 
>> $ diff -w fdlib_asinh.c Asinh.translit.java
>> 1c1,3
>> < /* asinh(x)
>> ---
>>> /**
>>> * Return the Inverse Hyperbolic Sine of x
>>> *
>> 2a5
>>> *
>> 10a14,17
>>> private static final class Asinh {
>>>       private static final double one = 1.0;
>>>       private static final double ln2 = 6.93147180559945286227e-01;
>>>       private static final double huge = 1.0e300;
>> 12,29c19
>> < #include "fdlibm.h"
>> <
>> < #ifdef __STDC__
>> < static const double
>> < #else
>> < static double
>> < #endif
>> < one =  1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */
>> < ln2 =  6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */
>> < huge=  1.00000000000000000000e+300;
>> <
>> < #ifdef __STDC__
>> <       double asinh(double x)
>> < #else
>> <       double asinh(x)
>> <       double x;
>> < #endif
>> < {
>> ---
>>>       static double compute(double x) {
>> 39c29
>> <           w = __ieee754_log(fabs(x))+ln2;
>> ---
>>>                       w = log(Math.abs(x))+ln2;
>> 41,42c31,32
>> <           t = fabs(x);
>> <           w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t));
>> ---
>>>                       t = Math.abs(x);
>>>                       w = log(2.0*t+one/(sqrt(x*x+one)+t));
>> 45c35
>> <           w =log1p(fabs(x)+t/(one+sqrt(one+t)));
>> ---
>>>                       w =log1p(Math.abs(x)+t/(one+sqrt(one+t)));
>> 47a38
>>>       }
>> 
>> Transliteration port vs more idiomatic port:
>> 
>> 
>> $ diff -w Asinh.translit.java Asinh.fdlibm.java
>> 6,9c6,12
>> < *  Based on
>> < *    asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ]
>> < *   we have
>> < *   asinh(x) := x  if  1+x*x=1,
>> ---
>>>  *
>>>  *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF
>>>  *      and sinh(asinh(x)) = x, -INF < x  < INF.
>>>  *      It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x  < INF.
>>>  *      1. Replace x by |x| as the function is odd.
>>>  *      2.
>>>  *          asinh(x) := x, if 1+x^2 = 1,
>> 12a16,22
>>>  *
>>>  *
>>>  *
>>>  * Special cases:
>>>  *      only asinh(0)=0 is exact for finite x.
>>>  *      asinh(NaN) is NaN
>>>  *      asinh(INF) is INF
>> 14,15c24
>> < private static final class Asinh {
>> <       private static final double one = 1.0;
>> ---
>>> static final class Asinh {
>> 24c33,35
>> <               if(ix>=0x7ff00000) return x+x;  /* x is inf or NaN */
>> ---
>>>               if(ix >= 0x7ff00000) {
>>>                       return x...
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8375285: Addressed reviewer's comments.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29273#pullrequestreview-3780179454

From lancea at openjdk.org  Wed Feb 11 09:45:54 2026
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 11 Feb 2026 09:45:54 GMT
Subject: RFR: 8219203: Use StringBuilder instead of StringBuffer in
 com.sun.jndi.dns.ResourceRecord
In-Reply-To: <c4mWSSOXzKmr0F94rqJ3I66rGNIE973qpOjOCoNFxoM=.fac4bf4e-4926-46b1-94c3-7fd2d4918079@github.com>
References: <c4mWSSOXzKmr0F94rqJ3I66rGNIE973qpOjOCoNFxoM=.fac4bf4e-4926-46b1-94c3-7fd2d4918079@github.com>
Message-ID: <qkgvaSFHm91U5Ay1FU0WAuGQDuLT3EACaG4IhbhmhQ4=.18df2b60-ed57-45a7-9efc-46f255b55675@github.com>

On Tue, 10 Feb 2026 11:39:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which replaces the usage of `StringBuffer` with `StringBuilder` in the methods of `com.sun.jndi.dns.ResourceRecord`? This addresses https://bugs.openjdk.org/browse/JDK-8219203.
> 
> Given the nature of the change, no new tests have been introduced.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29652#pullrequestreview-3780445089

From asemenyuk at openjdk.org  Wed Feb 11 09:46:07 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 11 Feb 2026 09:46:07 GMT
Subject: RFR: 8377514: jpackage: support passing multiple exceptions to the
 top-level error handler [v2]
In-Reply-To: <ZbVqysXuPvRn8fIgCtyQHjWylb9Tn8nKP6cY-gz36eY=.f18c0d3f-70c7-4973-b18a-c0f7eaaee52d@github.com>
References: <ZbVqysXuPvRn8fIgCtyQHjWylb9Tn8nKP6cY-gz36eY=.f18c0d3f-70c7-4973-b18a-c0f7eaaee52d@github.com>
Message-ID: <yoLzFMlOl-M_JBvPOBopaomr8D5h_I6MGsac-gSlNSA=.ea72dde1-a98e-49f0-8624-48c968f2c934@github.com>

> Make the top-level error reporter handle suppressed exceptions.
> 
> The bundling code may use the suppressed exceptions mechanism to report multiple error conditions.
> 
> Rework reporting of multiple signing identity errors using the new mechanism, simplified `MacFromOptions.createMacPkgPackage()`.
> 
> Additionally:
>  - Simplified AppImageSigningConfigBuilder and SigningIdentityBuilder

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

  Copyright year update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29643/files
  - new: https://git.openjdk.org/jdk/pull/29643/files/438ba70b..6ab4e521

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

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

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

From naoto at openjdk.org  Wed Feb 11 09:46:08 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Feb 2026 09:46:08 GMT
Subject: RFR: 8377013: TimeZone.getDefault() returns obsolete id on Windows
 (Asia/Calcutta) [v2]
In-Reply-To: <FzZY6RBGXd2YYTBcQR9Idz3WO_aXVor0_auv8zKUgvE=.646923cb-8a2a-4611-b526-9c2b6b351203@github.com>
References: <PMPp8Dq_aPJspR1mTJWBnZOvlsl_aRxf69oYFVSgK1I=.347739c4-b0f9-4d6f-82bc-55d5c356d798@github.com>
 <FzZY6RBGXd2YYTBcQR9Idz3WO_aXVor0_auv8zKUgvE=.646923cb-8a2a-4611-b526-9c2b6b351203@github.com>
Message-ID: <tES2xcOTM--wcJ4FNO1ay37cXxXywen3rv_q4ecJ_cM=.870bb63c-4de3-414b-affd-843ba8ef8d36@github.com>

On Fri, 6 Feb 2026 00:32:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing the Windows default time zones returned from `TimeZone.getDefault()` for some regions. On Windows, it uses their own regions for time zones that aren't 1-1 match to IANA's TZ database. Thus a mapping table is created as `conf/tzmappings` on Windows Java runtime. It is derived from CLDR's `windowsZones.xml` but it uses the obsolete IANA ids for their compatibility reasons. The fix is to replace the CLDR's old ids to the latest IANA ids for those regions.
>> Since it is hard to provide an automated test, as it involves the modification of the Windows' default time zone, regression test is not provided. Instead the fix is manually confirmed using the JIRA issue's example. Since this is a change in behavior, I will file a corresponding CSR/RN.
>> 
>> Here is the diff of the generated `conf/tzmappings` for reference:
>> 
>> @@ -13,7 +13,7 @@
>>  Arabian Standard Time:ZZ:Etc/GMT-4:
>>  Arabian Standard Time:001:Asia/Dubai:
>>  Arabic Standard Time:001:Asia/Baghdad:
>> -Argentina Standard Time:001:America/Buenos_Aires:
>> +Argentina Standard Time:001:America/Argentina/Buenos_Aires:
>>  Astrakhan Standard Time:001:Europe/Astrakhan:
>>  Atlantic Standard Time:BM:Atlantic/Bermuda:
>>  Atlantic Standard Time:GL:America/Thule:
>> @@ -58,7 +58,7 @@
>>  Central European Standard Time:MK:Europe/Skopje:
>>  Central European Standard Time:001:Europe/Warsaw:
>>  Central Pacific Standard Time:AQ:Antarctica/Casey:
>> -Central Pacific Standard Time:FM:Pacific/Ponape:
>> +Central Pacific Standard Time:FM:Pacific/Pohnpei:
>>  Central Pacific Standard Time:NC:Pacific/Noumea:
>>  Central Pacific Standard Time:VU:Pacific/Efate:
>>  Central Pacific Standard Time:ZZ:Etc/GMT-11:
>> @@ -75,7 +75,7 @@
>>  Dateline Standard Time:001:Etc/GMT+12:
>>  E. Africa Standard Time:AQ:Antarctica/Syowa:
>>  E. Africa Standard Time:DJ:Africa/Djibouti:
>> -E. Africa Standard Time:ER:Africa/Asmera:
>> +E. Africa Standard Time:ER:Africa/Asmara:
>>  E. Africa Standard Time:ET:Africa/Addis_Ababa:
>>  E. Africa Standard Time:KM:Indian/Comoro:
>>  E. Africa Standard Time:MG:Indian/Antananarivo:
>> @@ -101,10 +101,10 @@
>>  FLE Standard Time:FI:Europe/Helsinki:
>>  FLE Standard Time:LT:Europe/Vilnius:
>>  FLE Standard Time:LV:Europe/Riga:
>> -FLE Standard Time:001:Europe/Kiev:
>> +FLE Standard Time:001:Europe/Kyiv:
>>  Fiji Standard Time:001:Pacific/Fiji:
>>  GMT Standard Time:ES:Atlantic/Canary:
>> -GMT Standard Time:FO:Atlantic/Faeroe:
>> +GMT Standard Time:FO:Atlantic/Faroe:
>>  GMT Standard Time:GG:Europe/Guernsey:
>>  GMT Standard Time...
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/29591#issuecomment-3879307693

From naoto at openjdk.org  Wed Feb 11 09:46:20 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Feb 2026 09:46:20 GMT
Subject: Integrated: 8377013: TimeZone.getDefault() returns obsolete id on
 Windows (Asia/Calcutta)
In-Reply-To: <PMPp8Dq_aPJspR1mTJWBnZOvlsl_aRxf69oYFVSgK1I=.347739c4-b0f9-4d6f-82bc-55d5c356d798@github.com>
References: <PMPp8Dq_aPJspR1mTJWBnZOvlsl_aRxf69oYFVSgK1I=.347739c4-b0f9-4d6f-82bc-55d5c356d798@github.com>
Message-ID: <mJrOp5OQtEv7XxzDl4EOJsw5gLx5dektIcr4C_SkW8M=.f4dcd227-3bd6-4eac-a875-05115cbdbe67@github.com>

On Thu, 5 Feb 2026 17:27:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the Windows default time zones returned from `TimeZone.getDefault()` for some regions. On Windows, it uses their own regions for time zones that aren't 1-1 match to IANA's TZ database. Thus a mapping table is created as `conf/tzmappings` on Windows Java runtime. It is derived from CLDR's `windowsZones.xml` but it uses the obsolete IANA ids for their compatibility reasons. The fix is to replace the CLDR's old ids to the latest IANA ids for those regions.
> Since it is hard to provide an automated test, as it involves the modification of the Windows' default time zone, regression test is not provided. Instead the fix is manually confirmed using the JIRA issue's example. Since this is a change in behavior, I will file a corresponding CSR/RN.
> 
> Here is the diff of the generated `conf/tzmappings` for reference:
> 
> @@ -13,7 +13,7 @@
>  Arabian Standard Time:ZZ:Etc/GMT-4:
>  Arabian Standard Time:001:Asia/Dubai:
>  Arabic Standard Time:001:Asia/Baghdad:
> -Argentina Standard Time:001:America/Buenos_Aires:
> +Argentina Standard Time:001:America/Argentina/Buenos_Aires:
>  Astrakhan Standard Time:001:Europe/Astrakhan:
>  Atlantic Standard Time:BM:Atlantic/Bermuda:
>  Atlantic Standard Time:GL:America/Thule:
> @@ -58,7 +58,7 @@
>  Central European Standard Time:MK:Europe/Skopje:
>  Central European Standard Time:001:Europe/Warsaw:
>  Central Pacific Standard Time:AQ:Antarctica/Casey:
> -Central Pacific Standard Time:FM:Pacific/Ponape:
> +Central Pacific Standard Time:FM:Pacific/Pohnpei:
>  Central Pacific Standard Time:NC:Pacific/Noumea:
>  Central Pacific Standard Time:VU:Pacific/Efate:
>  Central Pacific Standard Time:ZZ:Etc/GMT-11:
> @@ -75,7 +75,7 @@
>  Dateline Standard Time:001:Etc/GMT+12:
>  E. Africa Standard Time:AQ:Antarctica/Syowa:
>  E. Africa Standard Time:DJ:Africa/Djibouti:
> -E. Africa Standard Time:ER:Africa/Asmera:
> +E. Africa Standard Time:ER:Africa/Asmara:
>  E. Africa Standard Time:ET:Africa/Addis_Ababa:
>  E. Africa Standard Time:KM:Indian/Comoro:
>  E. Africa Standard Time:MG:Indian/Antananarivo:
> @@ -101,10 +101,10 @@
>  FLE Standard Time:FI:Europe/Helsinki:
>  FLE Standard Time:LT:Europe/Vilnius:
>  FLE Standard Time:LV:Europe/Riga:
> -FLE Standard Time:001:Europe/Kiev:
> +FLE Standard Time:001:Europe/Kyiv:
>  Fiji Standard Time:001:Pacific/Fiji:
>  GMT Standard Time:ES:Atlantic/Canary:
> -GMT Standard Time:FO:Atlantic/Faeroe:
> +GMT Standard Time:FO:Atlantic/Faroe:
>  GMT Standard Time:GG:Europe/Guernsey:
>  GMT Standard Time:IE:Europe/Dublin:
>  GMT Standard Time:IM:Europe/Isle_of_Man:
> @@ -115,7 +115,7 @@
>  GTB St...

This pull request has now been integrated.

Changeset: 21d4c6c6
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21d4c6c68fc1199275b3317cd64ae24c8aeca003
Stats:     34 lines in 3 files changed: 29 ins; 0 del; 5 mod

8377013: TimeZone.getDefault() returns obsolete id on Windows (Asia/Calcutta)

Reviewed-by: jlu

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

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

From almatvee at openjdk.org  Wed Feb 11 09:46:12 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 11 Feb 2026 09:46:12 GMT
Subject: RFR: 8377514: jpackage: support passing multiple exceptions to the
 top-level error handler [v2]
In-Reply-To: <yoLzFMlOl-M_JBvPOBopaomr8D5h_I6MGsac-gSlNSA=.ea72dde1-a98e-49f0-8624-48c968f2c934@github.com>
References: <ZbVqysXuPvRn8fIgCtyQHjWylb9Tn8nKP6cY-gz36eY=.f18c0d3f-70c7-4973-b18a-c0f7eaaee52d@github.com>
 <yoLzFMlOl-M_JBvPOBopaomr8D5h_I6MGsac-gSlNSA=.ea72dde1-a98e-49f0-8624-48c968f2c934@github.com>
Message-ID: <crnafqYValZ-yqSmrllbzcnCKmrmNNK2DV1pPuf0sFQ=.10bcf17c-c785-485b-b331-c8361d4eb9ae@github.com>

On Wed, 11 Feb 2026 02:29:49 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Make the top-level error reporter handle suppressed exceptions.
>> 
>> The bundling code may use the suppressed exceptions mechanism to report multiple error conditions.
>> 
>> Rework reporting of multiple signing identity errors using the new mechanism, simplified `MacFromOptions.createMacPkgPackage()`.
>> 
>> Additionally:
>>  - Simplified AppImageSigningConfigBuilder and SigningIdentityBuilder
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright year update

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29643#pullrequestreview-3782506636

From jpai at openjdk.org  Wed Feb 11 09:46:03 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Feb 2026 09:46:03 GMT
Subject: RFR: 8219203: Use StringBuilder instead of StringBuffer in
 com.sun.jndi.dns.ResourceRecord
In-Reply-To: <c4mWSSOXzKmr0F94rqJ3I66rGNIE973qpOjOCoNFxoM=.fac4bf4e-4926-46b1-94c3-7fd2d4918079@github.com>
References: <c4mWSSOXzKmr0F94rqJ3I66rGNIE973qpOjOCoNFxoM=.fac4bf4e-4926-46b1-94c3-7fd2d4918079@github.com>
Message-ID: <5D425HJu2vszZ24gDkjkNaZ2ahRQZz4xu3MHfyQeV6E=.68cc8e8b-3d1c-4824-8da5-4bebeb8b015d@github.com>

On Tue, 10 Feb 2026 11:39:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which replaces the usage of `StringBuffer` with `StringBuilder` in the methods of `com.sun.jndi.dns.ResourceRecord`? This addresses https://bugs.openjdk.org/browse/JDK-8219203.
> 
> Given the nature of the change, no new tests have been introduced.

Thank you all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/29652#issuecomment-3881698041

From darcy at openjdk.org  Wed Feb 11 09:46:29 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 11 Feb 2026 09:46:29 GMT
Subject: RFR: 8375285: Port fdlibm asinh to Java [v8]
In-Reply-To: <4F7FK2EEtv90y37ECqa2nzt8Hnt7TVi7DNX874B9x94=.eeb5db92-690e-45e9-8ee8-a754f9c69487@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
 <p57-Mga85sxN41Hdd9JTLGNVazIrkfDjNtCIhz70-ME=.86050f09-06e0-4c6e-80ac-39794153f806@github.com>
 <HTq4KPrH8lZTVHT6_D3Gi1gMTzernd90gAPzZVEJT5c=.953c4ce3-6ee4-4d4c-9036-92763471579d@github.com>
 <Zgjlew-K02IYZ-EjoENRQzL8higlLSBGQ3Pr7VzA4CA=.2251ba23-b851-410e-900f-8a9f5a6bd1d7@github.com>
 <0w6KoryTq1Rb_a-q9eAULoFrGDLN-Jd_N12W-XwA5ns=.91e55f80-2bc0-44e2-be03-52c0cd1d8d07@github.com>
 <4F7FK2EEtv90y37ECqa2nzt8Hnt7TVi7DNX874B9x94=.eeb5db92-690e-45e9-8ee8-a754f9c69487@github.com>
Message-ID: <WZjt-EZPNhi_NwP_3XsXwXU9qOxJdS7r8m1hUs6jdHw=.61d739a2-4b25-424e-8c40-b1acd74c2199@github.com>

On Tue, 10 Feb 2026 02:03:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> @jddarcy What is the purpose of such methods that do not seem to be invoked?
>
>> @jddarcy What is the purpose of such methods that do not seem to be invoked?
> 
> I'm a bit confused; they do look to be used in that test file; e.g.
> 
> https://github.com/openjdk/jdk/blame/f9ded7f88cce75151cec32d1ef1f9662ea10431a/test/jdk/java/lang/Math/HyperbolicTests.java#L251
> 
> `            failures += testSinhCaseWithUlpDiff(testCase[0],`

> @jddarcy The concern is methods testing with tolerance, e.g. `testSinhCaseWithTolerance`. That one is never used. Same for `testCoshCaseWithTolerance`, `testTanhCaseWithTolerance`. If they are to be removed, I suggest to make is in a separate cleanup PR.

Ah, okay.

Looking at the history, those methods were including in the initial drop of files to OpenJDK and probably date back to when the hyperbolics were added in JDK 5. Without looking back at the ancient history, those methods might support test cases that were replaced by other test or written in anticipation of tests that were not written.

I think removing them in a follow-up pass is fine. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2789080207

From aartemov at openjdk.org  Wed Feb 11 09:46:39 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 11 Feb 2026 09:46:39 GMT
Subject: Integrated: 8375285: Port fdlibm asinh to Java
In-Reply-To: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
References: <C1PBobpWg5hTfJKObITVXPbQXiLI0LfiAzSooFj6Qck=.e58da6c8-4274-4465-be23-fbded39d45d6@github.com>
Message-ID: <BWrCYQhTJK21x2PmbqoCmd1O4TKOSo55sK0WJRXuxB8=.6aa582fc-4f5e-4b42-9ac0-6f0d01caf5b3@github.com>

On Fri, 16 Jan 2026 09:22:52 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM asinh method.
> 
> Original C vs transliteration port:
> 
> 
> $ diff -w fdlib_asinh.c Asinh.translit.java
> 1c1,3
> < /* asinh(x)
> ---
>> /**
>> * Return the Inverse Hyperbolic Sine of x
>> *
> 2a5
>> *
> 10a14,17
>> private static final class Asinh {
>>       private static final double one = 1.0;
>>       private static final double ln2 = 6.93147180559945286227e-01;
>>       private static final double huge = 1.0e300;
> 12,29c19
> < #include "fdlibm.h"
> <
> < #ifdef __STDC__
> < static const double
> < #else
> < static double
> < #endif
> < one =  1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */
> < ln2 =  6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */
> < huge=  1.00000000000000000000e+300;
> <
> < #ifdef __STDC__
> <       double asinh(double x)
> < #else
> <       double asinh(x)
> <       double x;
> < #endif
> < {
> ---
>>       static double compute(double x) {
> 39c29
> <           w = __ieee754_log(fabs(x))+ln2;
> ---
>>                       w = log(Math.abs(x))+ln2;
> 41,42c31,32
> <           t = fabs(x);
> <           w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t));
> ---
>>                       t = Math.abs(x);
>>                       w = log(2.0*t+one/(sqrt(x*x+one)+t));
> 45c35
> <           w =log1p(fabs(x)+t/(one+sqrt(one+t)));
> ---
>>                       w =log1p(Math.abs(x)+t/(one+sqrt(one+t)));
> 47a38
>>       }
> 
> Transliteration port vs more idiomatic port:
> 
> 
> $ diff -w Asinh.translit.java Asinh.fdlibm.java
> 6,9c6,12
> < *  Based on
> < *    asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ]
> < *   we have
> < *   asinh(x) := x  if  1+x*x=1,
> ---
>>  *
>>  *      asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF
>>  *      and sinh(asinh(x)) = x, -INF < x  < INF.
>>  *      It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x  < INF.
>>  *      1. Replace x by |x| as the function is odd.
>>  *      2.
>>  *          asinh(x) := x, if 1+x^2 = 1,
> 12a16,22
>>  *
>>  *
>>  *
>>  * Special cases:
>>  *      only asinh(0)=0 is exact for finite x.
>>  *      asinh(NaN) is NaN
>>  *      asinh(INF) is INF
> 14,15c24
> < private static final class Asinh {
> <       private static final double one = 1.0;
> ---
>> static final class Asinh {
> 24c33,35
> <               if(ix>=0x7ff00000) return x+x;  /* x is inf or NaN */
> ---
>>               if(ix >= 0x7ff00000) {
>>                       return x + x;                       /* x is inf or NaN */
>>               }
> 26c37,39
> <                       if(huge+x>one) return x;    /* return x inexact except 0...

This pull request has now been integrated.

Changeset: 43b2d2bd
Author:    Anton Artemov <aartemov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43b2d2bddf8d7c308c8d2782456cb3ab3a33993e
Stats:     586 lines in 7 files changed: 573 ins; 0 del; 13 mod

8375285: Port fdlibm asinh to Java

Reviewed-by: darcy, rgiulietti

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

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

From jpai at openjdk.org  Wed Feb 11 09:46:09 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Feb 2026 09:46:09 GMT
Subject: Integrated: 8219203: Use StringBuilder instead of StringBuffer in
 com.sun.jndi.dns.ResourceRecord
In-Reply-To: <c4mWSSOXzKmr0F94rqJ3I66rGNIE973qpOjOCoNFxoM=.fac4bf4e-4926-46b1-94c3-7fd2d4918079@github.com>
References: <c4mWSSOXzKmr0F94rqJ3I66rGNIE973qpOjOCoNFxoM=.fac4bf4e-4926-46b1-94c3-7fd2d4918079@github.com>
Message-ID: <Ub1Up7iZbw69YIldFkAs5lljDSQvWRjS0o-RXqX0flA=.8558bbe7-2dc2-49b9-8769-97571dbaeddb@github.com>

On Tue, 10 Feb 2026 11:39:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which replaces the usage of `StringBuffer` with `StringBuilder` in the methods of `com.sun.jndi.dns.ResourceRecord`? This addresses https://bugs.openjdk.org/browse/JDK-8219203.
> 
> Given the nature of the change, no new tests have been introduced.

This pull request has now been integrated.

Changeset: e516800b
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e516800b3e78e21d68460827ddced9225c3a2247
Stats:     8 lines in 1 file changed: 0 ins; 1 del; 7 mod

8219203: Use StringBuilder instead of StringBuffer in com.sun.jndi.dns.ResourceRecord

Reviewed-by: alanb, aefimov, rriggs, bpb, lancea

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

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

From asemenyuk at openjdk.org  Wed Feb 11 09:46:27 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 11 Feb 2026 09:46:27 GMT
Subject: Integrated: 8377514: jpackage: support passing multiple exceptions to
 the top-level error handler
In-Reply-To: <ZbVqysXuPvRn8fIgCtyQHjWylb9Tn8nKP6cY-gz36eY=.f18c0d3f-70c7-4973-b18a-c0f7eaaee52d@github.com>
References: <ZbVqysXuPvRn8fIgCtyQHjWylb9Tn8nKP6cY-gz36eY=.f18c0d3f-70c7-4973-b18a-c0f7eaaee52d@github.com>
Message-ID: <mlBZw9gCfLd_ICGmnX9uUsSLcGR540QLIKdA8S0TvSE=.69af33e5-2c7d-4d63-914a-14814c64d615@github.com>

On Tue, 10 Feb 2026 01:06:29 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Make the top-level error reporter handle suppressed exceptions.
> 
> The bundling code may use the suppressed exceptions mechanism to report multiple error conditions.
> 
> Rework reporting of multiple signing identity errors using the new mechanism, simplified `MacFromOptions.createMacPkgPackage()`.
> 
> Additionally:
>  - Simplified AppImageSigningConfigBuilder and SigningIdentityBuilder

This pull request has now been integrated.

Changeset: a87da517
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a87da5173f14d503664067713ab229e2e4fb6108
Stats:     715 lines in 11 files changed: 444 ins; 80 del; 191 mod

8377514: jpackage: support passing multiple exceptions to the top-level error handler

Reviewed-by: almatvee

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

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

From aartemov at openjdk.org  Wed Feb 11 10:07:31 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 11 Feb 2026 10:07:31 GMT
Subject: RFR: 8376665: Port fdlibm acosh to Java [v5]
In-Reply-To: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
References: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
Message-ID: <qmeoKt8VgTU75O5_58ReitzOC7-fdmpWWaLVY6WLH6I=.aaf2f066-99c2-4316-877d-3589d7809162@github.com>

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM acosh method.

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

  8376665: Fixed whitespaces.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29488/files
  - new: https://git.openjdk.org/jdk/pull/29488/files/32e51c37..702c955f

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

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

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

From jwilhelm at openjdk.org  Wed Feb 11 10:09:00 2026
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 11 Feb 2026 10:09:00 GMT
Subject: RFR: 8377509: Add licenses for gcc 14.2.0
Message-ID: <wQ7FUethHCraDe2hLn27x9N0XIyAlt39CaDnGaHdFo4=.4159ceb5-a44f-4f29-8f54-cf8660b2df57@github.com>

Added license file for gcc 14.2.0

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

Commit messages:
 - Removed tabs and trailing whitespaces
 - 8377509: Add licenses for gcc 14.2.0

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

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

From serb at openjdk.org  Wed Feb 11 10:09:04 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 11 Feb 2026 10:09:04 GMT
Subject: RFR: 8377509: Add licenses for gcc 14.2.0
In-Reply-To: <wQ7FUethHCraDe2hLn27x9N0XIyAlt39CaDnGaHdFo4=.4159ceb5-a44f-4f29-8f54-cf8660b2df57@github.com>
References: <wQ7FUethHCraDe2hLn27x9N0XIyAlt39CaDnGaHdFo4=.4159ceb5-a44f-4f29-8f54-cf8660b2df57@github.com>
Message-ID: <i4wy5HUXgMTp_lX9ODTAtgDubdtvNh41hmyRjQki0-s=.0790e653-88cc-4c63-ae50-4099df2fd7dd@github.com>

On Wed, 11 Feb 2026 00:09:48 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Added license file for gcc 14.2.0

> gcc was updated to 14.2.0 in JDK 25. Corresponding licenses should be added.

I wonder why the corresponding license needs to be added to the java.base module. Should this at least be followed by some tweaks in the makefiles?

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

PR Comment: https://git.openjdk.org/jdk/pull/29661#issuecomment-3882652084

From duke at openjdk.org  Wed Feb 11 10:10:36 2026
From: duke at openjdk.org (Harshit470250)
Date: Wed, 11 Feb 2026 10:10:36 GMT
Subject: RFR: 8377035: [s390x] Disable JSR166 test cases which uses virtual
 threads [v3]
In-Reply-To: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
References: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
Message-ID: <JvK7mMMqogV9IOg0R3WOmG3gamy6GnjhVhpvHTrBwYM=.e9b9ca79-0b51-4ce9-8fa1-6c30a46713fb@github.com>

> ReentrantReadWriteLock20Test.java is failing on s390 due to virtual threads which are not yet implemented on s390. 
> SynchronousQueue20Test.java also uses virtual thread so I am also disabling it.

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

  build platform library

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29555/files
  - new: https://git.openjdk.org/jdk/pull/29555/files/746240a7..6ab2d8bf

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

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

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

From aartemov at openjdk.org  Wed Feb 11 10:16:49 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 11 Feb 2026 10:16:49 GMT
Subject: RFR: 8376665: Port fdlibm acosh to Java [v6]
In-Reply-To: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
References: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
Message-ID: <qSsO7tj19yn2mbit3qOtD75f1TrrWCIaDuOdiRLUumI=.a16dce58-5c2a-46a0-a898-e89b7547a2e2@github.com>

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM acosh method.

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

  8376665: Fixed accidentally repeated testcase.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29488/files
  - new: https://git.openjdk.org/jdk/pull/29488/files/702c955f..dd5c5f7e

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

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

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

From jbhateja at openjdk.org  Wed Feb 11 10:42:32 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 11 Feb 2026 10:42:32 GMT
Subject: RFR: 8376186: [VectorAPI] Nomenclature change for concrete vector
 classes [v2]
In-Reply-To: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
References: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
Message-ID: <JhYx6qx3-eTm4uKLOImjGouDeXouNhiUEyiHYNMAHiE=.7b898af9-0e8b-4ecd-806f-de3304415cf4@github.com>

> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
> 
> In preparation of Float16 vector API support, changes to nomenclature of concrete vector class by suffixing the vector type with vector bit sizes e.g. FloatVector256 so that we don't end up generating names like Float16256Vector.
> 
> All existing Vector API jtreg test are passing with the patch.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

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

  Review comment resolution

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29614/files
  - new: https://git.openjdk.org/jdk/pull/29614/files/a5c98f86..c63c10a7

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

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

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

From jbhateja at openjdk.org  Wed Feb 11 10:42:35 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 11 Feb 2026 10:42:35 GMT
Subject: RFR: 8376186: [VectorAPI] Nomenclature change for concrete vector
 classes [v2]
In-Reply-To: <pZ_uBB3lTA1-0rXSDLbQqiA1iGOI86qudnUTzJDHTx8=.ea2c285b-a6cb-492d-a2ea-dcb5e0999837@github.com>
References: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
 <pZ_uBB3lTA1-0rXSDLbQqiA1iGOI86qudnUTzJDHTx8=.ea2c285b-a6cb-492d-a2ea-dcb5e0999837@github.com>
Message-ID: <ZUZ1T22P7xdsXmQBLFz_AsH-olmfxGvgr7OcUptOFx0=.6b2a884b-9611-40e0-881a-a828bf9e9697@github.com>

On Tue, 10 Feb 2026 18:27:10 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment resolution
>
> test/jdk/jdk/incubator/vector/gen-tests.sh line 61:
> 
>> 59:   args="-K$type -Dtype=$type -DType=$Type -DTYPE=$TYPE"
>> 60: 
>> 61:   VectorPrefix=$Type
> 
> This seems unnecessary - why do we need it?

Removed, thanks!

> test/jdk/jdk/incubator/vector/gen-tests.sh line 127:
> 
>> 125:   abstractvectortype=${typeprefix}${VectorPrefix}Vector
>> 126:   abstractvectorteststype=${typeprefix}${VectorPrefix}VectorTests
>> 127:   abstractbitsvectortype=${typeprefix}${VectorPrefixe}Vector
> 
> Suggestion:
> 
>   abstractbitsvectortype=${typeprefix}${VectorPrefix}Vector
> 
> But, why is it changed from ${Bitstype}?

Fixed!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29614#discussion_r2792539485
PR Review Comment: https://git.openjdk.org/jdk/pull/29614#discussion_r2792539345

From jpai at openjdk.org  Wed Feb 11 10:47:04 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Feb 2026 10:47:04 GMT
Subject: RFR: 8377035: [s390x] Disable JSR166 test cases which uses virtual
 threads [v3]
In-Reply-To: <JvK7mMMqogV9IOg0R3WOmG3gamy6GnjhVhpvHTrBwYM=.e9b9ca79-0b51-4ce9-8fa1-6c30a46713fb@github.com>
References: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
 <JvK7mMMqogV9IOg0R3WOmG3gamy6GnjhVhpvHTrBwYM=.e9b9ca79-0b51-4ce9-8fa1-6c30a46713fb@github.com>
Message-ID: <7vOR92YZ7buwR1UMnWjCkvAcG2KkiFH__bvXJOz-2NQ=.d496b47e-d4d4-43c4-9d0d-abda567da8b9@github.com>

On Wed, 11 Feb 2026 10:10:36 GMT, Harshit470250 <duke at openjdk.org> wrote:

>> ReentrantReadWriteLock20Test.java is failing on s390 due to virtual threads which are not yet implemented on s390. 
>> SynchronousQueue20Test.java also uses virtual thread so I am also disabling it.
>
> Harshit470250 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   build platform library

This looks OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29555#pullrequestreview-3784055093

From cstein at openjdk.org  Wed Feb 11 10:48:57 2026
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 11 Feb 2026 10:48:57 GMT
Subject: RFR: 8377656: JUnit test
 java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java uses private methods for
 BeforeAll/AfterAll
In-Reply-To: <KTOTySPrSBi2nRvezafHn2pv8YHGRnIgJHqqavePtw0=.3b37c043-86dc-4403-b0f0-43eb7ce08439@github.com>
References: <KTOTySPrSBi2nRvezafHn2pv8YHGRnIgJHqqavePtw0=.3b37c043-86dc-4403-b0f0-43eb7ce08439@github.com>
Message-ID: <IS8zbeSUlPowJi7gMZGCTz5x_XyGPutrJXXMP5ShcpE=.2c35dc3a-0756-4e1c-8664-e836ba1c3d0d@github.com>

On Wed, 11 Feb 2026 10:40:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only fix which addresses a test issue in `test/jdk/java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java`? As noted in https://bugs.openjdk.org/browse/JDK-8377656, the test uses `private` methods for `@BeforeAll`/`@AfterAll` which is discouraged by JUnit.
> 
> With the recent upgrade of jtreg https://bugs.openjdk.org/browse/JDK-8376355 such warnings now intentionally cause test failures. This wasn't caught during the integration of JDK-8376355  because the CI run for JDK-8376355 was done prior to the recent changes of these `java/util/zip` tests from testng to junit in https://bugs.openjdk.org/browse/JDK-8377116.
> 
> I've first reproduced this failure locally and then reran the tests under `java/util/zip` with this change and they all pass now. tier1 testing is currently in progress and I'll integrate this once that completes.

Marked as reviewed by cstein (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/29670#pullrequestreview-3784040033

From jpai at openjdk.org  Wed Feb 11 10:48:57 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Feb 2026 10:48:57 GMT
Subject: RFR: 8377656: JUnit test
 java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java uses private methods for
 BeforeAll/AfterAll
Message-ID: <KTOTySPrSBi2nRvezafHn2pv8YHGRnIgJHqqavePtw0=.3b37c043-86dc-4403-b0f0-43eb7ce08439@github.com>

Can I please get a review of this test-only fix which addresses a test issue in `test/jdk/java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java`? As noted in https://bugs.openjdk.org/browse/JDK-8377656, the test uses `private` methods for `@BeforeAll`/`@AfterAll` which is discouraged by JUnit.

With the recent upgrade of jtreg https://bugs.openjdk.org/browse/JDK-8376355 such warnings now intentionally cause test failures. This wasn't caught during the integration of JDK-8376355  because the CI run for JDK-8376355 was done prior to the recent changes of these `java/util/zip` tests from testng to junit in https://bugs.openjdk.org/browse/JDK-8377116.

I've first reproduced this failure locally and then reran the tests under `java/util/zip` with this change and they all pass now. tier1 testing is currently in progress and I'll integrate this once that completes.

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

Commit messages:
 - 8377656: JUnit test java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java uses private methods for BeforeAll/AfterAll

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

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

From alanb at openjdk.org  Wed Feb 11 10:48:58 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Feb 2026 10:48:58 GMT
Subject: RFR: 8377656: JUnit test
 java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java uses private methods for
 BeforeAll/AfterAll
In-Reply-To: <KTOTySPrSBi2nRvezafHn2pv8YHGRnIgJHqqavePtw0=.3b37c043-86dc-4403-b0f0-43eb7ce08439@github.com>
References: <KTOTySPrSBi2nRvezafHn2pv8YHGRnIgJHqqavePtw0=.3b37c043-86dc-4403-b0f0-43eb7ce08439@github.com>
Message-ID: <aKsmy_xAEQCsv4X0KHcXWD37Xj-ZZ-N1gI_BrnbpkTQ=.273c5001-537b-4163-bc5d-f8a00592be9f@github.com>

On Wed, 11 Feb 2026 10:40:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only fix which addresses a test issue in `test/jdk/java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java`? As noted in https://bugs.openjdk.org/browse/JDK-8377656, the test uses `private` methods for `@BeforeAll`/`@AfterAll` which is discouraged by JUnit.
> 
> With the recent upgrade of jtreg https://bugs.openjdk.org/browse/JDK-8376355 such warnings now intentionally cause test failures. This wasn't caught during the integration of JDK-8376355  because the CI run for JDK-8376355 was done prior to the recent changes of these `java/util/zip` tests from testng to junit in https://bugs.openjdk.org/browse/JDK-8377116.
> 
> I've first reproduced this failure locally and then reran the tests under `java/util/zip` with this change and they all pass now. tier1 testing is currently in progress and I'll integrate this once that completes.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29670#pullrequestreview-3784040830

From aartemov at openjdk.org  Wed Feb 11 11:04:02 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 11 Feb 2026 11:04:02 GMT
Subject: RFR: 8376665: Port fdlibm acosh to Java [v7]
In-Reply-To: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
References: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
Message-ID: <GzviyITmy02TvDM982wKv3R_bdXSp6oWYT947Pb5sn4=.7a353745-deea-4a6a-b0e0-c28dbac556b6@github.com>

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM acosh method.

Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:

 - 8376665: Stylistical fixes.
 - 8376665: Stylistical fixes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29488/files
  - new: https://git.openjdk.org/jdk/pull/29488/files/dd5c5f7e..9e468d66

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

  Stats: 31 lines in 5 files changed: 0 ins; 2 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/29488.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29488/head:pull/29488

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

From jpai at openjdk.org  Wed Feb 11 11:05:57 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Feb 2026 11:05:57 GMT
Subject: RFR: 8377656: JUnit test
 java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java uses private methods for
 BeforeAll/AfterAll
In-Reply-To: <KTOTySPrSBi2nRvezafHn2pv8YHGRnIgJHqqavePtw0=.3b37c043-86dc-4403-b0f0-43eb7ce08439@github.com>
References: <KTOTySPrSBi2nRvezafHn2pv8YHGRnIgJHqqavePtw0=.3b37c043-86dc-4403-b0f0-43eb7ce08439@github.com>
Message-ID: <nL2Sq67b_uoXBcpYXpUDOVog9DtCvhKNiPj7TwiEG0I=.fe6fa7af-b9b8-4395-ab41-75e241f062c1@github.com>

On Wed, 11 Feb 2026 10:40:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only fix which addresses a test issue in `test/jdk/java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java`? As noted in https://bugs.openjdk.org/browse/JDK-8377656, the test uses `private` methods for `@BeforeAll`/`@AfterAll` which is discouraged by JUnit.
> 
> With the recent upgrade of jtreg https://bugs.openjdk.org/browse/JDK-8376355 such warnings now intentionally cause test failures. This wasn't caught during the integration of JDK-8376355  because the CI run for JDK-8376355 was done prior to the recent changes of these `java/util/zip` tests from testng to junit in https://bugs.openjdk.org/browse/JDK-8377116.
> 
> I've first reproduced this failure locally and then reran the tests under `java/util/zip` with this change and they all pass now. tier1 testing is currently in progress and I'll integrate this once that completes.

Thank you Alan and Christian for the reviews. tier1 completed successfully with this change. I'll go ahead and integrate this now.

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

PR Comment: https://git.openjdk.org/jdk/pull/29670#issuecomment-3883707886

From jpai at openjdk.org  Wed Feb 11 11:05:58 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Feb 2026 11:05:58 GMT
Subject: Integrated: 8377656: JUnit test
 java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java uses private methods for
 BeforeAll/AfterAll
In-Reply-To: <KTOTySPrSBi2nRvezafHn2pv8YHGRnIgJHqqavePtw0=.3b37c043-86dc-4403-b0f0-43eb7ce08439@github.com>
References: <KTOTySPrSBi2nRvezafHn2pv8YHGRnIgJHqqavePtw0=.3b37c043-86dc-4403-b0f0-43eb7ce08439@github.com>
Message-ID: <6z4RgbGigklYunnJOYg2frbYWQUAxLiHImmogROjLPM=.ec2d4d58-170c-42ca-89c9-d0a215264f2e@github.com>

On Wed, 11 Feb 2026 10:40:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only fix which addresses a test issue in `test/jdk/java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java`? As noted in https://bugs.openjdk.org/browse/JDK-8377656, the test uses `private` methods for `@BeforeAll`/`@AfterAll` which is discouraged by JUnit.
> 
> With the recent upgrade of jtreg https://bugs.openjdk.org/browse/JDK-8376355 such warnings now intentionally cause test failures. This wasn't caught during the integration of JDK-8376355  because the CI run for JDK-8376355 was done prior to the recent changes of these `java/util/zip` tests from testng to junit in https://bugs.openjdk.org/browse/JDK-8377116.
> 
> I've first reproduced this failure locally and then reran the tests under `java/util/zip` with this change and they all pass now. tier1 testing is currently in progress and I'll integrate this once that completes.

This pull request has now been integrated.

Changeset: 6a5eb26d
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6a5eb26dcf9e9dcf16e80b7c46f16a236a893aef
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8377656: JUnit test java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java uses private methods for BeforeAll/AfterAll

Reviewed-by: cstein, alanb

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

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

From jpai at openjdk.org  Wed Feb 11 11:14:52 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Feb 2026 11:14:52 GMT
Subject: RFR: 8377388: Replacing "new StringReader(String)" by
 "Reader.of(CharSequence);" in Scanner
In-Reply-To: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
References: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
Message-ID: <RQSySLXetqxtIQxi_qNXMkgcq8uB5Jy3MkAM2ZHYeQs=.5e8ec8ee-c2fb-4436-8e51-f06dd2905d5b@github.com>

On Mon, 9 Feb 2026 07:33:03 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Request provides an implementation for [JDK-8377388](https://bugs.openjdk.org/browse/JDK-8377388): 'Replacing "new StringReader(String)" by "Reader.of(CharSequence);" in Scanner'.

This looks OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29627#pullrequestreview-3784170624

From alanb at openjdk.org  Wed Feb 11 11:50:33 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Feb 2026 11:50:33 GMT
Subject: RFR: 8377388: Replacing "new StringReader(String)" by
 "Reader.of(CharSequence);" in Scanner
In-Reply-To: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
References: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
Message-ID: <i_mz9Ak9Wu3PvWNhsGucwCHTPXZie5-DpBDRNDxYc4g=.8c5b5da5-5852-499a-aabc-46539f905a56@github.com>

On Mon, 9 Feb 2026 07:33:03 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Request provides an implementation for [JDK-8377388](https://bugs.openjdk.org/browse/JDK-8377388): 'Replacing "new StringReader(String)" by "Reader.of(CharSequence);" in Scanner'.

@mkarg I assume you will create the CSR for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/29627#issuecomment-3883924689

From duke at openjdk.org  Wed Feb 11 11:50:34 2026
From: duke at openjdk.org (Markus KARG)
Date: Wed, 11 Feb 2026 11:50:34 GMT
Subject: RFR: 8377388: Replacing "new StringReader(String)" by
 "Reader.of(CharSequence);" in Scanner
In-Reply-To: <i_mz9Ak9Wu3PvWNhsGucwCHTPXZie5-DpBDRNDxYc4g=.8c5b5da5-5852-499a-aabc-46539f905a56@github.com>
References: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
 <i_mz9Ak9Wu3PvWNhsGucwCHTPXZie5-DpBDRNDxYc4g=.8c5b5da5-5852-499a-aabc-46539f905a56@github.com>
Message-ID: <BkpLtUw3Jo8X86sok9xvzDmWKsQI2gBFZ10btQb8SzM=.c81f1869-209f-4271-b243-1984b3052fa4@github.com>

On Wed, 11 Feb 2026 11:46:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> @mkarg I assume you will create the CSR for this.

Yes, typing it right in this very moment. :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/29627#issuecomment-3883929526

From duke at openjdk.org  Wed Feb 11 11:58:23 2026
From: duke at openjdk.org (Markus KARG)
Date: Wed, 11 Feb 2026 11:58:23 GMT
Subject: RFR: 8377388: Replacing "new StringReader(String)" by
 "Reader.of(CharSequence);" in Scanner
In-Reply-To: <BkpLtUw3Jo8X86sok9xvzDmWKsQI2gBFZ10btQb8SzM=.c81f1869-209f-4271-b243-1984b3052fa4@github.com>
References: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
 <i_mz9Ak9Wu3PvWNhsGucwCHTPXZie5-DpBDRNDxYc4g=.8c5b5da5-5852-499a-aabc-46539f905a56@github.com>
 <BkpLtUw3Jo8X86sok9xvzDmWKsQI2gBFZ10btQb8SzM=.c81f1869-209f-4271-b243-1984b3052fa4@github.com>
Message-ID: <mldF1gtv609bc8rEKiclNbCEt_cAVHJW799VCPVMjC4=.482abb2f-f76c-45eb-bcfa-b1f41c1a6532@github.com>

On Wed, 11 Feb 2026 11:47:13 GMT, Markus KARG <duke at openjdk.org> wrote:

> @mkarg I assume you will create the CSR for this.

Kindly asking for reviews on CSR draft https://bugs.openjdk.org/browse/JDK-8377660. Thank you. :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/29627#issuecomment-3883964196

From smonteith at openjdk.org  Wed Feb 11 12:47:29 2026
From: smonteith at openjdk.org (Stuart Monteith)
Date: Wed, 11 Feb 2026 12:47:29 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <kRi61jloPuIqbNpENKgKl5GZ-Dzf_yKO7HkbMW3iP1M=.e61813a6-e51d-4ee0-993b-83c1aa1d7ed5@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
 <kRi61jloPuIqbNpENKgKl5GZ-Dzf_yKO7HkbMW3iP1M=.e61813a6-e51d-4ee0-993b-83c1aa1d7ed5@github.com>
Message-ID: <RZhq9CtQJRbR7S2Dkw2CJSUMQpaRh1RYXs29ZMzwFD4=.a25031da-e393-406d-aac2-596d085ae19f@github.com>

On Mon, 9 Feb 2026 12:50:14 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Thanks for looking at this.
> 
> Besides the code comments, there are few points that I'd like to bring up as well:
> 
>     1. I'm not sure I see using a ticket being worth it vs. just calling `getCounter` again in `release0`. The JIT understands that the current thread doesn't change in most situations, so it should be able to common out the load of the hash code.
> 
>     2. This adds significant footprint to SharedSession. Especially on server class machines which can have as much as to 512 logical processors (or more), this would add 8 pages of memory use per session instance, assuming the typical 64 byte cache line size, just for the counters.
> 
>     3. This is already a tricky bit of code in which we've seen several hard to diagnose issues. So, making changes here makes me a bit nervous, and I'm honestly having a hard time judging the cost vs. benefit of this change, considering also that the benchmark is testing the absolute worst case scenario where the acquire/release are being hammered. (and now I _really_ wish I had found the time to look at this earlier).
> 
> 
> Given 2. and 3. taken together, and out of an abundance of caution, I suggest keeping both the old and new implementations as separate MemorySessionImpl sub-classes, and then using a system property to select one or the other in `createShared`. Just in case someone wants to switch back to the single counter implementation, or in case we want to use this to diagnose an issue. (Having a single static property select between the impls should also avoid issues with megamorphic call sites since the total number of loaded impls in a given process should stay the same).

Thank you both for looking at this in such detail, I know it is a lot of work.

re: 1 - My original version had both release0() and release0(int ticket), as in most cases it was unnecessary. I decided to require a ticket to reduce the chance of a bug being introduced when the ticket actually did need to be passed between threads. The IOUtil Releasers are example of where the tickets are necessary. The side effect, of course, was many more changes. I benchmarked with both, and it didn't make a measurable difference.

re: 2 - I was initially experimenting with a SharedSession and a MultiSharedSession, which was switchable in MemorySessionImp with a property. I didn't submit that, thinking that another option would be undesirable. To avoid the overhead, where it is unnecessary, I have been experimenting with a single counter that only expands to multiple counters when there is contention, but does add to the complexity - I'm not there yet. There doesn't have to be a 1:1 ratio between the number of cores and the number of counters - you can get much of the benefit with a 4:1 or even 8:1 ratio, which would reduce the memory overhead somewhat. 

While the microbenchmark does hammer the code, there was a real issue the patch was addressing. We had an issue where someone had to work the scalability issue in  SharedSession by reimplementing their code with JNI.

> Overall, I think that this is a good experiment (and I'm very grateful for it), but I'm a bit skeptical in seeing it introduced in the JDK codebase. This is a very sensitive area, with lots of multi-threaded gotchas (lots of different failure modes to take into account). As I commented originally, I still feel like separating the ref counter from the liveness bit (ignoring everything else) brings even more failure modes to the table.
> 
> After discussing all of this with @JornVernee, we agreed that we should refrain from integrating this work (even if provided merely as an option), and maybe keep the door open to explore other alternatives that might provide some relief, while keeping the code more maintainable in the long run

Thank you too for taking the time to review this. That is all fair. The circumstance where this was necessary might be quite rare as it only applies when Arena.ofShared() arenas don't scale when memory is shared across a number of threads with many calls to quickly executing native functions. Instead I'd imagine we'd recommend using Arena.ofAuto(), or perhaps confined without sharing the memory, or at worst JNI could be used instead. 

This issue was spotted using the async-profiler. With a large number of threads executing with the same SharedSession. It was observed that more time and more time is spent in SharedSession.acquire0() and SharedSession.release0()  as the load on the server increased.

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

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3884203193

From duke at openjdk.org  Wed Feb 11 13:50:09 2026
From: duke at openjdk.org (jengebr)
Date: Wed, 11 Feb 2026 13:50:09 GMT
Subject: RFR: 8371656: HashMap.putAll() optimizations [v3]
In-Reply-To: <g3TjdIsFb1rPWELfUbyonfFEoNC5RRhfWFVL2TcQRk8=.de57ae82-8e40-4925-bf9b-c75aa901d722@github.com>
References: <L9LdywP8aeyIW9SVHLEsRSUmuaa2vWWQyMW9pTrLtHA=.363bd16c-febb-4028-96b9-a01cdd0d86a2@github.com>
 <ueLHOkfYfe15Ur0RmZDF7j93vGs1x0w48Zib1mZ4rF0=.bba5969c-4504-4921-a6e7-0a1a39395f9b@github.com>
 <g3TjdIsFb1rPWELfUbyonfFEoNC5RRhfWFVL2TcQRk8=.de57ae82-8e40-4925-bf9b-c75aa901d722@github.com>
Message-ID: <6ftJ6LFTLKfHfnMYMp9qpITZJUBWgl7-wWWmPDNfNUc=.35eb07c8-eb8e-4794-85da-00770b3d9839@github.com>

On Wed, 4 Feb 2026 21:08:00 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> jengebr has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into putMapEntriesOptimizations
>>  - Unit test revisions
>>  - Bug fix & unit test
>>  - fixing whitespace
>>  - Optimizing HashMap.putAll() and .<init> for HashMap and C$UM
>
> src/java.base/share/classes/java/util/HashMap.java line 516:
> 
>> 514:      */
>> 515:     final void putMapEntries(Map<? extends K, ? extends V> m, boolean evict) {
>> 516:         if (m.getClass() == Collections.UnmodifiableMap.class) {
> 
> I would address that issue in a separate bug.

What issue?  This is an integral part of the performance optimization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28243#discussion_r2793389419

From rgiulietti at openjdk.org  Wed Feb 11 14:09:37 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 11 Feb 2026 14:09:37 GMT
Subject: RFR: 8376665: Port fdlibm acosh to Java [v7]
In-Reply-To: <GzviyITmy02TvDM982wKv3R_bdXSp6oWYT947Pb5sn4=.7a353745-deea-4a6a-b0e0-c28dbac556b6@github.com>
References: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
 <GzviyITmy02TvDM982wKv3R_bdXSp6oWYT947Pb5sn4=.7a353745-deea-4a6a-b0e0-c28dbac556b6@github.com>
Message-ID: <tKmGjSsen_LFBdHd06iGGFRCseLMIBrmKm-LyPlwpOU=.be769fa1-e2f3-4224-b9cd-1933126b13f0@github.com>

On Wed, 11 Feb 2026 11:04:02 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM acosh method.
>
> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8376665: Stylistical fixes.
>  - 8376665: Stylistical fixes.

Otherwise looks fine.

src/java.base/share/classes/java/lang/FdLibm.java line 3573:

> 3571:      *      acosh(x) is defined so that acosh(cosh(alpha)) = alpha, -&infin; &lt; alpha < &infin
> 3572:      *      and cosh(acosh(x)) = x, 1 <= x  < &infin.
> 3573:      *      It can be written as acosh(x) = ln(x + sqrt(x^2 - 1)), 1 <= x  < &infin.

It's `&infin;` with a semicolon, like any HTML entity name.
Also, replace `<` with `&lt;`

src/java.base/share/classes/java/lang/FdLibm.java line 3574:

> 3572:      *      and cosh(acosh(x)) = x, 1 <= x  < &infin.
> 3573:      *      It can be written as acosh(x) = ln(x + sqrt(x^2 - 1)), 1 <= x  < &infin.
> 3574:      *      acosh(x) := log(x)+ln2, if x is large; else

Using both log and ln in the same context might be confusing. Consistency would be welcome.

src/java.base/share/classes/java/lang/Math.java line 2793:

> 2791:      * Returns the inverse hyperbolic cosine of a {@code double} value.
> 2792:      * The inverse hyperbolic cosine of <i>x</i> is defined to be the function such that
> 2793:      *  acosh({@linkplain Math#cosh cosh(<i>x</i>)}) = <i>x</i> for any <i>x >= 0</i>.

Suggestion:

     *  acosh({@linkplain Math#cosh cosh(<i>x</i>)}) = <i>x</i> for any <i>x</i> >= 0.

src/java.base/share/classes/java/lang/StrictMath.java line 2202:

> 2200:      * Returns the inverse hyperbolic cosine of a {@code double} value.
> 2201:      * The inverse hyperbolic cosine of <i>x</i> is defined to be the function such that
> 2202:      *  acosh({@linkplain Math#cosh cosh(<i>x</i>)}) = <i>x</i> for any <i>x >= 0</i>.

Suggestion:

     *  acosh({@linkplain Math#cosh cosh(<i>x</i>)}) = <i>x</i> for any <i>x</i> >= 0.

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

PR Review: https://git.openjdk.org/jdk/pull/29488#pullrequestreview-3785030643
PR Review Comment: https://git.openjdk.org/jdk/pull/29488#discussion_r2793485148
PR Review Comment: https://git.openjdk.org/jdk/pull/29488#discussion_r2793485365
PR Review Comment: https://git.openjdk.org/jdk/pull/29488#discussion_r2793485903
PR Review Comment: https://git.openjdk.org/jdk/pull/29488#discussion_r2793486254

From rriggs at openjdk.org  Wed Feb 11 15:03:19 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 11 Feb 2026 15:03:19 GMT
Subject: RFR: 8377388: Replacing "new StringReader(String)" by
 "Reader.of(CharSequence);" in Scanner
In-Reply-To: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
References: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
Message-ID: <1L8AlfnOqBJ94BTUPLFsDpRkxAYpu0F-yPM5DqhuojM=.a9e0d26f-7a42-4889-b90b-42af111b32de@github.com>

On Mon, 9 Feb 2026 07:33:03 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Request provides an implementation for [JDK-8377388](https://bugs.openjdk.org/browse/JDK-8377388): 'Replacing "new StringReader(String)" by "Reader.of(CharSequence);" in Scanner'.

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29627#pullrequestreview-3785360695

From duke at openjdk.org  Wed Feb 11 15:28:56 2026
From: duke at openjdk.org (jengebr)
Date: Wed, 11 Feb 2026 15:28:56 GMT
Subject: RFR: 8371656: HashMap.putAll() optimizations [v4]
In-Reply-To: <L9LdywP8aeyIW9SVHLEsRSUmuaa2vWWQyMW9pTrLtHA=.363bd16c-febb-4028-96b9-a01cdd0d86a2@github.com>
References: <L9LdywP8aeyIW9SVHLEsRSUmuaa2vWWQyMW9pTrLtHA=.363bd16c-febb-4028-96b9-a01cdd0d86a2@github.com>
Message-ID: <-5_RzT-cXjHI1QhuWQD_nKj25TNQvEbuf-jdl1EPAiM=.3a945bac-b2c4-4132-b8f1-bb8de3030dc6@github.com>

> # HashMap.putAll() optimizations: Eliminating Megamorphic Call Site Bottlenecks
> 
> ## Summary
> 
> This PR addresses performance bottlenecks in `HashMap.putMapEntries()` by implementing direct optimizations for specific input types: `j.u.HashMap` and `j.u.Collections$UnmodifiableMap`. The optimizations target `HashMap(Map)` constructor and `putAll()` operations based on the real-world megamorphic behavior identified in [JDK-8368292](https://bugs.openjdk.org/browse/JDK-8368292), delivering significant performance improvements when multiple `Map` subtypes are used.
> 
> ## Problem Context
> 
> ### Megamorphic Call Site Overhead in Map Iteration
> `HashMap.putMapEntries()` currently uses a generic approach that suffers from megamorphic call site overhead when applications perform bulk creation or population of HashMaps from various source map types:
> 
> 1. `m.entrySet()` becomes megamorphic across different map implementations
> 2. `entrySet().iterator()` creates different iterator types
> 3. `entry.getKey()` and `entry.getValue()` calls vary by map type
> 4. Individual `putVal()` calls for each entry
> 
> When the source is `Collections$UnmodifiableMap`, the problem is compounded by megamorphic wrappers around the already-megamorphic iteration methods. In cases where the unwrapped map is also a HashMap, both the wrapper overhead and the iteration overhead can be eliminated with a single optimization.
> 
> ## Optimized Methods
> 
> ### HashMap
> - **`putMapEntries(Map<? extends K, ? extends V> m, boolean evict)`**: Added fast paths for UnmodifiableMap unwrapping and HashMap-to-HashMap copying
> - **`putMapEntries(HashMap<? extends K, ? extends V> src, boolean evict)`**: copies HashMap-to-HashMap via direct Node processing.  Avoids polymorphic issues and eliminates redundant calls to HashMap.hash().
> 
> ## Implementation Details
> 
> ### HashMap-to-HashMap Fast Path
> Eliminates megamorphic iteration by targeting internal Node structure - and also reuses the pre-calculated hash code, thus avoiding megamorphic calls to Object.hashCode() and the sometimes-expensive recalculation (depending on key type).  This also eliminates direct reads from the key, thus reducing the set of objects accessed.
> 
> ### UnmodifiableMap Unwrapping
> Detects UnmodifiableMap instances and accesses the underlying map directly via the `m` field, eliminating wrapper-induced megamorphic call sites. UnmodifiableMap visibility changed from `private` to package-private to enable this direct access.
> 
> ## Performance Impact
> 
> | Source Type | Size |...

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

  Addressing CR feedback (formatting + safe casts)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28243/files
  - new: https://git.openjdk.org/jdk/pull/28243/files/1b09326c..bae73f88

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

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

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

From dl at openjdk.org  Wed Feb 11 15:30:37 2026
From: dl at openjdk.org (Doug Lea)
Date: Wed, 11 Feb 2026 15:30:37 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v33]
In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
Message-ID: <cUt9TsLgbX8njmuFOD_UbhJL-_39dvP9mv8Ihh69xTc=.8caa6d68-3ada-4aa6-9245-bd506f6027e5@github.com>

> Changes signal filtering to avoid possible starvation

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

  Revert some layout and sizing, better match spin vs scan

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28797/files
  - new: https://git.openjdk.org/jdk/pull/28797/files/1b9272b3..f67bfb19

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=31-32

  Stats: 60 lines in 1 file changed: 16 ins; 13 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/28797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28797/head:pull/28797

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

From jbhateja at openjdk.org  Wed Feb 11 16:16:04 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 11 Feb 2026 16:16:04 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v12]
In-Reply-To: <EUYLcTJ-tPZabk2LcLzwYne6MgOdrQ7PDqkx6lOvsJs=.7c5a65d0-0efc-4636-843d-93815f327a25@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <YbIRslmURu8J4TLXTCHEeo7F3IwpvGPiYMDA-6w7_xA=.386a3af7-73ac-42f2-9e05-d34c436872a7@github.com>
 <BCaFfmFgSFPW0kPql80L-9Uic7tu5fwpnXBLpn9uyP8=.b184ac3f-faac-4062-9b15-ad07ac5fe0c0@github.com>
 <EUYLcTJ-tPZabk2LcLzwYne6MgOdrQ7PDqkx6lOvsJs=.7c5a65d0-0efc-4636-843d-93815f327a25@github.com>
Message-ID: <cNEPOeynQkxzshTwW6s9rvXNVnDaNKX9Y_M6vTr6rZY=.eb3cd43d-ed22-4974-899d-2a5622542e41@github.com>

On Mon, 26 Jan 2026 17:43:41 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> LGTM! Thanks for your updating!
>
>> Hi @XiaohongGong , your comments have been addressed. Hi @sviswa7, can you kindly review x86 part.
> 
> Thanks @jatin-bhateja. I will take a look next week.

Hi @sviswa7 , @merykitty , Can you please review x86 backed implementation and approve.

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

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3885441940

From eirbjo at openjdk.org  Wed Feb 11 16:47:04 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 11 Feb 2026 16:47:04 GMT
Subject: Integrated: 8377461: Add ZipFile test for incorrect number of entries
 reported in ENDTOT
In-Reply-To: <HNKqPs_z16aAUi5uScwFT9ICjbLZDGZEJOSF-kuHdNo=.249a67d7-a6c1-4991-9777-f2e8f1d85c72@github.com>
References: <HNKqPs_z16aAUi5uScwFT9ICjbLZDGZEJOSF-kuHdNo=.249a67d7-a6c1-4991-9777-f2e8f1d85c72@github.com>
Message-ID: <xR5Kx6VgcsmobyhUABiY844bzdCzvacfQGgyIYQmiHM=.746bb78e-6eaf-4ab5-8c37-c728354a7c4e@github.com>

On Mon, 9 Feb 2026 12:27:31 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR introducing a test to verify that `ZipFile::size` reports the actual number of CEN entries in a ZIP file, despite an incorrect number being reported in the END header.
> 
> Background:
> 
> The `ZipFile` implementation treats `ENDTOT` as an indication, but falls back to counting CEN entries if this number is too low. After parsing the CEN, there is also code to adjust the total down to the actual count of CEN entries.
> 
> The behavior of always reporting the actual number of CEN entries has no current test coverage in the JDK. It seems good to have tests excercising these code paths and protecting against regressions in this area.
> 
> Verification:
> 
> Verified that the new test catches introduced regressions in handling over- and underreported numbers in ENDTOT and that no existing test catches such regressions.
> 
> Test-only change, `noreg-self`.

This pull request has now been integrated.

Changeset: b98899b4
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b98899b441222ce9cd6a2a74e86193c091e088e6
Stats:     117 lines in 1 file changed: 117 ins; 0 del; 0 mod

8377461: Add ZipFile test for incorrect number of entries reported in ENDTOT

Reviewed-by: lancea

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

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

From bpb at openjdk.org  Wed Feb 11 18:09:12 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Feb 2026 18:09:12 GMT
Subject: RFR: 8377388: Replacing "new StringReader(String)" by
 "Reader.of(CharSequence);" in Scanner
In-Reply-To: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
References: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
Message-ID: <ROxYtehRgrbV4u_DD_HgDIzQWdQDt4KRVkGydRrWsfg=.b7cc7669-f32b-44b7-ae13-27a1510e75df@github.com>

On Mon, 9 Feb 2026 07:33:03 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Request provides an implementation for [JDK-8377388](https://bugs.openjdk.org/browse/JDK-8377388): 'Replacing "new StringReader(String)" by "Reader.of(CharSequence);" in Scanner'.

Looks fine.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29627#pullrequestreview-3786377117

From jwilhelm at openjdk.org  Wed Feb 11 18:12:34 2026
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 11 Feb 2026 18:12:34 GMT
Subject: RFR: 8377509: Add licenses for gcc 14.2.0 [v2]
In-Reply-To: <wQ7FUethHCraDe2hLn27x9N0XIyAlt39CaDnGaHdFo4=.4159ceb5-a44f-4f29-8f54-cf8660b2df57@github.com>
References: <wQ7FUethHCraDe2hLn27x9N0XIyAlt39CaDnGaHdFo4=.4159ceb5-a44f-4f29-8f54-cf8660b2df57@github.com>
Message-ID: <fmP6C03nX8WxAQE1cpkInIW2RA-IKcfzcP6bXrHXE-c=.d03c0ab2-2778-4feb-861d-9230c982e05d@github.com>

> Added license file for gcc 14.2.0

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

  Added version

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29661/files
  - new: https://git.openjdk.org/jdk/pull/29661/files/c851bcd2..cec58f63

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

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

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

From forax at openjdk.org  Wed Feb 11 18:59:32 2026
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 11 Feb 2026 18:59:32 GMT
Subject: RFR: 8371656: HashMap.putAll() optimizations [v3]
In-Reply-To: <6ftJ6LFTLKfHfnMYMp9qpITZJUBWgl7-wWWmPDNfNUc=.35eb07c8-eb8e-4794-85da-00770b3d9839@github.com>
References: <L9LdywP8aeyIW9SVHLEsRSUmuaa2vWWQyMW9pTrLtHA=.363bd16c-febb-4028-96b9-a01cdd0d86a2@github.com>
 <ueLHOkfYfe15Ur0RmZDF7j93vGs1x0w48Zib1mZ4rF0=.bba5969c-4504-4921-a6e7-0a1a39395f9b@github.com>
 <g3TjdIsFb1rPWELfUbyonfFEoNC5RRhfWFVL2TcQRk8=.de57ae82-8e40-4925-bf9b-c75aa901d722@github.com>
 <6ftJ6LFTLKfHfnMYMp9qpITZJUBWgl7-wWWmPDNfNUc=.35eb07c8-eb8e-4794-85da-00770b3d9839@github.com>
Message-ID: <Ii5TuxCGGxaPEP4_JFFgzSx3ZOVwWezPG6YYtHs71O4=.9e4bbac6-fc60-4466-ab89-83aa8b6785ab@github.com>

On Wed, 11 Feb 2026 13:47:17 GMT, jengebr <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/HashMap.java line 516:
>> 
>>> 514:      */
>>> 515:     final void putMapEntries(Map<? extends K, ? extends V> m, boolean evict) {
>>> 516:         if (m.getClass() == Collections.UnmodifiableMap.class) {
>> 
>> I would address that issue in a separate bug.
>
> What issue?  This is an integral part of the performance optimization.

Your PR proposes two optimizations,
- HashMap.putAll(HashMap) 
- HashMap.putAll(UnmodifiableMap(HashMap))
 
The former have been done numerous time for other collections, the latter is as far as as know new.

There are several reasons to not wanting to do the latter , on top of my head:
- this is not a symmetrical transformation,
- why only have this optimization on HashMap and not ArrayList and/or ArrayDeque ? 

So It's a separate issue that should be discussed on on the mailist list first.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28243#discussion_r2794933915

From duke at openjdk.org  Wed Feb 11 19:27:37 2026
From: duke at openjdk.org (jengebr)
Date: Wed, 11 Feb 2026 19:27:37 GMT
Subject: RFR: 8371656: HashMap.putAll() optimizations [v3]
In-Reply-To: <Ii5TuxCGGxaPEP4_JFFgzSx3ZOVwWezPG6YYtHs71O4=.9e4bbac6-fc60-4466-ab89-83aa8b6785ab@github.com>
References: <L9LdywP8aeyIW9SVHLEsRSUmuaa2vWWQyMW9pTrLtHA=.363bd16c-febb-4028-96b9-a01cdd0d86a2@github.com>
 <ueLHOkfYfe15Ur0RmZDF7j93vGs1x0w48Zib1mZ4rF0=.bba5969c-4504-4921-a6e7-0a1a39395f9b@github.com>
 <g3TjdIsFb1rPWELfUbyonfFEoNC5RRhfWFVL2TcQRk8=.de57ae82-8e40-4925-bf9b-c75aa901d722@github.com>
 <6ftJ6LFTLKfHfnMYMp9qpITZJUBWgl7-wWWmPDNfNUc=.35eb07c8-eb8e-4794-85da-00770b3d9839@github.com>
 <Ii5TuxCGGxaPEP4_JFFgzSx3ZOVwWezPG6YYtHs71O4=.9e4bbac6-fc60-4466-ab89-83aa8b6785ab@github.com>
Message-ID: <NXtbQwicyI4udHFvmXcD-QWsjiqadwtBfivY3aWQGvE=.f0dec0af-1be0-4801-8b67-2195b3a64102@github.com>

On Wed, 11 Feb 2026 18:57:02 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> What issue?  This is an integral part of the performance optimization.
>
> Your PR proposes two optimizations,
> - HashMap.putAll(HashMap) 
> - HashMap.putAll(UnmodifiableMap(HashMap))
>  
> The former have been done numerous time for other collections, the latter is as far as as know new.
> 
> There are several reasons to not wanting to do the latter , on top of my head:
> - this is not a symmetrical transformation,
> - why only have this optimization on HashMap and not ArrayList and/or ArrayDeque ? 
> 
> So It's a separate issue that should be discussed on on the mailist list first.

Hmm, I disagree, since they are both aspects of improving performance of the target method, HashMap.putMapEntries().  They also both directly attack the underlying JDK JIT limitations described in https://bugs.openjdk.org/browse/JDK-8368292 .  It's a two-piece fix to one problem, and they're covered simultaneously by a single unit test and JMH benchmark.

Open to opinions from others.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28243#discussion_r2795064430

From almatvee at openjdk.org  Wed Feb 11 20:12:19 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 11 Feb 2026 20:12:19 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v10]
In-Reply-To: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
Message-ID: <H389dzZFtboOtIhBr0X0uNsZsE3y4rnw8RW5jBHAsgo=.3f874a1d-5271-4d94-8d30-03d54a64c4e2@github.com>

> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
> - Added test to cover added functionality.
> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.

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

  8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v9]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29260/files
  - new: https://git.openjdk.org/jdk/pull/29260/files/17707867..fc97db8a

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

  Stats: 440 lines in 14 files changed: 235 ins; 74 del; 131 mod
  Patch: https://git.openjdk.org/jdk/pull/29260.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29260/head:pull/29260

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

From almatvee at openjdk.org  Wed Feb 11 20:12:22 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 11 Feb 2026 20:12:22 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v9]
In-Reply-To: <C-8YiKlI0uge38gLDeQRdo7lsr2HBF7PcP0sIkLXLog=.1f55a466-228b-46cc-b444-0bfb21653f9e@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <C-8YiKlI0uge38gLDeQRdo7lsr2HBF7PcP0sIkLXLog=.1f55a466-228b-46cc-b444-0bfb21653f9e@github.com>
Message-ID: <PVLn85Rr8wXWRfm6vb0eIhX0Ui2-S6P2gDF_N7ToOT8=.485b84d6-a5d9-4ca3-8bfd-5b0ab3a7129b@github.com>

On Thu, 5 Feb 2026 02:52:59 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
>> - Added test to cover added functionality.
>> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v8]

8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v9]
- Fixed all latest review comments.
- Added version normalization for RPM, since "release" file version might contain "-" character which is not supported by RPM.

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

PR Comment: https://git.openjdk.org/jdk/pull/29260#issuecomment-3886827069

From dholmes at openjdk.org  Wed Feb 11 20:46:57 2026
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 11 Feb 2026 20:46:57 GMT
Subject: RFR: 8377509: Add licenses for gcc 14.2.0 [v2]
In-Reply-To: <fmP6C03nX8WxAQE1cpkInIW2RA-IKcfzcP6bXrHXE-c=.d03c0ab2-2778-4feb-861d-9230c982e05d@github.com>
References: <wQ7FUethHCraDe2hLn27x9N0XIyAlt39CaDnGaHdFo4=.4159ceb5-a44f-4f29-8f54-cf8660b2df57@github.com>
 <fmP6C03nX8WxAQE1cpkInIW2RA-IKcfzcP6bXrHXE-c=.d03c0ab2-2778-4feb-861d-9230c982e05d@github.com>
Message-ID: <AU3ICo787rDrF1Zi08-WfmIB40X_QAlmrwfQwScTBC8=.4d18e31a-b98a-4e24-be8e-954752bd4052@github.com>

On Wed, 11 Feb 2026 18:12:34 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> Added license file for gcc 14.2.0
>
> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added version

Looks good.

The build system will copy all legal files to the appropriate location in the image.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29661#pullrequestreview-3787371561

From serb at openjdk.org  Wed Feb 11 21:53:43 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 11 Feb 2026 21:53:43 GMT
Subject: RFR: 8377509: Add licenses for gcc 14.2.0 [v2]
In-Reply-To: <AU3ICo787rDrF1Zi08-WfmIB40X_QAlmrwfQwScTBC8=.4d18e31a-b98a-4e24-be8e-954752bd4052@github.com>
References: <wQ7FUethHCraDe2hLn27x9N0XIyAlt39CaDnGaHdFo4=.4159ceb5-a44f-4f29-8f54-cf8660b2df57@github.com>
 <fmP6C03nX8WxAQE1cpkInIW2RA-IKcfzcP6bXrHXE-c=.d03c0ab2-2778-4feb-861d-9230c982e05d@github.com>
 <AU3ICo787rDrF1Zi08-WfmIB40X_QAlmrwfQwScTBC8=.4d18e31a-b98a-4e24-be8e-954752bd4052@github.com>
Message-ID: <IH3fLe4XQE4PUT33h8wnsmQB2B7j6rfotNyFNV7U1QY=.30d30f56-6947-4769-9ac8-b39a8c84639a@github.com>

On Wed, 11 Feb 2026 20:44:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The build system will copy all legal files to the appropriate location in the image.

The makefiles were not updated. How will the build system know what to copy and when?
I just checked the build for this PR:


* C Compiler:     Version 13.3.0 (at /usr/bin/gcc)
* C++ Compiler:   Version 13.3.0 (at /usr/bin/g++)


$ cat ./build/linux-aarch64-server-release/images/jdk/legal/java.base/gcc.md  | more

## GCC - libgcc and libstdc++ 14.2.0

### GNU GENERAL PUBLIC LICENSE v3


This does not seem right.

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

PR Comment: https://git.openjdk.org/jdk/pull/29661#issuecomment-3887416035

From iklam at openjdk.org  Wed Feb 11 22:34:33 2026
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 11 Feb 2026 22:34:33 GMT
Subject: RFR: 8377712: ConstantPool of WeakReferenceKey is not deterministic in
 CDS archive
Message-ID: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>

We are seeing intermittent failures (12 times in Jan 2026) where the CDS archives generated in the JDK build is not deterministic.

The symptom is that (perhaps due to the peculiarity of hash codes and memory addressing??) the constant pool entry for `ReferenceKey<?>` in the `WeakReferenceKey` class is not resolved when the failure happens.

The fix is for the JVM to call a method in `WeakReferenceKey` to force this entry to be resolved.

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

Commit messages:
 - 8370855: ConstantPool of WeakReferenceKey is not deterministic in CDS archive

Changes: https://git.openjdk.org/jdk/pull/29678/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29678&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377712
  Stats: 41 lines in 4 files changed: 39 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29678.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29678/head:pull/29678

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

From liach at openjdk.org  Wed Feb 11 23:17:31 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 11 Feb 2026 23:17:31 GMT
Subject: RFR: 8377712: ConstantPool of WeakReferenceKey is not
 deterministic in CDS archive
In-Reply-To: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
References: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
Message-ID: <Gi6szudENQBJiKJkqYfk6L9wd37r-QZHAWKTBXbAP9k=.cf333683-2ab5-4477-a502-af0e636d6042@github.com>

On Wed, 11 Feb 2026 20:28:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> We are seeing intermittent failures (12 times in Jan 2026) where the CDS archives generated in the JDK build is not deterministic.
> 
> The symptom is that (perhaps due to the peculiarity of hash codes and memory addressing??) the constant pool entry for `ReferenceKey<?>` in the `WeakReferenceKey` class is not resolved when the failure happens.
> 
> The fix is for the JVM to call a method in `WeakReferenceKey` to force this entry to be resolved.

Is there a reason why this only happens for WeakReferenceKey but not SoftReferenceKey?

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

PR Comment: https://git.openjdk.org/jdk/pull/29678#issuecomment-3887762733

From jwilhelm at openjdk.org  Wed Feb 11 23:34:17 2026
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 11 Feb 2026 23:34:17 GMT
Subject: RFR: 8377509: Add licenses for gcc 14.2.0 [v2]
In-Reply-To: <fmP6C03nX8WxAQE1cpkInIW2RA-IKcfzcP6bXrHXE-c=.d03c0ab2-2778-4feb-861d-9230c982e05d@github.com>
References: <wQ7FUethHCraDe2hLn27x9N0XIyAlt39CaDnGaHdFo4=.4159ceb5-a44f-4f29-8f54-cf8660b2df57@github.com>
 <fmP6C03nX8WxAQE1cpkInIW2RA-IKcfzcP6bXrHXE-c=.d03c0ab2-2778-4feb-861d-9230c982e05d@github.com>
Message-ID: <ETC0vYaFxqUyd0C3jF4mgHXE906zaU2yHvonKFfC0Yw=.b45dd9e6-ea2c-401d-b012-5efc6aa5077b@github.com>

On Wed, 11 Feb 2026 18:12:34 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> Added license file for gcc 14.2.0
>
> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added version

Not sure where you found that info, but the builds that are available here on GitHub don't necessarily represent builds made by those who build and distribute JDK binaries. The changes to the makefiles was already done in JDK-8351603.

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

PR Comment: https://git.openjdk.org/jdk/pull/29661#issuecomment-3887806586

From jwilhelm at openjdk.org  Wed Feb 11 23:34:18 2026
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 11 Feb 2026 23:34:18 GMT
Subject: Integrated: 8377509: Add licenses for gcc 14.2.0
In-Reply-To: <wQ7FUethHCraDe2hLn27x9N0XIyAlt39CaDnGaHdFo4=.4159ceb5-a44f-4f29-8f54-cf8660b2df57@github.com>
References: <wQ7FUethHCraDe2hLn27x9N0XIyAlt39CaDnGaHdFo4=.4159ceb5-a44f-4f29-8f54-cf8660b2df57@github.com>
Message-ID: <-QpGIZ_IE2ZiPT5baX9KgFasR1bKsqkrWnEprjojMMg=.741de768-fee8-4861-a794-2c56af4d60b4@github.com>

On Wed, 11 Feb 2026 00:09:48 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Added license file for gcc 14.2.0

This pull request has now been integrated.

Changeset: 961d3284
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/961d32842d7841701a33659493a84b4d2c4d2f82
Stats:     2084 lines in 1 file changed: 2084 ins; 0 del; 0 mod

8377509: Add licenses for gcc 14.2.0

Reviewed-by: dholmes

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

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

From iklam at openjdk.org  Wed Feb 11 23:44:54 2026
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 11 Feb 2026 23:44:54 GMT
Subject: RFR: 8377712: ConstantPool of WeakReferenceKey is not
 deterministic in CDS archive
In-Reply-To: <Gi6szudENQBJiKJkqYfk6L9wd37r-QZHAWKTBXbAP9k=.cf333683-2ab5-4477-a502-af0e636d6042@github.com>
References: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
 <Gi6szudENQBJiKJkqYfk6L9wd37r-QZHAWKTBXbAP9k=.cf333683-2ab5-4477-a502-af0e636d6042@github.com>
Message-ID: <jeVsZy5H1gTeP4n9DzX2gOKqujR98yo3rj2wxjnYzZY=.76633204-a779-42b7-b722-209b670915da@github.com>

On Wed, 11 Feb 2026 23:14:25 GMT, Chen Liang <liach at openjdk.org> wrote:

> Is there a reason why this only happens for WeakReferenceKey but not SoftReferenceKey?

WeakReferenceKey is used in this call stack when creating a CDS archive during the JDK build process:


at java.base/jdk.internal.util.WeakReferenceKey.equals(WeakReferenceKey.java:73)
at java.base/java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1054)
at java.base/java.util.concurrent.ConcurrentHashMap.putIfAbsent(ConcurrentHashMap.java:1558)
at java.base/jdk.internal.util.ReferencedKeyMap.internKey(ReferencedKeyMap.java:460)
at java.base/jdk.internal.util.ReferencedKeyMap.intern(ReferencedKeyMap.java:396)
at java.base/jdk.internal.util.ReferencedKeySet.intern(ReferencedKeySet.java:178)
at java.base/java.lang.invoke.MethodType.makeImpl(MethodType.java:410)
at java.base/java.lang.invoke.MethodType.methodType(MethodType.java:312)
at java.base/java.lang.invoke.MemberName.getMethodOrFieldType(MemberName.java:110)
at java.base/java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:81)
at java.base/java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:130)
at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectFieldCommon(MethodHandles.java:3917)
at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectField(MethodHandles.java:3912)
at java.base/java.lang.invoke.MethodHandles$Lookup.findGetter(MethodHandles.java:2952)
at java.base/java.lang.invoke.ClassSpecializer$Factory.findGetter(ClassSpecializer.java:861)
at java.base/java.lang.invoke.ClassSpecializer$Factory.findGetters(ClassSpecializer.java:870)
at java.base/java.lang.invoke.ClassSpecializer$Factory.linkSpeciesDataToCode(ClassSpecializer.java:898)
at java.base/java.lang.invoke.ClassSpecializer$Factory.loadSpecies(ClassSpecializer.java:505)
at java.base/java.lang.invoke.ClassSpecializer.findSpecies(ClassSpecializer.java:212)
at java.base/java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:406)
at java.base/java.lang.invoke.LambdaForm.createConstantForm(LambdaForm.java:1642)
at java.base/java.lang.invoke.LambdaForm.constantForm(LambdaForm.java:1637)
at java.base/java.lang.invoke.GenerateJLIClassesHelper.generateBasicFormsClassBytes(GenerateJLIClassesHelper.java:467)
at java.base/java.lang.invoke.GenerateJLIClassesHelper$HolderClassBuilder.build(GenerateJLIClassesHelper.java:262)
at java.base/java.lang.invoke.GenerateJLIClassesHelper.generateHolderClasses(GenerateJLIClassesHelper.java:444)
at java.base/java.lang.invoke.MethodHandleImpl$1.generateHolderClasses(MethodHandleImpl.java:1560)
at java.base/jdk.internal.misc.CDS.generateLambdaFormHolderClasses(CDS.java:238)


SoftReferenceKeys are not used:


$ java -Xshare:dump -Xlog:class+init | grep ReferenceKe
Initializing 'jdk/internal/util/StrongReferenceKey'(no method) (0x000000005304c968) by thread "main"
Initializing 'jdk/internal/util/WeakReferenceKey'(no method) (0x000000005304cfb8) by thread "main"

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

PR Comment: https://git.openjdk.org/jdk/pull/29678#issuecomment-3887839876

From serb at openjdk.org  Wed Feb 11 23:54:13 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 11 Feb 2026 23:54:13 GMT
Subject: RFR: 8377509: Add licenses for gcc 14.2.0 [v2]
In-Reply-To: <ETC0vYaFxqUyd0C3jF4mgHXE906zaU2yHvonKFfC0Yw=.b45dd9e6-ea2c-401d-b012-5efc6aa5077b@github.com>
References: <wQ7FUethHCraDe2hLn27x9N0XIyAlt39CaDnGaHdFo4=.4159ceb5-a44f-4f29-8f54-cf8660b2df57@github.com>
 <fmP6C03nX8WxAQE1cpkInIW2RA-IKcfzcP6bXrHXE-c=.d03c0ab2-2778-4feb-861d-9230c982e05d@github.com>
 <ETC0vYaFxqUyd0C3jF4mgHXE906zaU2yHvonKFfC0Yw=.b45dd9e6-ea2c-401d-b012-5efc6aa5077b@github.com>
Message-ID: <gn3CXBBeMEpkp6Np3bXky0blNXEoJrg0LAxlqULzcBE=.97ce9e57-fec6-4717-80b7-d0ab3a45f01d@github.com>

On Wed, 11 Feb 2026 23:29:44 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Not sure where you found that info, but the builds that are available here on GitHub don't necessarily represent builds made by those who build and distribute JDK binaries. The changes to the makefiles was already done in JDK-8351603.

I did not find that; I just built the source from the current PR, and it is obviously using the gcc license for version 14.2.0, even though a different version is being used.

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

PR Comment: https://git.openjdk.org/jdk/pull/29661#issuecomment-3887862157

From liach at openjdk.org  Thu Feb 12 00:08:19 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 12 Feb 2026 00:08:19 GMT
Subject: RFR: 8377712: ConstantPool of WeakReferenceKey is not
 deterministic in CDS archive
In-Reply-To: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
References: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
Message-ID: <IZeHtfFYqqs-gJ2fD4b_S09-DzQuY4zOvd2A_cisE98=.613fc860-a062-4ba0-8c75-af0e0bfd46e3@github.com>

On Wed, 11 Feb 2026 20:28:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> We are seeing intermittent failures (12 times in Jan 2026) where the CDS archives generated in the JDK build is not deterministic.
> 
> The symptom is that (perhaps due to the peculiarity of hash codes and memory addressing??) the constant pool entry for `ReferenceKey<?>` in the `WeakReferenceKey` class is not resolved when the failure happens.
> 
> The fix is for the JVM to call a method in `WeakReferenceKey` to force this entry to be resolved.

I think a better approach might be in ReferencedKeyMap.prepareForAOTCache, after

        for (ReferenceKey<K> key : map.keySet()) {
            Object referent = key.get();

inject a call `key.equals(new StrongReferenceKey(referent))`, so that we hit the instanceof. What do you think? This code should be less reliant to weird translation hacks and requires less VM hacks.

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

PR Comment: https://git.openjdk.org/jdk/pull/29678#issuecomment-3887902436

From liach at openjdk.org  Thu Feb 12 00:13:37 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 12 Feb 2026 00:13:37 GMT
Subject: RFR: 8377712: ConstantPool of WeakReferenceKey is not
 deterministic in CDS archive
In-Reply-To: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
References: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
Message-ID: <SDGmoxp-zjwLWoCNFkWxiXyLbfBengM6_vsJ5Ghls6A=.e7154b45-f796-46d3-8818-6e3576b36277@github.com>

On Wed, 11 Feb 2026 20:28:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> We are seeing intermittent failures (12 times in Jan 2026) where the CDS archives generated in the JDK build is not deterministic.
> 
> The symptom is that (perhaps due to the peculiarity of hash codes and memory addressing??) the constant pool entry for `ReferenceKey<?>` in the `WeakReferenceKey` class is not resolved when the failure happens.
> 
> The fix is for the JVM to call a method in `WeakReferenceKey` to force this entry to be resolved.

A better approach might be as simple as calling `MethodType.methodType(` to retrieve an existing method type, maybe `MethodType.methodType(void.class)` would be sufficient, in `MethodType::assemblySetup`.

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

PR Comment: https://git.openjdk.org/jdk/pull/29678#issuecomment-3887917296

From almatvee at openjdk.org  Thu Feb 12 01:03:49 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 12 Feb 2026 01:03:49 GMT
Subject: RFR: 8377629: jpackage: Tighten up output validation in tests
In-Reply-To: <YC1d5DOWUhhgexyqfObG14ud4LeOdD6oDKwlAgKZWyI=.49769a63-3d02-47bc-92fa-27295c3e95e9@github.com>
References: <YC1d5DOWUhhgexyqfObG14ud4LeOdD6oDKwlAgKZWyI=.49769a63-3d02-47bc-92fa-27295c3e95e9@github.com>
Message-ID: <5kzAuF9DgKuyi6TVL5wAJOcFiBsovkOvANNYhfIdAeM=.92583281-3bd5-405d-832b-39b6eeaf4c2d@github.com>

On Tue, 10 Feb 2026 03:04:18 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Tighten up jpackage's output validation.
> 
>  - Support separate validation of jpackage's stdout and stderr. Previously, validation was applied to the merged stdout and stderr output, so errors were not detected when jpackage expected to write to stdout but wrote to stderr instead
> - 99% of test cases in ErrorTest will check that jpackage's stderr contains exact expected error messages and doesn't contain additional text lines
> - Use `String.equals()` instead of `String.contains()` when validating strings from jpackage string bundles in jpackage output
> 
> Replace TKit.TextStreamVerifier.Group class with a more capable JPackageOutputValidator.
> 
> Fix revealed issues:
>  - jdk.jpackage.internal.AppImageSigner: use `Log.fatalError()` to report a fatal signing error instead of `Log.info()`. This change directs signing error messages to stderr, where all warnings and errors belong, rather than stdout.
>  - On macOS, when the value of the "--app-image" option is not a directory, jpackage used to report two errors: that the value is not a directory and that it is not a macOS bundle. This behavior has changed: jpackage will report only the first error. If the value of the "--app-image" option is a directory that is not a valid macOS bundle, jpackage will fail with the corresponding error.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29644#pullrequestreview-3788232297

From xgong at openjdk.org  Thu Feb 12 02:15:14 2026
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 12 Feb 2026 02:15:14 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating
 broadcasted inputs [v2]
In-Reply-To: <PNW4gxucHTNbKyn34Kdbm4k4GU881SvrVshRPDU9SXA=.3868b71e-95a7-42ea-9159-4a8f08f610ab@github.com>
References: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
 <PNW4gxucHTNbKyn34Kdbm4k4GU881SvrVshRPDU9SXA=.3868b71e-95a7-42ea-9159-4a8f08f610ab@github.com>
Message-ID: <9Y6VgSySWfpWqZPXfXVVOrsUtaKgIvsXS2-G35yP00I=.b7c5da2b-3350-49fd-b62d-17d68fbdcaa0@github.com>

On Tue, 10 Feb 2026 05:34:06 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch optimizes SIMD kernels making heavy use of broadcasted inputs through following reassociating ideal transformations.
>> 
>> 
>>  VectorOperation (VectorBroadcast INP1,  VectorBroadcast INP2) => 
>>                             VectorBroadcast (ScalarOpration INP1, INP2)
>> 
>>  VectorOperation (VectorBroadcast INP1) (VectorOperation (VectorBroadcast INP2) INP3) => 
>>                              VectorOperation INP3 (VectorOperation (VectorBroadcast INP1) (VectorOperation INP2))
>> 
>> 
>> The idea is to push broadcasts across the vector operation and replace the vector with an equivalent, cheaper scalar variant.  Currently, patch handles most common vector operations.
>> 
>> Following are the performance number of benchmark included with this patch on latest generation x86 targets:- 
>> 
>> **AMD Turin (2.1GHz)**
>> <img width="1122" height="355" alt="image" src="https://github.com/user-attachments/assets/3f5087bf-0e14-4c56-b0c2-3d23253bad54" />
>> 
>> **Intel Granite Rapids (2.1GHz)**
>> <img width="1105" height="325" alt="image" src="https://github.com/user-attachments/assets/c8481f86-4db2-4c4e-bd65-51542c59fe63" />
>> 
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions

src/hotspot/share/opto/vectornode.cpp line 1303:

> 1301: //
> 1302: Node* VectorNode::reassociate_vector_operation(PhaseGVN* phase) {
> 1303:   if (is_commutative_vector_operation(Opcode()) && is_integral_type(vect_type()->element_basic_type())) {

Suggestions

  // Only integral vector operations support reassociate ...
  if (is_integral_type(vect_type()->element_basic_type())) {
    return nullptr;
  }

  // Only commutative vector operations supports ...
  if (!is_commutative_vector_operation(Opcode()) {
    return nullptr;
  }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2796430943

From xgong at openjdk.org  Thu Feb 12 02:22:59 2026
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 12 Feb 2026 02:22:59 GMT
Subject: RFR: 8372136: VectorAPI: Refactor subword gather load API java
 implementation [v3]
In-Reply-To: <SEUxzD0msReThVgeMRw5uapRw-UIjewDJP27RAt3ZzY=.991e5f58-347e-44fe-92db-b56576aab780@github.com>
References: <SEUxzD0msReThVgeMRw5uapRw-UIjewDJP27RAt3ZzY=.991e5f58-347e-44fe-92db-b56576aab780@github.com>
Message-ID: <vMKLDgygWhi4_kt6OIEZV94i0-aPGBh0lh3aifH8MVY=.55b5b806-0e9e-430d-9c24-0d52af052d3f@github.com>

> The current subword (`byte`/`short`) gather load API implementation is not well-suited for platforms that provide native vector instructions for these operations. As **discussed in PR [1]**, we'd like to re-implement these APIs with a **unified cross-platform** solution.
> 
> The main idea is to re-implement the API at Java-level, by performing multiple sub-gather operations. Each sub-gather operation loads a portion of elements using a specific index vector by calling the HotSpot intrinsic API. The partial results are then merged using vector `slice` and `or` operations. This design simplifies the VM compiler intrinsic implementation and better aligns with the Vector API design principles.
> 
> Key changes:
> 1. Re-implement the subword gather load API at the Java level. The HotSpot intrinsic `VectorSupport.loadWithMap` is simplified by reducing the vector index parameters from four (vix1-vix4) to a single parameter.
> 2. Adjust the compiler intrinsic implementation to support the new Java API, including updates to the x86 backend implementation.
> 
> The performance impact varies across different scenarios on X86. I tested the performance with different AVX levels on an X86 machine that supports AVX512. To achieve optimal performance, I also **applied PR [2]**, which improves the performance of the **`slice()`** API on X86. Following is the summarized performance gains, where:
> 
> - "non masked" means the gather operation is not the masked gather API.
> - "masked" means the gather operation is the masked gather API.
> - "1 gather cases" means the gather API is implemented with a single gather operation. E.g. Load `Short128Vector` with `MaxVectorSize=256`.
> - "2 gather cases" means the gather API is implemented with 2 parts of gather operations. E.g. Load `Short256Vector` with `MaxVectorSize=256`.
> - "4 gather cases" means the gather API is implemented with 4 parts of gather operations. E.g. Load `Byte256Vector` with `MaxVectorSize=256`.
> - "Un-intrinsified" means the gather operation is not supported to be intrinsified by hotspot. E.g. Load `Byte512Vector` with `MaxVectorSize=256`. The singificant performance uplifts comes from the Java-level changes which removes the vector index generation and range checks for such cases.
> 
> 
> ----------------------------------------------------------------------------
>                |          UseAVX=3           |          UseAVX=2           |
>                |-----------------------------|-----------------------------|
>                |  non maske...

Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Update copyright year
 - Merge jdk:master into JDK-8372136
 - Merge 'jdk:master' into JDK-8372136
 - 8372136: VectorAPI: Refactor subword gather load API java implementation

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

Changes: https://git.openjdk.org/jdk/pull/28520/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28520&range=02
  Stats: 559 lines in 13 files changed: 383 ins; 78 del; 98 mod
  Patch: https://git.openjdk.org/jdk/pull/28520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28520/head:pull/28520

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

From duke at openjdk.org  Thu Feb 12 03:08:06 2026
From: duke at openjdk.org (duke)
Date: Thu, 12 Feb 2026 03:08:06 GMT
Subject: Withdrawn: 8309748: Improve host selection in `External
 Specifications` page
In-Reply-To: <VRQeGKu9h86k5u3kjRt83_F3Ig42hAjgx8Es7rQDrR4=.12c9ad24-a8d1-4ce9-9e49-3dcb701007b7@github.com>
References: <VRQeGKu9h86k5u3kjRt83_F3Ig42hAjgx8Es7rQDrR4=.12c9ad24-a8d1-4ce9-9e49-3dcb701007b7@github.com>
Message-ID: <SpWlhN2keFDju6QWVP3pURt0zq_Ygsc0tNiF4-NQqfk=.0299dacb-f82b-4587-9bbc-5be5bbd4c64e@github.com>

On Wed, 17 Dec 2025 08:45:01 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to improve selection by host name in the External Specifications page. After trying a list of checkboxes as used in the API summary pages and finding it not a suitable solution, I found that a select/dropdown menu works best for this page. 
> 
>  - [New external specs page](https://cr.openjdk.org/~hannesw/8309748/api.00/external-specs.html)
>  - [Old external specs page](https://docs.oracle.com/en/java/javase/25/docs/api/external-specs.html) for comparsion
> 
> I also updated `@spec` tags in `java.lang.Character` to point to `www.unicode.org` rather than `unicode.org` to avoid a  `unicode.org` entry in the host list (other `@spec` tags use the `www.unicode.org` host name). The short `unicode.org` URL is still used elsewhere in the `java.lang.Character` class, I can update those links to the canonical host name as well if desired.

This pull request has been closed without being integrated.

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

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

From iklam at openjdk.org  Thu Feb 12 03:15:46 2026
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 12 Feb 2026 03:15:46 GMT
Subject: RFR: 8377712: ConstantPool of WeakReferenceKey is not
 deterministic in CDS archive
In-Reply-To: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
References: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
Message-ID: <g2oTe1atOJv1JH969MTj6PSFnBc5r9uKfttUQzwv5EA=.e1f5f6f2-e5ec-4ea7-b451-741cf6af6869@github.com>

On Wed, 11 Feb 2026 20:28:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> We are seeing intermittent failures (12 times in Jan 2026) where the CDS archives generated in the JDK build is not deterministic.
> 
> The symptom is that (perhaps due to the peculiarity of hash codes and memory addressing??) the constant pool entry for `ReferenceKey<?>` in the `WeakReferenceKey` class is not resolved when the failure happens.
> 
> The fix is for the JVM to call a method in `WeakReferenceKey` to force this entry to be resolved.

> I think a better approach might be in ReferencedKeyMap.prepareForAOTCache, after
> 
> ```
>         for (ReferenceKey<K> key : map.keySet()) {
>             Object referent = key.get();
> ```
> 
> inject a call `key.equals(new StrongReferenceKey(referent))`, so that we hit the instanceof. What do you think? This code should be less reliant to weird translation hacks and requires less VM hacks.

> A better approach might be as simple as calling `MethodType.methodType()` to retrieve an existing method type, maybe `MethodType.methodType(void.class)` would be sufficient, in `MethodType::assemblySetup`.

`ReferencedKeyMap.prepareForAOTCache()` is only called only when `AOTClassLinking` is true. However, when creating the default CDS archives, `AOTClassLinking` is false.

Also, I am not sure if we should insert unnecessary code to try to achieve some unobvious side effect.

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

PR Comment: https://git.openjdk.org/jdk/pull/29678#issuecomment-3888436219

From kshiroko at openjdk.org  Thu Feb 12 03:29:01 2026
From: kshiroko at openjdk.org (Kirill Shirokov)
Date: Thu, 12 Feb 2026 03:29:01 GMT
Subject: RFR: 8377729: Running jtreg tests with -agent... option causes some
 tests to fail due to duplicate -agent options provided to a subprocess
Message-ID: <Xx7VPlNQy-Svo7fkKo71gYLrSJ4nTxyyGnwEpXyfeyQ=.4cdbed9d-b09c-4c74-8a0e-1c27e620a825@github.com>

The fix removes duplicate `-agent...` and `-javaagent:...` options from test subprocess command line, thus allowing to run jtreg tests with agents that should be specified only once.

The fix tested manually:


$ make test JTREG="VERBOSE=summary,fail,error" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
   jtreg:test/jdk/sun/tools/jstack/DeadlockDetectionTest.java
                                                         1     1     0     0     0
   jtreg:test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java
                                                         1     1     0     0     0
   jtreg:test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java
                                                         1     1     0     0     0
==============================
TEST SUCCESS

$ make test JTREG="VERBOSE=summary,fail,error;JAVA_OPTIONS=-agentpath.../async-profiler-binaries/lib/libasyncProfiler.dylib=start,event=cpu,cstack=vm,loglevel=none,flat,file=/dev/null" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
   jtreg:test/jdk/sun/tools/jstack/DeadlockDetectionTest.java
>>                                                       1     0     1     0     0 <<
   jtreg:test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java
>>                                                       1     0     1     0     0 <<
   jtreg:test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java
>>                                                       1     0     1     0     0 <<
==============================
TEST FAILURE

$ make test JTREG="VERBOSE=summary,fail,error;VM_OPTIONS=-agentpath:.../async-profiler-binaries/lib/libasyncProfiler.dylib=start,event=cpu,cstack=vm,loglevel=none,flat,file=/dev/null" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"

(same errors)

With the fix everything above passes.

Tested on linux-aarch64, macos-aarch64 using specific tests + tier1 suite without additional options.

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

Commit messages:
 - 8377729: Running jtreg tests with -agent... option causes some tests to fail due to duplicate -agent options provided to a subprocess

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

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

From lmesnik at openjdk.org  Thu Feb 12 04:54:06 2026
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 12 Feb 2026 04:54:06 GMT
Subject: RFR: 8377729: Running jtreg tests with -agent... option causes
 some tests to fail due to duplicate -agent options provided to a subprocess
In-Reply-To: <Xx7VPlNQy-Svo7fkKo71gYLrSJ4nTxyyGnwEpXyfeyQ=.4cdbed9d-b09c-4c74-8a0e-1c27e620a825@github.com>
References: <Xx7VPlNQy-Svo7fkKo71gYLrSJ4nTxyyGnwEpXyfeyQ=.4cdbed9d-b09c-4c74-8a0e-1c27e620a825@github.com>
Message-ID: <CsMq1ha2NZrZCz_cACsxF0SSi0FSQieUeXp9pJ0PCdQ=.6c9137eb-c31b-41f4-b670-b0ca626cf6ca@github.com>

On Thu, 12 Feb 2026 03:22:57 GMT, Kirill Shirokov <kshiroko at openjdk.org> wrote:

> The fix removes duplicate `-agent...` and `-javaagent:...` options from test subprocess command line, thus allowing to run jtreg tests with agents that should be specified only once.
> 
> The fix tested manually:
> 
> 
> $ make test JTREG="VERBOSE=summary,fail,error" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>    jtreg:test/jdk/sun/tools/jstack/DeadlockDetectionTest.java
>                                                          1     1     0     0     0
>    jtreg:test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java
>                                                          1     1     0     0     0
>    jtreg:test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java
>                                                          1     1     0     0     0
> ==============================
> TEST SUCCESS
> 
> $ make test JTREG="VERBOSE=summary,fail,error;JAVA_OPTIONS=-agentpath.../async-profiler-binaries/lib/libasyncProfiler.dylib=start,event=cpu,cstack=vm,loglevel=none,flat,file=/dev/null" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>    jtreg:test/jdk/sun/tools/jstack/DeadlockDetectionTest.java
>>>                                                       1     0     1     0     0 <<
>    jtreg:test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java
>>>                                                       1     0     1     0     0 <<
>    jtreg:test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java
>>>                                                       1     0     1     0     0 <<
> ==============================
> TEST FAILURE
> 
> $ make test JTREG="VERBOSE=summary,fail,error;VM_OPTIONS=-agentpath:.../async-profiler-binaries/lib/libasyncProfiler.dylib=start,event=cpu,cstack=vm,loglevel=none,flat,file=/dev/null" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"
> 
> (same errors)
> 
> With th...

Changes requested by lmesnik (Reviewer).

test/lib/jdk/test/lib/apps/LingeredApp.java line 49:

> 47: import jdk.test.lib.Utils;
> 48: import jdk.test.lib.process.OutputBuffer;
> 49: import jdk.test.lib.process.ProcessTools;

I don't think that it is good idea to deduplicate options in ProcessTools.

Better to fix the tests that duplicate options rather then try to deduplicate all options.

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

PR Review: https://git.openjdk.org/jdk/pull/29684#pullrequestreview-3788723530
PR Review Comment: https://git.openjdk.org/jdk/pull/29684#discussion_r2796760237

From jbhateja at openjdk.org  Thu Feb 12 05:10:09 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 12 Feb 2026 05:10:09 GMT
Subject: RFR: 8376794: Enable copy and mismatch Partial Inlining for AMD
 AVX512 targets
In-Reply-To: <E708AlnV8T1i1fLw0e8gQX9sLEw46Ssy5IGZ7gxuxtA=.16133384-0992-4636-abca-d2913e78cfdb@github.com>
References: <LIdQi9c0pTKY9GZJoZVnpKC7DRYZYaATzujDQTPSyvY=.b0d8ee2f-bc7b-4174-b7f4-6e3cddc4721d@github.com>
 <E708AlnV8T1i1fLw0e8gQX9sLEw46Ssy5IGZ7gxuxtA=.16133384-0992-4636-abca-d2913e78cfdb@github.com>
Message-ID: <AcT7RPx4cHA9xqjZXBjZZpi6cbBOEIcfMwQgwx3KzV4=.ab9ab4e7-7c23-4e25-abfe-64fca6552844@github.com>

On Tue, 10 Feb 2026 09:57:48 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Partial in-lining handles copy and mismatch for small array sizes less than -XX:ArrayOperationPartialInlineSize bytes through JIT code rather than calling optimized stubs thereby saving costly call overhead.
>> 
>> Enabling partial in-lining optimization for AMD EPYC servers supporting AVX-512 feature.
>> 
>> Following are the performance numbers on Turin at fixed frequency of 2.1GHz
>> 
>> <img width="440" height="440" alt="image" src="https://github.com/user-attachments/assets/14b55ee3-b65c-4247-8739-67f1b94dceb4" />
>> <img width="440" height="300" alt="image" src="https://github.com/user-attachments/assets/c00d6443-45a2-4277-961d-580ceea5da88" />
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Sure, I'll report back once it passed.

Hi @TobiHartmann , Please let me know if the results of your test run are clean.

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

PR Comment: https://git.openjdk.org/jdk/pull/29519#issuecomment-3888712425

From liach at openjdk.org  Thu Feb 12 05:15:53 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 12 Feb 2026 05:15:53 GMT
Subject: RFR: 8377712: ConstantPool of WeakReferenceKey is not
 deterministic in CDS archive
In-Reply-To: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
References: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
Message-ID: <ajDsR2JraDfxMU3UwfiVM83wfrqGGV1OO94fn-ouusc=.9da2d389-6a24-4e1e-8a7d-dfe96b117ebf@github.com>

On Wed, 11 Feb 2026 20:28:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> We are seeing intermittent failures (12 times in Jan 2026) where the CDS archives generated in the JDK build is not deterministic.
> 
> The symptom is that (perhaps due to the peculiarity of hash codes and memory addressing??) the constant pool entry for `ReferenceKey<?>` in the `WeakReferenceKey` class is not resolved when the failure happens.
> 
> The fix is for the JVM to call a method in `WeakReferenceKey` to force this entry to be resolved.

Then I think we should probably patch GenerateJLIClassesHelper to call `MethodType.methodType(void.class)` (or any other method type) twice somewhere. The 2nd call ensures there will be a method type lookup, which covers the missing code path that causes the problem.

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

PR Comment: https://git.openjdk.org/jdk/pull/29678#issuecomment-3888726353

From jbhateja at openjdk.org  Thu Feb 12 05:18:36 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 12 Feb 2026 05:18:36 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating
 broadcasted inputs [v3]
In-Reply-To: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
References: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
Message-ID: <JO48amlT-BaATLTxZv05xSRGyz-UcGM0jgrCDXSHRwY=.0b1ca7d4-0e93-4a1e-af41-0bb6ae906998@github.com>

> Hi all,
> 
> This patch optimizes SIMD kernels making heavy use of broadcasted inputs through following reassociating ideal transformations.
> 
> 
>  VectorOperation (VectorBroadcast INP1,  VectorBroadcast INP2) => 
>                             VectorBroadcast (ScalarOpration INP1, INP2)
> 
>  VectorOperation (VectorBroadcast INP1) (VectorOperation (VectorBroadcast INP2) INP3) => 
>                              VectorOperation INP3 (VectorOperation (VectorBroadcast INP1) (VectorOperation INP2))
> 
> 
> The idea is to push broadcasts across the vector operation and replace the vector with an equivalent, cheaper scalar variant.  Currently, patch handles most common vector operations.
> 
> Following are the performance number of benchmark included with this patch on latest generation x86 targets:- 
> 
> **AMD Turin (2.1GHz)**
> <img width="1122" height="355" alt="image" src="https://github.com/user-attachments/assets/3f5087bf-0e14-4c56-b0c2-3d23253bad54" />
> 
> **Intel Granite Rapids (2.1GHz)**
> <img width="1105" height="325" alt="image" src="https://github.com/user-attachments/assets/c8481f86-4db2-4c4e-bd65-51542c59fe63" />
> 
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

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

  Review comments resolution

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25617/files
  - new: https://git.openjdk.org/jdk/pull/25617/files/2a044457..c28e1d60

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

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

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

From jbhateja at openjdk.org  Thu Feb 12 05:18:38 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 12 Feb 2026 05:18:38 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating
 broadcasted inputs [v2]
In-Reply-To: <9Y6VgSySWfpWqZPXfXVVOrsUtaKgIvsXS2-G35yP00I=.b7c5da2b-3350-49fd-b62d-17d68fbdcaa0@github.com>
References: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
 <PNW4gxucHTNbKyn34Kdbm4k4GU881SvrVshRPDU9SXA=.3868b71e-95a7-42ea-9159-4a8f08f610ab@github.com>
 <9Y6VgSySWfpWqZPXfXVVOrsUtaKgIvsXS2-G35yP00I=.b7c5da2b-3350-49fd-b62d-17d68fbdcaa0@github.com>
Message-ID: <Gk6dcjT7vYuLGpPq3GsjigMH3d1iPr_KQfZgRQFxIDs=.a2458f21-664b-48a9-9407-d0b7ee6a4ae0@github.com>

On Thu, 12 Feb 2026 02:11:04 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions
>
> src/hotspot/share/opto/vectornode.cpp line 1303:
> 
>> 1301: //
>> 1302: Node* VectorNode::reassociate_vector_operation(PhaseGVN* phase) {
>> 1303:   if (is_commutative_vector_operation(Opcode()) && is_integral_type(vect_type()->element_basic_type())) {
> 
> Suggestions
> 
>   // Only integral vector operations support reassociate ...
>   if (is_integral_type(vect_type()->element_basic_type())) {
>     return nullptr;
>   }
> 
>   // Only commutative vector operations supports ...
>   if (!is_commutative_vector_operation(Opcode()) {
>     return nullptr;
>   }

Addressed!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2796806875

From amitkumar at openjdk.org  Thu Feb 12 05:19:54 2026
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 12 Feb 2026 05:19:54 GMT
Subject: RFR: 8377035: [s390x] Disable JSR166 test cases which uses virtual
 threads [v3]
In-Reply-To: <JvK7mMMqogV9IOg0R3WOmG3gamy6GnjhVhpvHTrBwYM=.e9b9ca79-0b51-4ce9-8fa1-6c30a46713fb@github.com>
References: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
 <JvK7mMMqogV9IOg0R3WOmG3gamy6GnjhVhpvHTrBwYM=.e9b9ca79-0b51-4ce9-8fa1-6c30a46713fb@github.com>
Message-ID: <l3ssLghX9y8yy2Og4fiPAjroPV_XJt5xkb58RUjRUDk=.550766e6-8835-424e-9846-36c9abd40a99@github.com>

On Wed, 11 Feb 2026 10:10:36 GMT, Harshit470250 <duke at openjdk.org> wrote:

>> ReentrantReadWriteLock20Test.java is failing on s390 due to virtual threads which are not yet implemented on s390. 
>> SynchronousQueue20Test.java also uses virtual thread so I am also disabling it.
>
> Harshit470250 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   build platform library

Marked as reviewed by amitkumar (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/29555#pullrequestreview-3788774392

From duke at openjdk.org  Thu Feb 12 05:22:52 2026
From: duke at openjdk.org (duke)
Date: Thu, 12 Feb 2026 05:22:52 GMT
Subject: RFR: 8377035: [s390x] Disable JSR166 test cases which uses virtual
 threads [v3]
In-Reply-To: <JvK7mMMqogV9IOg0R3WOmG3gamy6GnjhVhpvHTrBwYM=.e9b9ca79-0b51-4ce9-8fa1-6c30a46713fb@github.com>
References: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
 <JvK7mMMqogV9IOg0R3WOmG3gamy6GnjhVhpvHTrBwYM=.e9b9ca79-0b51-4ce9-8fa1-6c30a46713fb@github.com>
Message-ID: <ncNbiRA2cgL1MEHAE4z0JsvkR3G_qNDAmyBpaOMPAt4=.2d5c66cc-c240-450e-80fb-8a34293f170c@github.com>

On Wed, 11 Feb 2026 10:10:36 GMT, Harshit470250 <duke at openjdk.org> wrote:

>> ReentrantReadWriteLock20Test.java is failing on s390 due to virtual threads which are not yet implemented on s390. 
>> SynchronousQueue20Test.java also uses virtual thread so I am also disabling it.
>
> Harshit470250 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   build platform library

@Harshit470250 
Your change (at version 6ab2d8bf01485f0ec4d5faa4bae23528f655798c) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/29555#issuecomment-3888743085

From iklam at openjdk.org  Thu Feb 12 05:54:17 2026
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 12 Feb 2026 05:54:17 GMT
Subject: RFR: 8377712: ConstantPool of WeakReferenceKey is not
 deterministic in CDS archive
In-Reply-To: <ajDsR2JraDfxMU3UwfiVM83wfrqGGV1OO94fn-ouusc=.9da2d389-6a24-4e1e-8a7d-dfe96b117ebf@github.com>
References: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
 <ajDsR2JraDfxMU3UwfiVM83wfrqGGV1OO94fn-ouusc=.9da2d389-6a24-4e1e-8a7d-dfe96b117ebf@github.com>
Message-ID: <aqXkAvS94cs4GGAhb9tLEUwNgRjWNFy785k7bCPM-ms=.da501f8a-860f-4621-9d02-b206baa96439@github.com>

On Thu, 12 Feb 2026 05:13:03 GMT, Chen Liang <liach at openjdk.org> wrote:

> Then I think we should probably patch GenerateJLIClassesHelper to call `MethodType.methodType(void.class)` (or any other method type) twice somewhere. The 2nd call ensures there will be a method type lookup, which covers the missing code path that causes the problem.

The actions in WeakReferenceKey.equals() is many levels away from `MethodType.methodType()`. Doing this is fragile if the implementation changes at any of those levels. It's also "unnecessary code that has an unobvious side effect".

That's why I prefer to address the problem directly, as close to its source as possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/29678#issuecomment-3888819154

From thartmann at openjdk.org  Thu Feb 12 06:45:07 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 12 Feb 2026 06:45:07 GMT
Subject: RFR: 8376794: Enable copy and mismatch Partial Inlining for AMD
 AVX512 targets
In-Reply-To: <LIdQi9c0pTKY9GZJoZVnpKC7DRYZYaATzujDQTPSyvY=.b0d8ee2f-bc7b-4174-b7f4-6e3cddc4721d@github.com>
References: <LIdQi9c0pTKY9GZJoZVnpKC7DRYZYaATzujDQTPSyvY=.b0d8ee2f-bc7b-4174-b7f4-6e3cddc4721d@github.com>
Message-ID: <ssW8ph2eSdOx5D8Y6lbn9JGqMX_ejbqjOi0djC1Yi3s=.9a2ac944-9d31-4eca-be1a-b444f66abbe9@github.com>

On Mon, 2 Feb 2026 10:37:16 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Partial in-lining handles copy and mismatch for small array sizes less than -XX:ArrayOperationPartialInlineSize bytes through JIT code rather than calling optimized stubs thereby saving costly call overhead.
> 
> Enabling partial in-lining optimization for AMD EPYC servers supporting AVX-512 feature.
> 
> Following are the performance numbers on Turin at fixed frequency of 2.1GHz
> 
> <img width="440" height="440" alt="image" src="https://github.com/user-attachments/assets/14b55ee3-b65c-4247-8739-67f1b94dceb4" />
> <img width="440" height="300" alt="image" src="https://github.com/user-attachments/assets/c00d6443-45a2-4277-961d-580ceea5da88" />
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Marked as reviewed by thartmann (Reviewer).

Testing is all clean (except for some AArch64 specific targets that wouldn't be affected by this anyway).

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

PR Review: https://git.openjdk.org/jdk/pull/29519#pullrequestreview-3788986414
PR Comment: https://git.openjdk.org/jdk/pull/29519#issuecomment-3888970394

From alanb at openjdk.org  Thu Feb 12 06:48:01 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Feb 2026 06:48:01 GMT
Subject: RFR: 8377035: [s390x] Disable JSR166 test cases which uses virtual
 threads [v3]
In-Reply-To: <JvK7mMMqogV9IOg0R3WOmG3gamy6GnjhVhpvHTrBwYM=.e9b9ca79-0b51-4ce9-8fa1-6c30a46713fb@github.com>
References: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
 <JvK7mMMqogV9IOg0R3WOmG3gamy6GnjhVhpvHTrBwYM=.e9b9ca79-0b51-4ce9-8fa1-6c30a46713fb@github.com>
Message-ID: <KkDb8h1I6BftuKjq56wXSTBixVBknpEUrkwZONrrNxE=.b8e1db3b-895a-4110-bd4a-ab7de0615040@github.com>

On Wed, 11 Feb 2026 10:10:36 GMT, Harshit470250 <duke at openjdk.org> wrote:

>> ReentrantReadWriteLock20Test.java is failing on s390 due to virtual threads which are not yet implemented on s390. 
>> SynchronousQueue20Test.java also uses virtual thread so I am also disabling it.
>
> Harshit470250 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   build platform library

test/jdk/java/util/concurrent/tck/JSR166TestCase.java line 634:

> 632:             };
> 633: 
> 634:             if (!Platform.isS390x()) {

I assume the intent is to remove this patch once the s390x port is further along. In that case maybe leave the above as is and use if (`Platform.isS390x())` to set java20TestClassNames to the subset that can be run on that platform.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29555#discussion_r2797045410

From jbhateja at openjdk.org  Thu Feb 12 06:54:53 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 12 Feb 2026 06:54:53 GMT
Subject: RFR: 8376794: Enable copy and mismatch Partial Inlining for AMD
 AVX512 targets
In-Reply-To: <-6CdVqRlf2pPkhmumd3J6mSCeZDeW8lUpCkvxVDUJbM=.2dea83f9-10b9-4918-9a7c-4178e1a7df92@github.com>
References: <LIdQi9c0pTKY9GZJoZVnpKC7DRYZYaATzujDQTPSyvY=.b0d8ee2f-bc7b-4174-b7f4-6e3cddc4721d@github.com>
 <-6CdVqRlf2pPkhmumd3J6mSCeZDeW8lUpCkvxVDUJbM=.2dea83f9-10b9-4918-9a7c-4178e1a7df92@github.com>
Message-ID: <uG9FmD8jxfF6NDQv-VuMDS55IkeM46MjyoJV8KN4uAA=.31a27feb-47bf-4f24-95b8-815438165f19@github.com>

On Mon, 9 Feb 2026 21:14:50 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Partial in-lining handles copy and mismatch for small array sizes less than -XX:ArrayOperationPartialInlineSize bytes through JIT code rather than calling optimized stubs thereby saving costly call overhead.
>> 
>> Enabling partial in-lining optimization for AMD EPYC servers supporting AVX-512 feature.
>> 
>> Following are the performance numbers on Turin at fixed frequency of 2.1GHz
>> 
>> <img width="440" height="440" alt="image" src="https://github.com/user-attachments/assets/14b55ee3-b65c-4247-8739-67f1b94dceb4" />
>> <img width="440" height="300" alt="image" src="https://github.com/user-attachments/assets/c00d6443-45a2-4277-961d-580ceea5da88" />
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Looks good to me.

Thanks @sviswa7  and @TobiHartmann  for review and approval

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29519#issuecomment-3888998604

From jbhateja at openjdk.org  Thu Feb 12 06:54:54 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 12 Feb 2026 06:54:54 GMT
Subject: Integrated: 8376794: Enable copy and mismatch Partial Inlining for AMD
 AVX512 targets
In-Reply-To: <LIdQi9c0pTKY9GZJoZVnpKC7DRYZYaATzujDQTPSyvY=.b0d8ee2f-bc7b-4174-b7f4-6e3cddc4721d@github.com>
References: <LIdQi9c0pTKY9GZJoZVnpKC7DRYZYaATzujDQTPSyvY=.b0d8ee2f-bc7b-4174-b7f4-6e3cddc4721d@github.com>
Message-ID: <gJLLNaRJf4CQbTNIS132ZsV-GF-vv7WobVyvklcLMoU=.fac25b40-65c4-4a34-a70c-84e7757643c2@github.com>

On Mon, 2 Feb 2026 10:37:16 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Partial in-lining handles copy and mismatch for small array sizes less than -XX:ArrayOperationPartialInlineSize bytes through JIT code rather than calling optimized stubs thereby saving costly call overhead.
> 
> Enabling partial in-lining optimization for AMD EPYC servers supporting AVX-512 feature.
> 
> Following are the performance numbers on Turin at fixed frequency of 2.1GHz
> 
> <img width="440" height="440" alt="image" src="https://github.com/user-attachments/assets/14b55ee3-b65c-4247-8739-67f1b94dceb4" />
> <img width="440" height="300" alt="image" src="https://github.com/user-attachments/assets/c00d6443-45a2-4277-961d-580ceea5da88" />
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

This pull request has now been integrated.

Changeset: 6abb29cc
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6abb29cc07e033e9a747b5a8a62e831c8f629c14
Stats:     75 lines in 2 files changed: 47 ins; 5 del; 23 mod

8376794: Enable copy and mismatch Partial Inlining for AMD AVX512 targets

Reviewed-by: sviswanathan, thartmann

-------------

PR: https://git.openjdk.org/jdk/pull/29519

From aartemov at openjdk.org  Thu Feb 12 08:45:14 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 12 Feb 2026 08:45:14 GMT
Subject: RFR: 8376665: Port fdlibm acosh to Java [v8]
In-Reply-To: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
References: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
Message-ID: <iZYaCs-IWWK5g2YVmjkxTD3yPYvhvlTxm9SZL-Zlrgc=.69740715-dfb9-43b4-8699-4e4e8892cc30@github.com>

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM acosh method.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8376665: Addressed reviewer's comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29488/files
  - new: https://git.openjdk.org/jdk/pull/29488/files/9e468d66..e50c546a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29488&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29488&range=06-07

  Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/29488.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29488/head:pull/29488

PR: https://git.openjdk.org/jdk/pull/29488

From aartemov at openjdk.org  Thu Feb 12 08:45:18 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 12 Feb 2026 08:45:18 GMT
Subject: RFR: 8376665: Port fdlibm acosh to Java [v7]
In-Reply-To: <tKmGjSsen_LFBdHd06iGGFRCseLMIBrmKm-LyPlwpOU=.be769fa1-e2f3-4224-b9cd-1933126b13f0@github.com>
References: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
 <GzviyITmy02TvDM982wKv3R_bdXSp6oWYT947Pb5sn4=.7a353745-deea-4a6a-b0e0-c28dbac556b6@github.com>
 <tKmGjSsen_LFBdHd06iGGFRCseLMIBrmKm-LyPlwpOU=.be769fa1-e2f3-4224-b9cd-1933126b13f0@github.com>
Message-ID: <Rvq9aLS-9rAs3nGbzo2zJj4yG3qSWhh-IZUHxMMs7Rk=.62c90a2e-27ef-4a7c-8da4-a07fda1f8597@github.com>

On Wed, 11 Feb 2026 14:05:34 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8376665: Stylistical fixes.
>>  - 8376665: Stylistical fixes.
>
> src/java.base/share/classes/java/lang/FdLibm.java line 3573:
> 
>> 3571:      *      acosh(x) is defined so that acosh(cosh(alpha)) = alpha, -&infin; &lt; alpha < &infin
>> 3572:      *      and cosh(acosh(x)) = x, 1 <= x  < &infin.
>> 3573:      *      It can be written as acosh(x) = ln(x + sqrt(x^2 - 1)), 1 <= x  < &infin.
> 
> It's `&infin;` with a semicolon, like any HTML entity name.
> Also, replace `<` with `&lt;`

Noted.

> src/java.base/share/classes/java/lang/FdLibm.java line 3574:
> 
>> 3572:      *      and cosh(acosh(x)) = x, 1 <= x  < &infin.
>> 3573:      *      It can be written as acosh(x) = ln(x + sqrt(x^2 - 1)), 1 <= x  < &infin.
>> 3574:      *      acosh(x) := log(x)+ln2, if x is large; else
> 
> Using both log and ln in the same context might be confusing. Consistency would be welcome.

Fixed.

> src/java.base/share/classes/java/lang/Math.java line 2793:
> 
>> 2791:      * Returns the inverse hyperbolic cosine of a {@code double} value.
>> 2792:      * The inverse hyperbolic cosine of <i>x</i> is defined to be the function such that
>> 2793:      *  acosh({@linkplain Math#cosh cosh(<i>x</i>)}) = <i>x</i> for any <i>x >= 0</i>.
> 
> Suggestion:
> 
>      *  acosh({@linkplain Math#cosh cosh(<i>x</i>)}) = <i>x</i> for any <i>x</i> >= 0.

Fixed.

> src/java.base/share/classes/java/lang/StrictMath.java line 2202:
> 
>> 2200:      * Returns the inverse hyperbolic cosine of a {@code double} value.
>> 2201:      * The inverse hyperbolic cosine of <i>x</i> is defined to be the function such that
>> 2202:      *  acosh({@linkplain Math#cosh cosh(<i>x</i>)}) = <i>x</i> for any <i>x >= 0</i>.
> 
> Suggestion:
> 
>      *  acosh({@linkplain Math#cosh cosh(<i>x</i>)}) = <i>x</i> for any <i>x</i> >= 0.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29488#discussion_r2797505752
PR Review Comment: https://git.openjdk.org/jdk/pull/29488#discussion_r2797506130
PR Review Comment: https://git.openjdk.org/jdk/pull/29488#discussion_r2797506562
PR Review Comment: https://git.openjdk.org/jdk/pull/29488#discussion_r2797507016

From jpbempel at openjdk.org  Thu Feb 12 10:21:25 2026
From: jpbempel at openjdk.org (Jean-Philippe Bempel)
Date: Thu, 12 Feb 2026 10:21:25 GMT
Subject: RFR: 8376185: NoSuchFieldError thrown after a record with type
 annotation retransformed [v4]
In-Reply-To: <XW2Cg1qe3q-032vXC49SYIPv_GuIoWNuINSwfFyHTzk=.788d3555-f05e-41ab-be8b-3a94a4e43a97@github.com>
References: <XW2Cg1qe3q-032vXC49SYIPv_GuIoWNuINSwfFyHTzk=.788d3555-f05e-41ab-be8b-3a94a4e43a97@github.com>
Message-ID: <XTDY8BlyH_WqMO3V8vq0FTXyBUr36LCOD34bOWasFEI=.2f47257a-6d10-48d9-bc82-db233f82ce6f@github.com>

> ?retransformed
> 
> Fix a retransform error when retransforming a record with type annotation. processing the record type annotation was done by calling the wrong method and using the one to process regular annotation. Regular annotations have not the same structure and decoding was therefore incorrect. The decoding methods detect a problem but this error was not propagated correctly outside of VM_RedfineClass::load_new_class_versions method, swallowing the error and leaving the retransformed class in bad state.
> 
> Here we have fixed the call to the right method for decoding the type annotations but also propagated the error when rewriting the constant pool as an JVMTI_ERROR_INTERNAL

Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision:

  replace shell script with class running asmtools
  
  include output directory for asmtools and jcoder command
  Add comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29445/files
  - new: https://git.openjdk.org/jdk/pull/29445/files/f0ee21fd..d11590b7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29445&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29445&range=02-03

  Stats: 134 lines in 4 files changed: 104 ins; 29 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29445.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29445/head:pull/29445

PR: https://git.openjdk.org/jdk/pull/29445

From aturbanov at openjdk.org  Thu Feb 12 10:28:14 2026
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 12 Feb 2026 10:28:14 GMT
Subject: RFR: 8376665: Port fdlibm acosh to Java [v8]
In-Reply-To: <iZYaCs-IWWK5g2YVmjkxTD3yPYvhvlTxm9SZL-Zlrgc=.69740715-dfb9-43b4-8699-4e4e8892cc30@github.com>
References: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
 <iZYaCs-IWWK5g2YVmjkxTD3yPYvhvlTxm9SZL-Zlrgc=.69740715-dfb9-43b4-8699-4e4e8892cc30@github.com>
Message-ID: <LsvCAkOPUBS2o6KySjIk45H69-OK1Tbe0VOR0pKfCHk=.00867e34-296a-4358-a695-ba55f9252a24@github.com>

On Thu, 12 Feb 2026 08:45:14 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM acosh method.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8376665: Addressed reviewer's comments.

src/java.base/share/classes/java/lang/FdLibm.java line 3591:

> 3589:             int hx;
> 3590:             hx = __HI(x);
> 3591:             if(hx < 0x3ff0_0000) {                           // x < 1 */

Suggestion:

            if (hx < 0x3ff0_0000) {                           // x < 1 */

src/java.base/share/classes/java/lang/FdLibm.java line 3594:

> 3592:                 return (x - x) / (x - x);
> 3593:             } else if (hx >= 0x41b0_0000) {                  // x > 2**28
> 3594:                 if(hx >= 0x7ff0_0000) {                      // x is inf of NaN

Suggestion:

                if (hx >= 0x7ff0_0000) {                      // x is inf of NaN

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29488#discussion_r2798021724
PR Review Comment: https://git.openjdk.org/jdk/pull/29488#discussion_r2798022331

From aartemov at openjdk.org  Thu Feb 12 12:04:41 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 12 Feb 2026 12:04:41 GMT
Subject: RFR: 8376665: Port fdlibm acosh to Java [v9]
In-Reply-To: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
References: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
Message-ID: <8Aa15ErOwvGDWlwsoPoDk72EP0Oj0NCV14UMkrpurYc=.d3a6c8a2-b2b1-4845-8550-fcb82bde9786@github.com>

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM acosh method.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8376665: Fixed whitespaces.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29488/files
  - new: https://git.openjdk.org/jdk/pull/29488/files/e50c546a..13218df6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29488&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29488&range=07-08

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/29488.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29488/head:pull/29488

PR: https://git.openjdk.org/jdk/pull/29488

From aartemov at openjdk.org  Thu Feb 12 12:04:45 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 12 Feb 2026 12:04:45 GMT
Subject: RFR: 8376665: Port fdlibm acosh to Java [v8]
In-Reply-To: <LsvCAkOPUBS2o6KySjIk45H69-OK1Tbe0VOR0pKfCHk=.00867e34-296a-4358-a695-ba55f9252a24@github.com>
References: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
 <iZYaCs-IWWK5g2YVmjkxTD3yPYvhvlTxm9SZL-Zlrgc=.69740715-dfb9-43b4-8699-4e4e8892cc30@github.com>
 <LsvCAkOPUBS2o6KySjIk45H69-OK1Tbe0VOR0pKfCHk=.00867e34-296a-4358-a695-ba55f9252a24@github.com>
Message-ID: <NYoCVU2O_jZjMGTi9XHBheUMwqubUW6u3DCMGxO-V5I=.0434b175-6baf-4e12-a6ff-226353527555@github.com>

On Thu, 12 Feb 2026 10:25:32 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8376665: Addressed reviewer's comments.
>
> src/java.base/share/classes/java/lang/FdLibm.java line 3591:
> 
>> 3589:             int hx;
>> 3590:             hx = __HI(x);
>> 3591:             if(hx < 0x3ff0_0000) {                           // x < 1 */
> 
> Suggestion:
> 
>             if (hx < 0x3ff0_0000) {                           // x < 1 */

Fixed.

> src/java.base/share/classes/java/lang/FdLibm.java line 3594:
> 
>> 3592:                 return (x - x) / (x - x);
>> 3593:             } else if (hx >= 0x41b0_0000) {                  // x > 2**28
>> 3594:                 if(hx >= 0x7ff0_0000) {                      // x is inf of NaN
> 
> Suggestion:
> 
>                 if (hx >= 0x7ff0_0000) {                      // x is inf of NaN

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29488#discussion_r2798480203
PR Review Comment: https://git.openjdk.org/jdk/pull/29488#discussion_r2798480381

From jpai at openjdk.org  Thu Feb 12 13:49:56 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Feb 2026 13:49:56 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v3]
In-Reply-To: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
Message-ID: <puhByiLbFFRHJTwHjnP2QQSmBidL-VksCwLbyYsau7E=.208136b8-5ec3-412e-8586-c8f357d876ce@github.com>

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?
> 
> The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.
> 
> When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.
> 
> When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.
> 
> Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `OutputStream` is a `Bu...

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 eight additional commits since the last revision:

 - merge latest from master branch
 - merge latest from master branch
 - add comment
 - copyright years
 - alternate fix
 - rename test
 - 8362268: NPE thrown from SASL GSSAPI impl when  TLS is  used with QOP auth-int against Active Directory
 - introduce test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29638/files
  - new: https://git.openjdk.org/jdk/pull/29638/files/f8b8165d..2c0973ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29638&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29638&range=01-02

  Stats: 11318 lines in 337 files changed: 7170 ins; 2082 del; 2066 mod
  Patch: https://git.openjdk.org/jdk/pull/29638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29638/head:pull/29638

PR: https://git.openjdk.org/jdk/pull/29638

From rriggs at openjdk.org  Thu Feb 12 14:30:25 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 12 Feb 2026 14:30:25 GMT
Subject: RFR: 8376234: Migrate java/lang/constant tests away from TestNG
In-Reply-To: <OdyavIz4EF19kdDjM05Un-d0XGg3SNisPGcF_WHvAb4=.b26f0248-eb76-47df-9505-9690c8206b2d@github.com>
References: <OdyavIz4EF19kdDjM05Un-d0XGg3SNisPGcF_WHvAb4=.b26f0248-eb76-47df-9505-9690c8206b2d@github.com>
Message-ID: <08BNNvYjMiNpHw9c4rEfI-iiLE7JUWUyQCnBs1aq3U0=.51aa6873-59e9-4793-a2ba-22a050b2dcaa@github.com>

On Fri, 23 Jan 2026 22:10:06 GMT, Chen Liang <liach at openjdk.org> wrote:

> Convert all TestNG tests in java/lang/constant to JUnit tests.

Looks good.

test/jdk/java/lang/constant/CondyDescTest.java line 211:

> 209:         assertFalse(clazz.isAssignableFrom(nonCanonical.getClass()));
> 210:         assertEquals(canonical, prototype);
> 211:         assertEquals(prototype, canonical);

The tool swapped the lines unnecessarily.
And a couple more cases below.

test/jdk/java/lang/constant/MethodHandleDescTest.java line 113:

> 111:         testMethodHandleDesc(r);
> 112: 
> 113:         assertMHEquals(mh, r.resolveConstantDesc(LOOKUP));

Swapping the arguments isn't necessary since assertMHEquals is reflexive.
The method arguments don't follow the junit expected/actual ordering.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29396#pullrequestreview-3790970821
PR Review Comment: https://git.openjdk.org/jdk/pull/29396#discussion_r2798847481
PR Review Comment: https://git.openjdk.org/jdk/pull/29396#discussion_r2799051841

From prappo at openjdk.org  Thu Feb 12 14:42:46 2026
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 12 Feb 2026 14:42:46 GMT
Subject: RFR: 8352171: Arrays.hashCode for sub-range of byte array API
 addition [v3]
In-Reply-To: <nxrWw6FZFcRhcLcDU0VhTqy385UMeGfx-YbtS5arZ00=.94edd34b-ef09-472f-9292-71bc0cd6a4b1@github.com>
References: <863TowvS917gG9yKE1hbDkd_CeYCwzbSm_mtAcKFTJQ=.f6a72b03-5642-493d-8d2b-48bbf4a3f8b2@github.com>
 <nxrWw6FZFcRhcLcDU0VhTqy385UMeGfx-YbtS5arZ00=.94edd34b-ef09-472f-9292-71bc0cd6a4b1@github.com>
Message-ID: <Pa9PkV58ePtgQ7RdBGR2TAoH2aUrrU1imA25Jzcybj0=.879c4873-ab5a-4e08-91ed-0dd5b020e97d@github.com>

On Mon, 9 Feb 2026 21:35:33 GMT, Zihao Lin <zlin at openjdk.org> wrote:

>> Add the java.util.Arrays.hashCode(byte[], int start, int end).
>> 
>> Hi team, I am new here, please give me some guidance. Thank you.
>
> Zihao Lin 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:
> 
>  - rename to hashCodeOfRange
>  - Merge branch 'master' into dev
>  - Merge branch 'openjdk:master' into dev
>  - Merge branch 'openjdk:master' into dev
>  - 8352171: Arrays.hashCode for sub-range of byte array API addition

My 2 (euro) cent, which you can ignore. Try to be consistent with the prevailing style of javadoc in this class. Use `{@code}` and other formatting only where other methods do. There's no need to use code font for numbers. Similarly, while I also like symbolic and mathematical notation, it doesn't fit this class to use `[a, b)` to denote a half-open range or interval.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24128#issuecomment-3891336463

From rgiulietti at openjdk.org  Thu Feb 12 14:43:58 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 12 Feb 2026 14:43:58 GMT
Subject: RFR: 8376665: Port fdlibm acosh to Java [v9]
In-Reply-To: <8Aa15ErOwvGDWlwsoPoDk72EP0Oj0NCV14UMkrpurYc=.d3a6c8a2-b2b1-4845-8550-fcb82bde9786@github.com>
References: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
 <8Aa15ErOwvGDWlwsoPoDk72EP0Oj0NCV14UMkrpurYc=.d3a6c8a2-b2b1-4845-8550-fcb82bde9786@github.com>
Message-ID: <pHQfrMwgNhTzQJarE5_yRUM_ANOZ0HJ-iuW55-Ravgk=.47bc6a3e-8b0f-4c7e-aa11-3abb3b08bc61@github.com>

On Thu, 12 Feb 2026 12:04:41 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM acosh method.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8376665: Fixed whitespaces.

Please wait 24 hours before integrating to give a chance for everyone in all timezones to chime in.

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29488#pullrequestreview-3791425190

From jwilhelm at openjdk.org  Thu Feb 12 14:56:45 2026
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 12 Feb 2026 14:56:45 GMT
Subject: [jdk26] RFR: 8377509: Add licenses for gcc 14.2.0
Message-ID: <OlTzcX0sobf8ZtaiEzc7uPz25lqbCivkILrgjYdh_y0=.4d3ad81d-37d1-4025-9597-8aaf3f78c2c7@github.com>

8377509: Add licenses for gcc 14.2.0

-------------

Commit messages:
 - Backport 961d32842d7841701a33659493a84b4d2c4d2f82

Changes: https://git.openjdk.org/jdk/pull/29694/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29694&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377509
  Stats: 2084 lines in 1 file changed: 2084 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29694.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29694/head:pull/29694

PR: https://git.openjdk.org/jdk/pull/29694

From eosterlund at openjdk.org  Thu Feb 12 15:13:25 2026
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 12 Feb 2026 15:13:25 GMT
Subject: [jdk26] RFR: 8377509: Add licenses for gcc 14.2.0
In-Reply-To: <OlTzcX0sobf8ZtaiEzc7uPz25lqbCivkILrgjYdh_y0=.4d3ad81d-37d1-4025-9597-8aaf3f78c2c7@github.com>
References: <OlTzcX0sobf8ZtaiEzc7uPz25lqbCivkILrgjYdh_y0=.4d3ad81d-37d1-4025-9597-8aaf3f78c2c7@github.com>
Message-ID: <C3Sge6zRE2yl44sArcZvIFAJx25korGGeCPzP5PJWfE=.fcdc5c46-0684-46df-b315-5be6ec7e88ac@github.com>

On Thu, 12 Feb 2026 14:48:28 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> 8377509: Add licenses for gcc 14.2.0

Looks like a license to me.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29694#pullrequestreview-3791615001

From jwilhelm at openjdk.org  Thu Feb 12 15:18:51 2026
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 12 Feb 2026 15:18:51 GMT
Subject: [jdk26] Integrated: 8377509: Add licenses for gcc 14.2.0
In-Reply-To: <OlTzcX0sobf8ZtaiEzc7uPz25lqbCivkILrgjYdh_y0=.4d3ad81d-37d1-4025-9597-8aaf3f78c2c7@github.com>
References: <OlTzcX0sobf8ZtaiEzc7uPz25lqbCivkILrgjYdh_y0=.4d3ad81d-37d1-4025-9597-8aaf3f78c2c7@github.com>
Message-ID: <6KFoolvJ7tconEKLR57HBtfUxY3YkZjOcEoXExTCNLY=.b9043135-567e-4994-8c0d-ddd1000b43b3@github.com>

On Thu, 12 Feb 2026 14:48:28 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> 8377509: Add licenses for gcc 14.2.0

This pull request has now been integrated.

Changeset: 4408cd2a
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4408cd2a07a14243a58cd9d30813302bfbe81133
Stats:     2084 lines in 1 file changed: 2084 ins; 0 del; 0 mod

8377509: Add licenses for gcc 14.2.0

Reviewed-by: eosterlund
Backport-of: 961d32842d7841701a33659493a84b4d2c4d2f82

-------------

PR: https://git.openjdk.org/jdk/pull/29694

From rriggs at openjdk.org  Thu Feb 12 15:18:56 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 12 Feb 2026 15:18:56 GMT
Subject: RFR: 8377070: Migrate preview mode support for jimage to mainline
In-Reply-To: <hrFvapR-FfjUfX5TBKowIxO6Xfac9eOaWOc7JtyVtVo=.c3e88771-0ac9-44c7-a415-916d3f76ac80@github.com>
References: <hrFvapR-FfjUfX5TBKowIxO6Xfac9eOaWOc7JtyVtVo=.c3e88771-0ac9-44c7-a415-916d3f76ac80@github.com>
Message-ID: <aOGq1QjBWHK68FNPKjlAzft6sVl_cwGgi6YwqYgQSKE=.e1e0fe99-c6e9-414c-ab3d-484f49877105@github.com>

On Mon, 26 Jan 2026 12:42:06 GMT, David Beaumont <duke at openjdk.org> wrote:

> Implementation of preview-mode support for jimage modules file, migrated from Valhalla related work (see JDK-8352750).
> 
> This PR (the first of several) migrates work from Valhalla (lworld) to the JDK mainline repository in relation to "preview mode" support. It affects the creation and reading of the jimage file, both in Java (BasicImageReader/ImageReader) and C++ (imageFile.xpp/jimage.xpp).
> 
> Preview mode is a mechanism by which alternate version of JDK class files and resources can be made available for class loading and reflection when the '--enable-preview' flag is passed to the runtime.
> 
> Alternate classes/resource appear in each module under the:
> 
> /<module>/META-INF/preview/<path-to>/<resource-or-class>
> 
> and replace the original:
> 
> /<module>/<path-to>/<resource-or-class>
> 
> files when preview mode is enabled.
> 
> While initially useful for Valhalla work, this mechanism will be used for other cases where preview features (in the JEP 12 sense) require alternate classes/resources to be provided. None of the changes in this (or the follow-up PRs) are Valhalla specific.
> 
> In this PR:
> * the writing of jimage files is modified to recognize and handle preview mode paths
> * flags in the jimage file are added or modified to support preview mode efficiently
> * (C++) the class loader is modified to permit reading preview versions of classes
> * (Java) the image reader and associated JRT file-system classes are modified to permit reading preview files
> * unit tests are added to ensure preview mode works as expected when enabled
> * (temporary) any code calling into the affected API (other than tests) specifies that preview mode is disabled
> 
> Future PRs will add the plumbing to enable preview mode correctly, but with the PR there should be no observable change in behaviour (especially since no preview classes or resources are being supplied at this point).

Looks good.
Please update copyrights.

A second reviewer would be good for this re-implementation.

src/hotspot/share/classfile/classLoader.cpp line 269:

> 267: static JImageFile* jimage_non_null() {
> 268:   assert(jimage_exists(), "should have been opened by ClassLoader::lookup_vm_options "
> 269:                           "and remained throughout normal JVM lifetime");

"remained" -> "remain open"

src/hotspot/share/runtime/arguments.cpp line 2995:

> 2993: 
> 2994:   // Called after ClassLoader::lookup_vm_options() but before class loading begins.
> 2995:   // TODO: Obtain and pass correct preview mode flag value here.

Suggestion: A hotspot convention is to include the bugid of the fix/enhancement that is pending.
Since you've planned the progression of PR's that may be useful here.  YMMV.

src/java.base/share/classes/jdk/internal/jimage/ModuleReference.java line 85:

> 83:         return new ModuleReference(moduleName, previewFlag(isPreview));
> 84:     }
> 85: 

A one-line comment may be useful here.

src/java.base/share/native/libjimage/imageFile.cpp line 361:

> 359:         if (verify_location(location, path)) {
> 360:                 *size = (jlong)location.get_attribute(ImageLocation::ATTRIBUTE_UNCOMPRESSED);
> 361:             return offset;

The previous line is also wrongly-indented.

src/java.base/share/native/libjimage/jimage.cpp line 112:

> 110:     size_t module_name_len = strlen(module_name);
> 111:     size_t name_len = strlen(name);
> 112:     size_t preview_infix_len = strlen(preview_infix);

`sizeof` would make this a constant.

-------------

PR Review: https://git.openjdk.org/jdk/pull/29414#pullrequestreview-3787717603
PR Comment: https://git.openjdk.org/jdk/pull/29414#issuecomment-3891551995
PR Review Comment: https://git.openjdk.org/jdk/pull/29414#discussion_r2795758045
PR Review Comment: https://git.openjdk.org/jdk/pull/29414#discussion_r2795792694
PR Review Comment: https://git.openjdk.org/jdk/pull/29414#discussion_r2795824431
PR Review Comment: https://git.openjdk.org/jdk/pull/29414#discussion_r2799342198
PR Review Comment: https://git.openjdk.org/jdk/pull/29414#discussion_r2799363201

From vyazici at openjdk.org  Thu Feb 12 16:11:25 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 12 Feb 2026 16:11:25 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v2]
In-Reply-To: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
Message-ID: <rObgPuAWe3qMxqlDCoOSR4Tpj9zHt6g8kb68ATCOCig=.9fce9ad3-8254-489f-9585-1624465da04c@github.com>

> Moves input validation checks to Java for `java.lang.StringLatin1` intrinsics. While doing so, affected `java.lang.StringUTF16` methods needed to be updated due to relaxed checks at intrinsics. The javadocs of the touched methods are extensively overhauled.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Apply review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28832/files
  - new: https://git.openjdk.org/jdk/pull/28832/files/6e5273ed..068eb358

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28832&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28832&range=00-01

  Stats: 33 lines in 3 files changed: 0 ins; 6 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/28832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28832/head:pull/28832

PR: https://git.openjdk.org/jdk/pull/28832

From vyazici at openjdk.org  Thu Feb 12 16:15:08 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 12 Feb 2026 16:15:08 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v2]
In-Reply-To: <3ui4ZV1EWo2YpaqabNnOSHlCWN3QJKVBFbYs4fb8hPE=.b8bdb195-43c5-4900-ad61-09b575f3a212@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
 <3ui4ZV1EWo2YpaqabNnOSHlCWN3QJKVBFbYs4fb8hPE=.b8bdb195-43c5-4900-ad61-09b575f3a212@github.com>
Message-ID: <f4ih6l15znL2Js_rB4kEI88K5OM8-6BpOC5oWnzgWdA=.7eb7b057-32dd-4736-b84c-d305b91e255d@github.com>

On Tue, 10 Feb 2026 17:10:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply review feedback
>
> src/hotspot/share/classfile/vmIntrinsics.hpp line 363:
> 
>> 361:                                                                                                                         \
>> 362:   do_intrinsic(_compressStringC,          java_lang_StringUTF16,  compressS_name, encodeISOArray_signature,      F_S)   \
>> 363:    do_name(     compressS_name,                                  "compress0")                                           \
> 
> _compressS_name doesn't seem to follow the naming pattern.

Renamed to `compressString_name` in 068eb3589a3.

> Is there a HotSpot specific namespace qualifier that can make it easier to cross reference this?

@RogerRiggs, not that I know of. I also considered following alternatives:

- `library_call.cpp:inline_string_equals`
- `vmIntrinsics::_compressStringB`

But none really qualifies as a programmatic reference and settled on `inline_string_equals`, the most convenient phrase to do find-and-jump.

@dafedafe, @TobiHartmann, do you have any suggestions/preferences?

> src/java.base/share/classes/java/lang/StringLatin1.java line 207:
> 
>> 205: 
>> 206:     /**
>> 207:      * Lexicographically compares a Latin-1 string sub-range to a UTF-16
> 
> It would be more specific to say it compares a "prefix" since the start is always 0.

Applied your suggestion in 068eb3589a3.

> src/java.base/share/classes/java/lang/StringUTF16.java line 398:
> 
>> 396: 
>> 397:     /**
>> 398:      * Exhaustively copies Latin-1 characters from a {@code char} array
> 
> The word Exhaustively does not fit here because it stops copying for > 0xff.
> Perhaps:   "Copies the prefix of Latin-1 characters".

Applied your suggestion in 068eb3589a3.

> src/java.base/share/classes/java/lang/StringUTF16.java line 457:
> 
>> 455:         Objects.requireNonNull(src);
>> 456:         checkBoundsOffCount(srcOff, len, src);
>> 457:         String.checkBoundsOffCount(dstOff, len, dst.length);    // Implicit null check on `dst`
> 
> This bouncing around between source files for methods of the same name `checkBoundsOffCout` is bound to confuse the reader.
> Be consistent, either now or later, use the local one in this file or remove the utility method.

Removed `StringUTF16::checkBoundsOffCout`, and replaced its usages with `String.checkBoundsOffCout(..., StringUTF16.length(...))` in 068eb3589a3.

> src/java.base/share/classes/java/lang/StringUTF16.java line 603:
> 
>> 601: 
>> 602:     /**
>> 603:      * Lexicographically compares a UTF-16 string sub-range to a Latin-1 one as
> 
> It isn't a full sub-range, the start index is 0, use prefix instead.

Applied your suggestion in 068eb3589a3.

> src/java.base/share/classes/java/lang/StringUTF16.java line 950:
> 
>> 948:     }
>> 949: 
>> 950: 
> 
> Extra blank line.

Removed it in 068eb3589a3.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2799746361
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2799751943
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2799754004
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2799756674
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2799758583
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2799759597
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2799760520

From vyazici at openjdk.org  Thu Feb 12 16:15:14 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 12 Feb 2026 16:15:14 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v2]
In-Reply-To: <KeNqd83bGg0oPTyA4m5C8HB_F5q5r4jcY_ac96NNMI4=.74f069e3-4ba1-44b2-b9ac-6d84a745d8cb@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
 <KeNqd83bGg0oPTyA4m5C8HB_F5q5r4jcY_ac96NNMI4=.74f069e3-4ba1-44b2-b9ac-6d84a745d8cb@github.com>
Message-ID: <E3MpThx86Yu3C_JpWtNTcoc_WJ5DX5ohKb1j1LmAn84=.b84c33bd-9ea4-433f-bc38-6176b0345a48@github.com>

On Tue, 10 Feb 2026 08:28:58 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply review feedback
>
> src/hotspot/share/classfile/vmIntrinsics.hpp line 402:
> 
>> 400:    do_signature(indexOfChar_signature,                           "([BIII)I")                                            \
>> 401:   do_intrinsic(_equalsL,                  java_lang_StringLatin1,equalsS_name, equalsB_signature,                 F_S)  \
>> 402:     do_name(    equalsS_name,                                    "equals0")                                             \
> 
> Suggestion:
> 
>    do_name(    equalsS_name,                                     "equals0")                                             \

Applied the suggestion in 068eb3589a3.

> src/java.base/share/classes/java/lang/StringLatin1.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2015, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Suggestion:
> 
>  * Copyright (c) 2015, 2026, Oracle and/or its affiliates. All rights reserved.

Corrected the copyright year in 068eb3589a3.

> Are these additional checks?

Yes. I'm exercising _"Always validate all input at the Java wrapper"_ stated in the parent issue [JDK-8156534].

> I'm asking because I was expecting them to "replace" intrinsics ones but couldn't find where/how

Note the Javadoc of `ArraysSupport#mismatch(byte[] a, byte[] b, int length)`:

    This method does not perform bounds checks. It is the responsibility
    of the caller to perform such bounds checks before calling this method.

AFAICT, `ArraysSupport` should be updated to validate its inputs too. But that is for another day.

> I'm also wondering why they were not there before: did all callers ensure that?

Yes, pretty much accidentally.

[JDK-8156534]: https://bugs.openjdk.org/browse/JDK-8156534

> src/java.base/share/classes/java/lang/StringLatin1.java line 220:
> 
>> 218:     static int compareToUTF16(byte[] value, byte[] other, int len1, int len2) {
>> 219:         Objects.requireNonNull(value);
>> 220:         Objects.requireNonNull(other);
> 
> [Similar question](https://github.com/openjdk/jdk/pull/28832/changes#r2788781455)

Callers were ensuring the validity.

> src/java.base/share/classes/java/lang/StringLatin1.java line 266:
> 
>> 264:     static int compareToCI_UTF16(byte[] value, byte[] other) {
>> 265:         Objects.requireNonNull(value);
>> 266:         Objects.requireNonNull(other);
> 
> [Similar question](https://github.com/openjdk/jdk/pull/28832/changes#r2788781455)

Caller were ensuring the validity.

> src/java.base/share/classes/java/lang/StringUTF16.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2015, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Suggestion:
> 
>  * Copyright (c) 2015, 2026, Oracle and/or its affiliates. All rights reserved.

Corrected the copyright year in 068eb3589a3.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2799748646
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2799749747
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2799752709
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2799754246
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2799754534
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2799755812

From mullan at openjdk.org  Thu Feb 12 18:21:15 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 12 Feb 2026 18:21:15 GMT
Subject: RFR: 8377102: cacerts jlink plugin
Message-ID: <pRqfyRXHZHI7_wpjlirukGFoiqBdiQ58hH8z7km54Aw=.0e1621b5-1851-4783-bd2e-ba6b28f1ead6@github.com>

This is a new `jlink` plugin which allows the user to specify the CA certificates it wants to include in the `cacerts` keystore in a custom runtime image. This can be very useful for creating runtimes that only contain the CA certificates that are necessary.

The command-line syntax takes one or more `cacert` keystore aliases as an option, separated by a comma.

For example: 

`jlink --cacerts "letsencryptisrgx1 [jdk]"`

or

`jlink --cacerts "letsencryptisrgx1 [jdk],digicertglobalrootca [jdk]"`

-------------

Commit messages:
 - Initial revision.

Changes: https://git.openjdk.org/jdk/pull/29700/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29700&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377102
  Stats: 250 lines in 4 files changed: 247 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/29700.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29700/head:pull/29700

PR: https://git.openjdk.org/jdk/pull/29700

From weijun at openjdk.org  Thu Feb 12 18:50:26 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 12 Feb 2026 18:50:26 GMT
Subject: RFR: 8377102: cacerts jlink plugin
In-Reply-To: <pRqfyRXHZHI7_wpjlirukGFoiqBdiQ58hH8z7km54Aw=.0e1621b5-1851-4783-bd2e-ba6b28f1ead6@github.com>
References: <pRqfyRXHZHI7_wpjlirukGFoiqBdiQ58hH8z7km54Aw=.0e1621b5-1851-4783-bd2e-ba6b28f1ead6@github.com>
Message-ID: <T4viO9xZTmh_fNFwGqhOZKIG1zOPIwkSVlzcXzNxKqE=.921053da-5772-4ecd-8f24-bb45f086f723@github.com>

On Thu, 12 Feb 2026 18:12:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is a new `jlink` plugin which allows the user to specify the CA certificates it wants to include in the `cacerts` keystore in a custom runtime image. This can be very useful for creating runtimes that only contain the CA certificates that are necessary.
> 
> The command-line syntax takes one or more `cacert` keystore aliases as an option, separated by a comma.
> 
> For example: 
> 
> `jlink --cacerts "letsencryptisrgx1 [jdk]"`
> 
> or
> 
> `jlink --cacerts "letsencryptisrgx1 [jdk],digicertglobalrootca [jdk]"`

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/CACertsPlugin.java line 108:

> 106:             ks.load(null, null);
> 107:             for (var entry : certs.entrySet()) {
> 108:                 ks.setCertificateEntry(entry.getKey(), entry.getValue());

Assume the original entry has attributes, do we want to copy them into the new keystore?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29700#discussion_r2800519127

From asemenyuk at openjdk.org  Thu Feb 12 19:24:11 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 12 Feb 2026 19:24:11 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v10]
In-Reply-To: <H389dzZFtboOtIhBr0X0uNsZsE3y4rnw8RW5jBHAsgo=.3f874a1d-5271-4d94-8d30-03d54a64c4e2@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <H389dzZFtboOtIhBr0X0uNsZsE3y4rnw8RW5jBHAsgo=.3f874a1d-5271-4d94-8d30-03d54a64c4e2@github.com>
Message-ID: <3eMtW8ameVPa5telshPA1irDvlz67YF1nAD9BJMpFVA=.a405f66f-b589-4575-8b07-c43abebc60b0@github.com>

On Wed, 11 Feb 2026 20:12:19 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
>> - Added test to cover added functionality.
>> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v9]

src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxFromOptions.java line 82:

> 80:             // In this case it should ensure the derived value is valid RPM version.
> 81:             if (type.isPresent()) {
> 82:                 if (type.get().equals(LINUX_RPM)) {

The use of `OptionUtils.bundlingOperation(options) == StandardBundlingOperation.CREATE_LINUX_RPM` instead of the two conditions is simpler and eliminates the need to modify the signature of the `createLinuxApplication()` function.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2800649691

From asemenyuk at openjdk.org  Thu Feb 12 19:28:33 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 12 Feb 2026 19:28:33 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v10]
In-Reply-To: <H389dzZFtboOtIhBr0X0uNsZsE3y4rnw8RW5jBHAsgo=.3f874a1d-5271-4d94-8d30-03d54a64c4e2@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <H389dzZFtboOtIhBr0X0uNsZsE3y4rnw8RW5jBHAsgo=.3f874a1d-5271-4d94-8d30-03d54a64c4e2@github.com>
Message-ID: <613yRAHdc98iESn-zRrrO-hpLuTsPV_Zti32Bnv1rZM=.f2e5b362-0a49-43a1-b666-a5355d02e195@github.com>

On Wed, 11 Feb 2026 20:12:19 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
>> - Added test to cover added functionality.
>> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v9]

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinFromOptions.java line 47:

> 45: 
> 46: import java.math.BigInteger;
> 47: import java.util.Arrays;

These imports look redundant

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2800674373

From mullan at openjdk.org  Thu Feb 12 19:34:52 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 12 Feb 2026 19:34:52 GMT
Subject: RFR: 8377102: cacerts jlink plugin
In-Reply-To: <T4viO9xZTmh_fNFwGqhOZKIG1zOPIwkSVlzcXzNxKqE=.921053da-5772-4ecd-8f24-bb45f086f723@github.com>
References: <pRqfyRXHZHI7_wpjlirukGFoiqBdiQ58hH8z7km54Aw=.0e1621b5-1851-4783-bd2e-ba6b28f1ead6@github.com>
 <T4viO9xZTmh_fNFwGqhOZKIG1zOPIwkSVlzcXzNxKqE=.921053da-5772-4ecd-8f24-bb45f086f723@github.com>
Message-ID: <tWxz29q_22V31akyfEjke7f1fqDXOfyhHzknEdTYMPQ=.f6359b38-10ed-4155-a0a0-ebe06f7426a0@github.com>

On Thu, 12 Feb 2026 18:47:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is a new `jlink` plugin which allows the user to specify the CA certificates it wants to include in the `cacerts` keystore in a custom runtime image. This can be very useful for creating runtimes that only contain the CA certificates that are necessary.
>> 
>> The command-line syntax takes one or more `cacert` keystore aliases as an option, separated by a comma.
>> 
>> For example: 
>> 
>> `jlink --cacerts "letsencryptisrgx1 [jdk]"`
>> 
>> or
>> 
>> `jlink --cacerts "letsencryptisrgx1 [jdk],digicertglobalrootca [jdk]"`
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/CACertsPlugin.java line 108:
> 
>> 106:             ks.load(null, null);
>> 107:             for (var entry : certs.entrySet()) {
>> 108:                 ks.setCertificateEntry(entry.getKey(), entry.getValue());
> 
> Assume the original entry has attributes, do we want to copy them into the new keystore?

I could, I think it is easy enough to do, although I'm not aware of any use cases that depend on attributes, and `keytool` doesn't support them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29700#discussion_r2800695726

From asemenyuk at openjdk.org  Thu Feb 12 19:36:56 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 12 Feb 2026 19:36:56 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v10]
In-Reply-To: <H389dzZFtboOtIhBr0X0uNsZsE3y4rnw8RW5jBHAsgo=.3f874a1d-5271-4d94-8d30-03d54a64c4e2@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <H389dzZFtboOtIhBr0X0uNsZsE3y4rnw8RW5jBHAsgo=.3f874a1d-5271-4d94-8d30-03d54a64c4e2@github.com>
Message-ID: <CcFoYyN5YulsLXKzsOYotPiFscyeJHcNem16jyj2iOk=.6b8e4e9f-75d7-45eb-81d2-1cfb306927a4@github.com>

On Wed, 11 Feb 2026 20:12:19 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
>> - Added test to cover added functionality.
>> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v9]

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinFromOptions.java line 142:

> 140:             // We should drop any characters. For example: "-ea".
> 141:             return ver.toComponentsString();
> 142:         }

If I understand the code correctly, and the `version` variable is set to "17.2", then the function will return "17.2", right? But if it is "17.2.1", it will return "17.2.1.0". Is this what we want?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2800695743

From asemenyuk at openjdk.org  Thu Feb 12 19:42:14 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 12 Feb 2026 19:42:14 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v10]
In-Reply-To: <H389dzZFtboOtIhBr0X0uNsZsE3y4rnw8RW5jBHAsgo=.3f874a1d-5271-4d94-8d30-03d54a64c4e2@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <H389dzZFtboOtIhBr0X0uNsZsE3y4rnw8RW5jBHAsgo=.3f874a1d-5271-4d94-8d30-03d54a64c4e2@github.com>
Message-ID: <baogBM2-qGAY3tXMHb7MwDES75o8aR71Hz90ERknPNo=.957de6f7-1495-494b-b9fd-b60601910b38@github.com>

On Wed, 11 Feb 2026 20:12:19 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
>> - Added test to cover added functionality.
>> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v9]

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 254:

> 252:         return TKit.isLinux() && (PackageType.LINUX_RPM == getArgumentValue("--type",
> 253:                 () -> null, PACKAGE_TYPES::get));
> 254:     }

This method is redundant. It can be replaced by `packageType() == PackageType.LINUX_RPM` condition

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 263:

> 261:                 final var releaseFile = RuntimeImageUtils.getReleaseFilePath(runtimeHome);
> 262:                 return RuntimeVersionReader.readVersion(releaseFile).map(releaseVersion -> {
> 263:                     if (TKit.isWindows()) {

The switch would be more appropriate here:

switch (packageType()) {
    case WIN_EXE, WIN_MSI -> {
        return WindowsHelper.getNormalizedVersion(releaseVersion.toString());
    }
    ...
}

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java line 45:

> 43: import java.lang.reflect.InvocationTargetException;
> 44: import java.lang.reflect.Method;
> 45: import java.math.BigInteger;

This import looks redundant

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2800716263
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2800721777
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2800724898

From psandoz at openjdk.org  Thu Feb 12 20:54:20 2026
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 12 Feb 2026 20:54:20 GMT
Subject: RFR: 8376186: [VectorAPI] Nomenclature change for concrete vector
 classes [v2]
In-Reply-To: <JhYx6qx3-eTm4uKLOImjGouDeXouNhiUEyiHYNMAHiE=.7b898af9-0e8b-4ecd-806f-de3304415cf4@github.com>
References: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
 <JhYx6qx3-eTm4uKLOImjGouDeXouNhiUEyiHYNMAHiE=.7b898af9-0e8b-4ecd-806f-de3304415cf4@github.com>
Message-ID: <Vdd_PeqLjKlZkO3euaUt3IxKrRtqCg0qM4vZZ7CN2W4=.6c076b92-c741-4584-8183-69078277cc69@github.com>

On Wed, 11 Feb 2026 10:42:32 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
>> 
>> In preparation of Float16 vector API support, changes to nomenclature of concrete vector class by suffixing the vector type with vector bit sizes e.g. FloatVector256 so that we don't end up generating names like Float16256Vector.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment resolution

This looks good. I did a search on the code base using the regex `[\d]+Vector` and found one place. In `VectorMathLibrary` the naming convention is used in a local variable name, so we might as well update that.

-------------

PR Review: https://git.openjdk.org/jdk/pull/29614#pullrequestreview-3793608325

From asemenyuk at openjdk.org  Thu Feb 12 21:17:00 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 12 Feb 2026 21:17:00 GMT
Subject: Integrated: 8377629: jpackage: Tighten up output validation in tests
In-Reply-To: <YC1d5DOWUhhgexyqfObG14ud4LeOdD6oDKwlAgKZWyI=.49769a63-3d02-47bc-92fa-27295c3e95e9@github.com>
References: <YC1d5DOWUhhgexyqfObG14ud4LeOdD6oDKwlAgKZWyI=.49769a63-3d02-47bc-92fa-27295c3e95e9@github.com>
Message-ID: <QDADoVysxbu_jtvbSOaWYIP3i4KouyoAvw-re_RN_40=.f63c3fcd-f5d8-4522-9b69-5ffb5dff6334@github.com>

On Tue, 10 Feb 2026 03:04:18 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Tighten up jpackage's output validation.
> 
>  - Support separate validation of jpackage's stdout and stderr. Previously, validation was applied to the merged stdout and stderr output, so errors were not detected when jpackage expected to write to stdout but wrote to stderr instead
> - 99% of test cases in ErrorTest will check that jpackage's stderr contains exact expected error messages and doesn't contain additional text lines
> - Use `String.equals()` instead of `String.contains()` when validating strings from jpackage string bundles in jpackage output
> 
> Replace TKit.TextStreamVerifier.Group class with a more capable JPackageOutputValidator.
> 
> Fix revealed issues:
>  - jdk.jpackage.internal.AppImageSigner: use `Log.fatalError()` to report a fatal signing error instead of `Log.info()`. This change directs signing error messages to stderr, where all warnings and errors belong, rather than stdout.
>  - On macOS, when the value of the "--app-image" option is not a directory, jpackage used to report two errors: that the value is not a directory and that it is not a macOS bundle. This behavior has changed: jpackage will report only the first error. If the value of the "--app-image" option is a directory that is not a valid macOS bundle, jpackage will fail with the corresponding error.

This pull request has now been integrated.

Changeset: c7ef631b
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c7ef631b0c99c725120d7dde4b11fd34baf0455d
Stats:     965 lines in 27 files changed: 635 ins; 118 del; 212 mod

8377629: jpackage: Tighten up output validation in tests

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/29644

From ryan at hallock.us  Thu Feb 12 21:45:39 2026
From: ryan at hallock.us (Ryan Hallock)
Date: Thu, 12 Feb 2026 15:45:39 -0600
Subject: Add @Stable to Class#enumConstants.
Message-ID: <CAC4ELwECZ-G58UAv-AQ01dtL22ZY8s6WQiU7FiDyh-4nDXhqEw@mail.gmail.com>

Hello, I am new to OpenJDK development and I want to propose changes to
Class#enumConstants from
Class#getEnumConstants()/Class#getSharedEnumConstants().

Currently consider the following example:
```java
enum E {
    A, B, C
}
E[] values = E.values();
E[] constants = E.class.getEnumConstants();
assert Arrays.equals(values, constants);
```
These methods provide an equal array of values, but they are treated
differently. This is because the _constants_ stored by Class#enumConstants
are non final and declared volatile. So C2 can't trust this call. Consider
if I only wanted to access the value from an offset from these arrays.
```java
E value = values[0];
E constant = constants[0];
assert value == constant;
```
_constant_ would never be folded but _value_ would be.

So I propose the addition of @Stable annotation added to
Class#enumConstants so _constant_ can be folded by C2. This is not a
trivial change as it requires changing the data race to abide by @Stable.
Could I be sponsored for this change (JBS issue as well)?

A future proposal would be adding @Stable to Class#enumConstantDirectory,
though that can be a seperate enhancement as that might require changing of
the data structure to allow folding. Let me know if it should be combined
as the Stable annotation itself would be implemented in a similar way for
both.

Thanks,
Ryan Hallock
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260212/280f685a/attachment.htm>

From almatvee at openjdk.org  Thu Feb 12 22:22:15 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 12 Feb 2026 22:22:15 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v11]
In-Reply-To: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
Message-ID: <j4ymgpDEZyARILLwjqdCNrl1ggS98AsitGOmxSKx1jo=.5ae425cc-513b-4bd5-b3d3-9cec1292cbf2@github.com>

> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
> - Added test to cover added functionality.
> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.

Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge remote-tracking branch 'upstream/master' into JDK-8357404
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v9]
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v8]
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v7]
 - Merge remote-tracking branch 'upstream/master' into JDK-8357404
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]
 - merge with upstream
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v5]
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v4]
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v3]
 - ... and 2 more: https://git.openjdk.org/jdk/compare/c7ef631b...6a644426

-------------

Changes: https://git.openjdk.org/jdk/pull/29260/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=10
  Stats: 800 lines in 20 files changed: 715 ins; 20 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/29260.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29260/head:pull/29260

PR: https://git.openjdk.org/jdk/pull/29260

From chen.l.liang at oracle.com  Thu Feb 12 23:46:13 2026
From: chen.l.liang at oracle.com (Chen Liang)
Date: Thu, 12 Feb 2026 23:46:13 +0000
Subject: Add @Stable to Class#enumConstants.
In-Reply-To: <CAC4ELwECZ-G58UAv-AQ01dtL22ZY8s6WQiU7FiDyh-4nDXhqEw@mail.gmail.com>
References: <CAC4ELwECZ-G58UAv-AQ01dtL22ZY8s6WQiU7FiDyh-4nDXhqEw@mail.gmail.com>
Message-ID: <IA0SPRMB0009615B0623BF22DE50D398A260A@IA0SPRMB0009.namprd10.prod.outlook.com>

Hi Ryan, is there a use case where people call getEnumConstants() and access a fixed index of array element?

This is so far the only use case I can think of that would be negatively impacted by the lack of constant folding for this method.

In addition, I do not recommend adding more @Stable - we should consider better representations like LazyConstant.

Regards
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Ryan Hallock <ryan at hallock.us>
Sent: Thursday, February 12, 2026 3:45 PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Add @Stable to Class#enumConstants.

Hello, I am new to OpenJDK development and I want to propose changes to Class#enumConstants from Class#getEnumConstants()/Class#getSharedEnumConstants().

Currently consider the following example:
```java
enum E {
    A, B, C
}
E[] values = E.values();
E[] constants = E.class.getEnumConstants();
assert Arrays.equals(values, constants);
```
These methods provide an equal array of values, but they are treated differently. This is because the _constants_ stored by Class#enumConstants are non final and declared volatile. So C2 can't trust this call. Consider if I only wanted to access the value from an offset from these arrays.
```java
E value = values[0];
E constant = constants[0];
assert value == constant;
```
_constant_ would never be folded but _value_ would be.

So I propose the addition of @Stable annotation added to Class#enumConstants so _constant_ can be folded by C2. This is not a trivial change as it requires changing the data race to abide by @Stable. Could I be sponsored for this change (JBS issue as well)?

A future proposal would be adding @Stable to Class#enumConstantDirectory, though that can be a seperate enhancement as that might require changing of the data structure to allow folding. Let me know if it should be combined as the Stable annotation itself would be implemented in a similar way for both.

Thanks,
Ryan Hallock

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260212/f23b299d/attachment-0001.htm>

From almatvee at openjdk.org  Thu Feb 12 23:47:41 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 12 Feb 2026 23:47:41 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v10]
In-Reply-To: <CcFoYyN5YulsLXKzsOYotPiFscyeJHcNem16jyj2iOk=.6b8e4e9f-75d7-45eb-81d2-1cfb306927a4@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <H389dzZFtboOtIhBr0X0uNsZsE3y4rnw8RW5jBHAsgo=.3f874a1d-5271-4d94-8d30-03d54a64c4e2@github.com>
 <CcFoYyN5YulsLXKzsOYotPiFscyeJHcNem16jyj2iOk=.6b8e4e9f-75d7-45eb-81d2-1cfb306927a4@github.com>
Message-ID: <-S58KvW69ZzrfdhCBGoyqOBPbL6hn6jhJdOPjxxhCzU=.7c65591d-b0c3-4679-963c-f5859f2628b6@github.com>

On Thu, 12 Feb 2026 19:31:39 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v9]
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinFromOptions.java line 142:
> 
>> 140:             // We should drop any characters. For example: "-ea".
>> 141:             return ver.toComponentsString();
>> 142:         }
> 
> If I understand the code correctly, and the `version` variable is set to "17.2", then the function will return "17.2", right? But if it is "17.2.1", it will return "17.2.1.0". Is this what we want?

Yes. We want to normalize only if version is not complaint with target package requirements. If normalization is required it will be always done to 4 components. 17 -> 17.0.0.0.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2801572749

From asemenyuk at openjdk.org  Thu Feb 12 23:57:33 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 12 Feb 2026 23:57:33 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v10]
In-Reply-To: <-S58KvW69ZzrfdhCBGoyqOBPbL6hn6jhJdOPjxxhCzU=.7c65591d-b0c3-4679-963c-f5859f2628b6@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <H389dzZFtboOtIhBr0X0uNsZsE3y4rnw8RW5jBHAsgo=.3f874a1d-5271-4d94-8d30-03d54a64c4e2@github.com>
 <CcFoYyN5YulsLXKzsOYotPiFscyeJHcNem16jyj2iOk=.6b8e4e9f-75d7-45eb-81d2-1cfb306927a4@github.com>
 <-S58KvW69ZzrfdhCBGoyqOBPbL6hn6jhJdOPjxxhCzU=.7c65591d-b0c3-4679-963c-f5859f2628b6@github.com>
Message-ID: <meNbrxR3hFwsSbzrR7LU0onpxLxFic8dW1mQ8ht-2L4=.02aeb35e-02d1-4fba-b1ee-795e7e1da43a@github.com>

On Thu, 12 Feb 2026 23:44:42 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinFromOptions.java line 142:
>> 
>>> 140:             // We should drop any characters. For example: "-ea".
>>> 141:             return ver.toComponentsString();
>>> 142:         }
>> 
>> If I understand the code correctly, and the `version` variable is set to "17.2", then the function will return "17.2", right? But if it is "17.2.1", it will return "17.2.1.0". Is this what we want?
>
> Yes. We want to normalize only if version is not complaint with target package requirements. If normalization is required it will be always done to 4 components. 17 -> 17.0.0.0.

Ok, but why "17.2" is a special case:

17     -> 17.0.0.0
17.2   -> 17.2
17.2.3 -> 17.2.3.0

?

And another question. If "17.2" is OK, then why don't we convert "17" into "17.0" instead of "17.0.0.0"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2801594960

From almatvee at openjdk.org  Fri Feb 13 00:05:38 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 13 Feb 2026 00:05:38 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v10]
In-Reply-To: <meNbrxR3hFwsSbzrR7LU0onpxLxFic8dW1mQ8ht-2L4=.02aeb35e-02d1-4fba-b1ee-795e7e1da43a@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <H389dzZFtboOtIhBr0X0uNsZsE3y4rnw8RW5jBHAsgo=.3f874a1d-5271-4d94-8d30-03d54a64c4e2@github.com>
 <CcFoYyN5YulsLXKzsOYotPiFscyeJHcNem16jyj2iOk=.6b8e4e9f-75d7-45eb-81d2-1cfb306927a4@github.com>
 <-S58KvW69ZzrfdhCBGoyqOBPbL6hn6jhJdOPjxxhCzU=.7c65591d-b0c3-4679-963c-f5859f2628b6@github.com>
 <meNbrxR3hFwsSbzrR7LU0onpxLxFic8dW1mQ8ht-2L4=.02aeb35e-02d1-4fba-b1ee-795e7e1da43a@github.com>
Message-ID: <FribbfkIXyoGcbgfGHAPR6IJsGA6IDPqKaABFMbmFbQ=.fbc2c572-3889-4865-9844-8d90bd389f70@github.com>

On Thu, 12 Feb 2026 23:53:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Yes. We want to normalize only if version is not complaint with target package requirements. If normalization is required it will be always done to 4 components. 17 -> 17.0.0.0.
>
> Ok, but why "17.2" is a special case:
> 
> 17     -> 17.0.0.0
> 17.2   -> 17.2
> 17.2.3 -> 17.2.3.0
> 
> ?
> 
> And another question. If "17.2" is OK, then why don't we convert "17" into "17.0" instead of "17.0.0.0"?

2 or 4 components are valid for Windows.

> "17" into "17.0" instead of "17.0.0.0"?

Good question. I do not have any preferences.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2801623500

From asemenyuk at openjdk.org  Fri Feb 13 00:19:45 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 13 Feb 2026 00:19:45 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v10]
In-Reply-To: <FribbfkIXyoGcbgfGHAPR6IJsGA6IDPqKaABFMbmFbQ=.fbc2c572-3889-4865-9844-8d90bd389f70@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <H389dzZFtboOtIhBr0X0uNsZsE3y4rnw8RW5jBHAsgo=.3f874a1d-5271-4d94-8d30-03d54a64c4e2@github.com>
 <CcFoYyN5YulsLXKzsOYotPiFscyeJHcNem16jyj2iOk=.6b8e4e9f-75d7-45eb-81d2-1cfb306927a4@github.com>
 <-S58KvW69ZzrfdhCBGoyqOBPbL6hn6jhJdOPjxxhCzU=.7c65591d-b0c3-4679-963c-f5859f2628b6@github.com>
 <meNbrxR3hFwsSbzrR7LU0onpxLxFic8dW1mQ8ht-2L4=.02aeb35e-02d1-4fba-b1ee-795e7e1da43a@github.com>
 <FribbfkIXyoGcbgfGHAPR6IJsGA6IDPqKaABFMbmFbQ=.fbc2c572-3889-4865-9844-8d90bd389f70@github.com>
Message-ID: <nRhMgac2Ozo-yE0_L_KNFZT38mQUoL6yqjoDUaLapVs=.5a798530-affa-4569-96c4-42511a8b06a6@github.com>

On Fri, 13 Feb 2026 00:02:51 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> 2 or 4 components are valid for Windows.

Ok, why 3 is not valid? Which component complains?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2801655705

From almatvee at openjdk.org  Fri Feb 13 00:48:28 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 13 Feb 2026 00:48:28 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v10]
In-Reply-To: <nRhMgac2Ozo-yE0_L_KNFZT38mQUoL6yqjoDUaLapVs=.5a798530-affa-4569-96c4-42511a8b06a6@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <H389dzZFtboOtIhBr0X0uNsZsE3y4rnw8RW5jBHAsgo=.3f874a1d-5271-4d94-8d30-03d54a64c4e2@github.com>
 <CcFoYyN5YulsLXKzsOYotPiFscyeJHcNem16jyj2iOk=.6b8e4e9f-75d7-45eb-81d2-1cfb306927a4@github.com>
 <-S58KvW69ZzrfdhCBGoyqOBPbL6hn6jhJdOPjxxhCzU=.7c65591d-b0c3-4679-963c-f5859f2628b6@github.com>
 <meNbrxR3hFwsSbzrR7LU0onpxLxFic8dW1mQ8ht-2L4=.02aeb35e-02d1-4fba-b1ee-795e7e1da43a@github.com>
 <FribbfkIXyoGcbgfGHAPR6IJsGA6IDPqKaABFMbmFbQ=.fbc2c572-3889-4865-9844-8d90bd389f70@github.com>
 <nRhMgac2Ozo-yE0_L_KNFZT38mQUoL6yqjoDUaLapVs=.5a798530-affa-4569-96c4-42511a8b06a6@github.com>
Message-ID: <VL7bHKB0AwYIBFL_xA426FUUmyBdGT2q6HJ2PNB2rq4=.0028a8bd-f73a-411a-9701-182ecb866f10@github.com>

On Fri, 13 Feb 2026 00:17:03 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> 2 or 4 components are valid for Windows.
>> 
>>> "17" into "17.0" instead of "17.0.0.0"?
>> 
>> Good question. I do not have any preferences.
>
>> 2 or 4 components are valid for Windows.
> 
> Ok, why 3 is not valid? Which component complains?

MSI. It should be between 2 and 4, so 3 is valid. Will fix it.

if (components.length < 2 || components.length > 4) {
            throw buildLocalizedException()
                    .message("error.msi-product-version-components", value)
                    .create(IllegalArgumentException::new);
        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2801736267

From ryan at hallock.us  Fri Feb 13 01:20:31 2026
From: ryan at hallock.us (Ryan Hallock)
Date: Fri, 13 Feb 2026 01:20:31 +0000
Subject: Add @Stable to Class#enumConstants.
In-Reply-To: <IA0SPRMB0009615B0623BF22DE50D398A260A@IA0SPRMB0009.namprd10.prod.outlook.com>
References: <CAC4ELwECZ-G58UAv-AQ01dtL22ZY8s6WQiU7FiDyh-4nDXhqEw@mail.gmail.com>
 <IA0SPRMB0009615B0623BF22DE50D398A260A@IA0SPRMB0009.namprd10.prod.outlook.com>
Message-ID: <CAC4ELwH+76=NQ2k-BUSZiffW6Oz2wXMjB=7Np9vhr+6uBP4jnA@mail.gmail.com>

Hi Chen, just searching GitHub it seems there are 2600 results for
Class#getEnumConstants()[0], from looking at them it's mostly used in a
fallback scenario in most cases when they only have the Class. So I
wouldn't be surprised if most of these callsites would never be able to be
resolved, this was meant to be an example that's easy to make an IR test &
micro benchmark for.

Class#enumConstants are also used in getting the universe of EnumMap,
EnumSet, So call sites like EnumSet.noneOf(Class), and EnumMap(Class) would
also benefit from such a change as it may be able to fold the volatile
read. (untested)

In defense to using @Stable over LazyConstant is there would be a
capturing lambda plus an LazyConstant allocated for every class even if
it's not an Enum, then if you wanted to make LazyConstant itself lazy it
would also require a @Stable to be able to fold. This seems like an
antipattern. Also this kind of goes against the idea behind caching
Class#enumConstants here as it is currently null if it's never used. As for
the implementation I have in mind would also likely place the
Unsafe#compareAndExchangeReference in the existing Class.Atomic as to still
allow this being used early in the startup process similar to LazyConstant.

Please let me know if you have any additional questions.

Cheers,
Ryan Hallock

On Thu, Feb 12, 2026 at 11:46?PM Chen Liang <chen.l.liang at oracle.com> wrote:

> Hi Ryan, is there a use case where people call getEnumConstants() and
> access a fixed index of array element?
>
> This is so far the only use case I can think of that would be negatively
> impacted by the lack of constant folding for this method.
>
> In addition, I do not recommend adding more @Stable - we should consider
> better representations like LazyConstant.
>
> Regards
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Ryan
> Hallock <ryan at hallock.us>
> *Sent:* Thursday, February 12, 2026 3:45 PM
> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Subject:* Add @Stable to Class#enumConstants.
>
> Hello, I am new to OpenJDK development and I want to propose changes to
> Class#enumConstants from
> Class#getEnumConstants()/Class#getSharedEnumConstants().
>
> Currently consider the following example:
> ```java
> enum E {
>     A, B, C
> }
> E[] values = E.values();
> E[] constants = E.class.getEnumConstants();
> assert Arrays.equals(values, constants);
> ```
> These methods provide an equal array of values, but they are treated
> differently. This is because the _constants_ stored by Class#enumConstants
> are non final and declared volatile. So C2 can't trust this call. Consider
> if I only wanted to access the value from an offset from these arrays.
> ```java
> E value = values[0];
> E constant = constants[0];
> assert value == constant;
> ```
> _constant_ would never be folded but _value_ would be.
>
> So I propose the addition of @Stable annotation added to
> Class#enumConstants so _constant_ can be folded by C2. This is not a
> trivial change as it requires changing the data race to abide by @Stable.
> Could I be sponsored for this change (JBS issue as well)?
>
> A future proposal would be adding @Stable to Class#enumConstantDirectory,
> though that can be a seperate enhancement as that might require changing of
> the data structure to allow folding. Let me know if it should be combined
> as the Stable annotation itself would be implemented in a similar way for
> both.
>
> Thanks,
> Ryan Hallock
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260213/ea985066/attachment.htm>

From jpai at openjdk.org  Fri Feb 13 02:05:51 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Feb 2026 02:05:51 GMT
Subject: RFR: 8377857: Add since checker test for java.naming module
Message-ID: <i75aV2GS75Ug9CzaNXKrVq3TMB-t5cJFsrAaYe_puTI=.73e4f0f3-1fa7-4a6a-ab82-95dda2521682@github.com>

Can I please get a review of this change which introduces a test to verify the usages of `@since` javadoc tags in the `java.naming` module? This addresses https://bugs.openjdk.org/browse/JDK-8377857.

The `SinceChecker` test utility has been in use for several modules, but wasn't added for java.naming. The commit in this PR adds one for that module.

The `SinceChecker` test utility does not handle the presence of a comma in (for example `@since X, Y`) correctly. The javadoc tag spec for `@since` allows that syntax https://docs.oracle.com/en/java/javase/25/docs/specs/javadoc/doc-comment-spec.html#since. As a workaround, the commit in this PR splits the `@since` on `javax.naming.InitialContext` class into two separate declarations (this too is allowed by the `@since` tag spec). I've verified that the generated javadoc continues to correctly show these values. I have also spoken to Nizar about this issue in SinceChecker and it will be addressed separately.

-------------

Commit messages:
 - 8377857: Add since checker test for java.naming module

Changes: https://git.openjdk.org/jdk/pull/29705/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29705&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377857
  Stats: 32 lines in 2 files changed: 30 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/29705.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29705/head:pull/29705

PR: https://git.openjdk.org/jdk/pull/29705

From jpai at openjdk.org  Fri Feb 13 02:28:05 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Feb 2026 02:28:05 GMT
Subject: RFR: 8049630: Custom socket factory is not checked for the existence
 of a getDefault() method
Message-ID: <JNvlWlAZn-EXjPRX4-1ZvbAUvOgGFdAqqLpEgeWAZks=.629f21c8-41ec-4156-b32f-d9bbc059938a@github.com>

Can I please get a review of this change which addresses the issues noted in https://bugs.openjdk.org/browse/JDK-8049630 and https://bugs.openjdk.org/browse/JDK-8049619?

The `java.naming` module allows for the `java.naming.ldap.factory.socket` environment property to be configured to point to the class name of the implementation of a `javax.net.SocketFactory`. As noted in the specification of that property https://docs.oracle.com/en/java/javase/25/docs/api/java.naming/module-summary.html:

> The value of this environment property specifies the fully qualified class name of the socket factory used by the LDAP provider. This class must implement the SocketFactory abstract class and provide an implementation of the static "getDefault()" method that returns an instance of the socket factory.

The implementation in the JDK default LDAP provider currently doesn't verify that the given class name points to a type which is `javax.net.SocketFactory`, nor does it verify that the correct expected `getDefault()` method exists. The changes in this PR addresses that issue and introduces a jtreg test to reproduce the issue and verify the fix.

Given the nature of this change, I believe a CSR will be needed which I'll file shortly.

-------------

Commit messages:
 - 8049630: Custom socket factory is not checked for the existence of a getDefault() method

Changes: https://git.openjdk.org/jdk/pull/29706/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29706&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8049630
  Stats: 180 lines in 3 files changed: 167 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/29706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29706/head:pull/29706

PR: https://git.openjdk.org/jdk/pull/29706

From almatvee at openjdk.org  Fri Feb 13 03:32:17 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 13 Feb 2026 03:32:17 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v12]
In-Reply-To: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
Message-ID: <RbGqJfJv4v1UiNQnzQJPFXUoI2viH2-rrOQ8yX5T3OI=.be609e13-29f6-4ebe-84f4-84e6a559952a@github.com>

> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
> - Added test to cover added functionality.
> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v10]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29260/files
  - new: https://git.openjdk.org/jdk/pull/29260/files/6a644426..a7d5c14e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=10-11

  Stats: 88 lines in 6 files changed: 30 ins; 34 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/29260.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29260/head:pull/29260

PR: https://git.openjdk.org/jdk/pull/29260

From almatvee at openjdk.org  Fri Feb 13 03:32:19 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 13 Feb 2026 03:32:19 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v11]
In-Reply-To: <j4ymgpDEZyARILLwjqdCNrl1ggS98AsitGOmxSKx1jo=.5ae425cc-513b-4bd5-b3d3-9cec1292cbf2@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <j4ymgpDEZyARILLwjqdCNrl1ggS98AsitGOmxSKx1jo=.5ae425cc-513b-4bd5-b3d3-9cec1292cbf2@github.com>
Message-ID: <HMtnRglpnLcuskBfH3CKeNpPnIpT-M_ohJoRXgzx3GE=.c1922042-43c9-442f-a8f0-5a004cc31bdd@github.com>

On Thu, 12 Feb 2026 22:22:15 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
>> - Added test to cover added functionality.
>> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.
>
> Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8357404
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v9]
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v8]
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v7]
>  - Merge remote-tracking branch 'upstream/master' into JDK-8357404
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]
>  - merge with upstream
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v5]
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v4]
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v3]
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/c7ef631b...6a644426

8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v10]
- Fixed latest comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29260#issuecomment-3894606165

From asemenyuk at openjdk.org  Fri Feb 13 03:44:11 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 13 Feb 2026 03:44:11 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v12]
In-Reply-To: <RbGqJfJv4v1UiNQnzQJPFXUoI2viH2-rrOQ8yX5T3OI=.be609e13-29f6-4ebe-84f4-84e6a559952a@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <RbGqJfJv4v1UiNQnzQJPFXUoI2viH2-rrOQ8yX5T3OI=.be609e13-29f6-4ebe-84f4-84e6a559952a@github.com>
Message-ID: <Y1TfdCawRAfRMose9HK2DAqYcRFhlKlgAIrC585UMVw=.c7196419-6cbc-4fc6-a101-db306bb9131c@github.com>

On Fri, 13 Feb 2026 03:32:17 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
>> - Added test to cover added functionality.
>> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v10]

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacFromOptions.java line 71:

> 69: import jdk.jpackage.internal.cli.StandardFaOption;
> 70: import jdk.jpackage.internal.model.Application;
> 71: import jdk.jpackage.internal.model.DottedVersion;

Looks like all newly added imports except for DottedVersion are redundant

src/jdk.jpackage/share/classes/jdk/jpackage/internal/FromOptions.java line 51:

> 49: import java.io.UncheckedIOException;
> 50: import java.nio.file.Path;
> 51: import java.util.Arrays;

I think these new imports are redundant

src/jdk.jpackage/share/classes/jdk/jpackage/internal/FromOptions.java line 145:

> 143:     }
> 144: 
> 145: 

Redundant new line change

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinFromOptions.java line 46:

> 44: import static jdk.jpackage.internal.model.StandardPackageType.WIN_MSI;
> 45: 
> 46: import java.util.function.UnaryOperator;

This import is redundant

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 37:

> 35: import java.io.IOException;
> 36: import java.io.UncheckedIOException;
> 37: import java.io.Writer;

Redundant import

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 54:

> 52: import java.util.Optional;
> 53: import java.util.OptionalInt;
> 54: import java.util.Properties;

Redundant import

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2802109086
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2802115154
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2802112958
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2802117084
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2802118431
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2802118722

From asemenyuk at openjdk.org  Fri Feb 13 03:53:28 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 13 Feb 2026 03:53:28 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v12]
In-Reply-To: <RbGqJfJv4v1UiNQnzQJPFXUoI2viH2-rrOQ8yX5T3OI=.be609e13-29f6-4ebe-84f4-84e6a559952a@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <RbGqJfJv4v1UiNQnzQJPFXUoI2viH2-rrOQ8yX5T3OI=.be609e13-29f6-4ebe-84f4-84e6a559952a@github.com>
Message-ID: <xYsHzA9mkwUad9FzEGNv85utnhzDK2lNOx22q-VIO8s=.d56b1428-c247-43ba-887c-0a445053b680@github.com>

On Fri, 13 Feb 2026 03:32:17 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
>> - Added test to cover added functionality.
>> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v10]

Changes requested by asemenyuk (Reviewer).

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinFromOptions.java line 140:

> 138:             // We should drop any characters. For example: "-ea".
> 139:             return ver.toComponentsString();
> 140:         }

Branching is redundant; it is equivalent to DottedVersion.lazy(version).trim(4).pad(2).toComponentsString()

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java line 32:

> 30: import java.lang.ref.SoftReference;
> 31: import java.lang.reflect.Method;
> 32: import java.math.BigInteger;

Redundant import

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java line 36:

> 34: import java.nio.file.Path;
> 35: import java.time.Instant;
> 36: import java.util.Arrays;

Redundant import

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java line 68:

> 66:         } else {
> 67:             return ver.toComponentsString();
> 68:         }

Branching is redundant; it is equivalent to `DottedVersion.lazy(version).trim(4).pad(2).toComponentsString()`

-------------

PR Review: https://git.openjdk.org/jdk/pull/29260#pullrequestreview-3794903796
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2802129151
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2802131394
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2802131960
PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2802128057

From duke at openjdk.org  Fri Feb 13 05:23:18 2026
From: duke at openjdk.org (Harshit470250)
Date: Fri, 13 Feb 2026 05:23:18 GMT
Subject: RFR: 8377035: [s390x] Disable JSR166 test cases which uses virtual
 threads [v4]
In-Reply-To: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
References: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
Message-ID: <OSAHszZtIaX88M8YjSIwooS5ovO8OzrLu5jgteEv3Y8=.080b008c-a25c-4166-b67b-885b2c6b15eb@github.com>

> ReentrantReadWriteLock20Test.java is failing on s390 due to virtual threads which are not yet implemented on s390. 
> SynchronousQueue20Test.java also uses virtual thread so I am also disabling it.

Harshit470250 has updated the pull request incrementally with one additional commit since the last revision:

  change java20TestClassNames only if on s390

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29555/files
  - new: https://git.openjdk.org/jdk/pull/29555/files/6ab2d8bf..6bc23d46

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29555&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29555&range=02-03

  Stats: 6 lines in 1 file changed: 2 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29555/head:pull/29555

PR: https://git.openjdk.org/jdk/pull/29555

From jpai at openjdk.org  Fri Feb 13 06:16:37 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Feb 2026 06:16:37 GMT
Subject: RFR: 8049630: Custom socket factory is not checked for the
 existence of a getDefault() method
In-Reply-To: <JNvlWlAZn-EXjPRX4-1ZvbAUvOgGFdAqqLpEgeWAZks=.629f21c8-41ec-4156-b32f-d9bbc059938a@github.com>
References: <JNvlWlAZn-EXjPRX4-1ZvbAUvOgGFdAqqLpEgeWAZks=.629f21c8-41ec-4156-b32f-d9bbc059938a@github.com>
Message-ID: <nMv0LiI7svim79HdLiOKF_W1fAAurP7L778FHNHo_1g=.27d6e9b8-e051-434a-869f-40414eee7412@github.com>

On Fri, 13 Feb 2026 02:19:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses the issues noted in https://bugs.openjdk.org/browse/JDK-8049630 and https://bugs.openjdk.org/browse/JDK-8049619?
> 
> The `java.naming` module allows for the `java.naming.ldap.factory.socket` environment property to be configured to point to the class name of the implementation of a `javax.net.SocketFactory`. As noted in the specification of that property https://docs.oracle.com/en/java/javase/25/docs/api/java.naming/module-summary.html:
> 
>> The value of this environment property specifies the fully qualified class name of the socket factory used by the LDAP provider. This class must implement the SocketFactory abstract class and provide an implementation of the static "getDefault()" method that returns an instance of the socket factory.
> 
> The implementation in the JDK default LDAP provider currently doesn't verify that the given class name points to a type which is `javax.net.SocketFactory`, nor does it verify that the correct expected `getDefault()` method exists. The changes in this PR addresses that issue and introduces a jtreg test to reproduce the issue and verify the fix.
> 
> Given the nature of this change, I believe a CSR will be needed which I'll file shortly.

The CSR is now ready for review https://bugs.openjdk.org/browse/JDK-8377864

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29706#issuecomment-3895116796

From jbhateja at openjdk.org  Fri Feb 13 06:33:44 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 13 Feb 2026 06:33:44 GMT
Subject: RFR: 8376186: [VectorAPI] Nomenclature change for concrete vector
 classes [v3]
In-Reply-To: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
References: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
Message-ID: <rFnnnmZYvqWwSF9swRBWGoK2BXHIuYl_qkplWfy1V94=.25b06d9d-ef15-4d8c-99a3-5c5cb69c280c@github.com>

> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
> 
> In preparation of Float16 vector API support, changes to nomenclature of concrete vector class by suffixing the vector type with vector bit sizes e.g. FloatVector256 so that we don't end up generating names like Float16256Vector.
> 
> All existing Vector API jtreg test are passing with the patch.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review comments resolution

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29614/files
  - new: https://git.openjdk.org/jdk/pull/29614/files/c63c10a7..8a5615d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29614&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29614&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/29614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29614/head:pull/29614

PR: https://git.openjdk.org/jdk/pull/29614

From jbhateja at openjdk.org  Fri Feb 13 06:33:45 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 13 Feb 2026 06:33:45 GMT
Subject: RFR: 8376186: [VectorAPI] Nomenclature change for concrete vector
 classes [v2]
In-Reply-To: <Vdd_PeqLjKlZkO3euaUt3IxKrRtqCg0qM4vZZ7CN2W4=.6c076b92-c741-4584-8183-69078277cc69@github.com>
References: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
 <JhYx6qx3-eTm4uKLOImjGouDeXouNhiUEyiHYNMAHiE=.7b898af9-0e8b-4ecd-806f-de3304415cf4@github.com>
 <Vdd_PeqLjKlZkO3euaUt3IxKrRtqCg0qM4vZZ7CN2W4=.6c076b92-c741-4584-8183-69078277cc69@github.com>
Message-ID: <GZenm0zRGVyGhsqKlsGSNrZQRqlUYO97fUlnfejG9aY=.60b07166-bd7d-4abb-b159-6ff3d7322228@github.com>

On Thu, 12 Feb 2026 20:52:06 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> This looks good. I did a search on the code base using the regex `[\d]+Vector` and found one place. In `VectorMathLibrary` the naming convention is used in a local variable name, so we might as well update that.

Thanks @PaulSandoz , Addressed!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29614#issuecomment-3895151976

From thartmann at openjdk.org  Fri Feb 13 07:05:29 2026
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 13 Feb 2026 07:05:29 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v2]
In-Reply-To: <f4ih6l15znL2Js_rB4kEI88K5OM8-6BpOC5oWnzgWdA=.7eb7b057-32dd-4736-b84c-d305b91e255d@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
 <3ui4ZV1EWo2YpaqabNnOSHlCWN3QJKVBFbYs4fb8hPE=.b8bdb195-43c5-4900-ad61-09b575f3a212@github.com>
 <f4ih6l15znL2Js_rB4kEI88K5OM8-6BpOC5oWnzgWdA=.7eb7b057-32dd-4736-b84c-d305b91e255d@github.com>
Message-ID: <nf0TkStEpXhGFDUzuEBfO-bxKox9QCm_K7OZwiM4tZs=.99ab1261-b993-42c5-8149-5199cec39212@github.com>

On Thu, 12 Feb 2026 16:09:35 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringLatin1.java line 112:
>> 
>>> 110:     }
>>> 111: 
>>> 112:     // inline_string_equals
>> 
>> Is there a HotSpot specific namespace qualifier that can make it easier to cross reference this?
>> Ditto the other hotspot names below.
>
>> Is there a HotSpot specific namespace qualifier that can make it easier to cross reference this?
> 
> @RogerRiggs, not that I know of. I also considered following alternatives:
> 
> - `library_call.cpp:inline_string_equals`
> - `vmIntrinsics::_compressStringB`
> 
> But none really qualifies as a programmatic reference and settled on `inline_string_equals`, the most convenient phrase to do find-and-jump.
> 
> @dafedafe, @TobiHartmann, do you have any suggestions/preferences?

I think `vmIntrinsics::_equalsL` would be the best option here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2802620696

From alanb at openjdk.org  Fri Feb 13 07:07:16 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Feb 2026 07:07:16 GMT
Subject: RFR: 8377035: [s390x] Disable JSR166 test cases which uses virtual
 threads [v4]
In-Reply-To: <OSAHszZtIaX88M8YjSIwooS5ovO8OzrLu5jgteEv3Y8=.080b008c-a25c-4166-b67b-885b2c6b15eb@github.com>
References: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
 <OSAHszZtIaX88M8YjSIwooS5ovO8OzrLu5jgteEv3Y8=.080b008c-a25c-4166-b67b-885b2c6b15eb@github.com>
Message-ID: <2yoeSUIryhNhYFDGNAIBnaSPOM9bUtceMbBo0StzDmo=.3bb22cd9-4447-4780-8f0d-4e63629896b9@github.com>

On Fri, 13 Feb 2026 05:23:18 GMT, Harshit470250 <duke at openjdk.org> wrote:

>> ReentrantReadWriteLock20Test.java is failing on s390 due to virtual threads which are not yet implemented on s390. 
>> SynchronousQueue20Test.java also uses virtual thread so I am also disabling it.
>
> Harshit470250 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change java20TestClassNames only if on s390

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29555#pullrequestreview-3795406872

From syan at openjdk.org  Fri Feb 13 08:11:30 2026
From: syan at openjdk.org (SendaoYan)
Date: Fri, 13 Feb 2026 08:11:30 GMT
Subject: [jdk26] RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some
 tests [v2]
In-Reply-To: <Wjhdn5QObisFsKhWfVdbWdAqro9vQU5gxTEszL7gNMk=.17da51b9-d767-430c-af2d-d55273d142cc@github.com>
References: <a9jk4WieiGK6U35ULrnvQNtjVHWuUCiKmV1HQ9GJO4A=.b23b2f46-763e-413d-97bf-1eaa76e7f5f3@github.com>
 <Wjhdn5QObisFsKhWfVdbWdAqro9vQU5gxTEszL7gNMk=.17da51b9-d767-430c-af2d-d55273d142cc@github.com>
Message-ID: <scm91m0sIRDLVXOi6T3MYA9PBG1tQdm1OyepqOALkmE=.b369cb23-b332-4578-a98c-4ed1e5f1111a@github.com>

On Wed, 17 Dec 2025 11:52:45 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [34f24131](https://github.com/openjdk/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by SendaoYan on 15 Dec 2025 and was reviewed by Leonid Mesnik and David Holmes.
>> 
>> This clean backport PR will make all the docker tests receive -Djdk.test.docker.retain.image property correctly.
>> 
>> Thanks!
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add an whitespace after if
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

I think we should close this PR now

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28826#issuecomment-3895504024

From syan at openjdk.org  Fri Feb 13 08:11:32 2026
From: syan at openjdk.org (SendaoYan)
Date: Fri, 13 Feb 2026 08:11:32 GMT
Subject: [jdk26] Withdrawn: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for
 some tests
In-Reply-To: <a9jk4WieiGK6U35ULrnvQNtjVHWuUCiKmV1HQ9GJO4A=.b23b2f46-763e-413d-97bf-1eaa76e7f5f3@github.com>
References: <a9jk4WieiGK6U35ULrnvQNtjVHWuUCiKmV1HQ9GJO4A=.b23b2f46-763e-413d-97bf-1eaa76e7f5f3@github.com>
Message-ID: <oOmBALtkt1kvQ23pZLaviWwiGgQy1nsV1dAyHq96P_A=.0956049c-0ce6-4cf8-9673-02872ba463b5@github.com>

On Mon, 15 Dec 2025 14:27:14 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [34f24131](https://github.com/openjdk/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 15 Dec 2025 and was reviewed by Leonid Mesnik and David Holmes.
> 
> This clean backport PR will make all the docker tests receive -Djdk.test.docker.retain.image property correctly.
> 
> Thanks!

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/28826

From duke at openjdk.org  Fri Feb 13 08:18:18 2026
From: duke at openjdk.org (duke)
Date: Fri, 13 Feb 2026 08:18:18 GMT
Subject: RFR: 8377035: [s390x] Disable JSR166 test cases which uses virtual
 threads [v4]
In-Reply-To: <OSAHszZtIaX88M8YjSIwooS5ovO8OzrLu5jgteEv3Y8=.080b008c-a25c-4166-b67b-885b2c6b15eb@github.com>
References: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
 <OSAHszZtIaX88M8YjSIwooS5ovO8OzrLu5jgteEv3Y8=.080b008c-a25c-4166-b67b-885b2c6b15eb@github.com>
Message-ID: <acjeAcy-j-_c1PsolGT9P9LMgBTKvnTc37hc0oY4G64=.12093ee5-6d04-4c58-942b-82b02ab79ba0@github.com>

On Fri, 13 Feb 2026 05:23:18 GMT, Harshit470250 <duke at openjdk.org> wrote:

>> ReentrantReadWriteLock20Test.java is failing on s390 due to virtual threads which are not yet implemented on s390. 
>> SynchronousQueue20Test.java also uses virtual thread so I am also disabling it.
>
> Harshit470250 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change java20TestClassNames only if on s390

@Harshit470250 
Your change (at version 6bc23d468b497cb035f8ffb3e583c5e2280ce33b) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29555#issuecomment-3895529373

From alanb at openjdk.org  Fri Feb 13 08:27:25 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Feb 2026 08:27:25 GMT
Subject: RFR: 8377857: Add since checker test for java.naming module
In-Reply-To: <i75aV2GS75Ug9CzaNXKrVq3TMB-t5cJFsrAaYe_puTI=.73e4f0f3-1fa7-4a6a-ab82-95dda2521682@github.com>
References: <i75aV2GS75Ug9CzaNXKrVq3TMB-t5cJFsrAaYe_puTI=.73e4f0f3-1fa7-4a6a-ab82-95dda2521682@github.com>
Message-ID: <kCJw03XoQeIh2AFk8yjOOx9A_FF0it5LC3BaGMMwp44=.edb8083c-c3be-45c8-9fa7-16344b4679a2@github.com>

On Fri, 13 Feb 2026 02:00:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which introduces a test to verify the usages of `@since` javadoc tags in the `java.naming` module? This addresses https://bugs.openjdk.org/browse/JDK-8377857.
> 
> The `SinceChecker` test utility has been in use for several modules, but wasn't added for java.naming. The commit in this PR adds one for that module.
> 
> The `SinceChecker` test utility does not handle the presence of a comma in (for example `@since X, Y`) correctly. The javadoc tag spec for `@since` allows that syntax https://docs.oracle.com/en/java/javase/25/docs/specs/javadoc/doc-comment-spec.html#since. As a workaround, the commit in this PR splits the `@since` on `javax.naming.InitialContext` class into two separate declarations (this too is allowed by the `@since` tag spec). I've verified that the generated javadoc continues to correctly show these values. I have also spoken to Nizar about this issue in SinceChecker and it will be addressed separately.

src/java.naming/share/classes/javax/naming/InitialContext.java line 121:

> 119:  *      NamingManager.setInitialContextFactoryBuilder
> 120:  * @since 1.3
> 121:  * @since JNDI 1.1

Do we really need to keep `@since JNDI 1.1`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29705#discussion_r2802901491

From jbhateja at openjdk.org  Fri Feb 13 08:44:50 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 13 Feb 2026 08:44:50 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v13]
In-Reply-To: <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
Message-ID: <SuF2PPHbvps3Pr380hkFkYI2q8bB0dCl37z-JoRTDyc=.f419937c-e006-471e-8c14-119bb0d8e576@github.com>

On Mon, 9 Feb 2026 21:36:16 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 with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - Review comments resolutions
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - Review comments resolutions
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - Update callGenerator.hpp copyright year
>  - Review comments resolution
>  - Cleanups
>  - Review comments resolutions
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/ffb6279c...1dfff558

Hi @sviswa7 , @merykitty , Can you please review x86 backed implementation and approve.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3895635725

From dfuchs at openjdk.org  Fri Feb 13 09:49:36 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Feb 2026 09:49:36 GMT
Subject: RFR: 8049630: Custom socket factory is not checked for the
 existence of a getDefault() method
In-Reply-To: <JNvlWlAZn-EXjPRX4-1ZvbAUvOgGFdAqqLpEgeWAZks=.629f21c8-41ec-4156-b32f-d9bbc059938a@github.com>
References: <JNvlWlAZn-EXjPRX4-1ZvbAUvOgGFdAqqLpEgeWAZks=.629f21c8-41ec-4156-b32f-d9bbc059938a@github.com>
Message-ID: <tKcxJ8wI7QAUFE6psNmIkQ_PC2SNQxjzQ1I0Nx9bMho=.f99b9465-a10a-4bec-ba19-ce55eb5cc163@github.com>

On Fri, 13 Feb 2026 02:19:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses the issues noted in https://bugs.openjdk.org/browse/JDK-8049630 and https://bugs.openjdk.org/browse/JDK-8049619?
> 
> The `java.naming` module allows for the `java.naming.ldap.factory.socket` environment property to be configured to point to the class name of the implementation of a `javax.net.SocketFactory`. As noted in the specification of that property https://docs.oracle.com/en/java/javase/25/docs/api/java.naming/module-summary.html:
> 
>> The value of this environment property specifies the fully qualified class name of the socket factory used by the LDAP provider. This class must implement the SocketFactory abstract class and provide an implementation of the static "getDefault()" method that returns an instance of the socket factory.
> 
> The implementation in the JDK default LDAP provider currently doesn't verify that the given class name points to a type which is `javax.net.SocketFactory`, nor does it verify that the correct expected `getDefault()` method exists. The changes in this PR addresses that issue and introduces a jtreg test to reproduce the issue and verify the fix.
> 
> Given the nature of this change, I believe a CSR will be needed which I'll file shortly.

Nice cleanup. I agree that CSR and release notes are needed. Thanks for drafting those already.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29706#pullrequestreview-3796190614

From jpai at openjdk.org  Fri Feb 13 10:15:24 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Feb 2026 10:15:24 GMT
Subject: RFR: 8377857: Add since checker test for java.naming module
In-Reply-To: <kCJw03XoQeIh2AFk8yjOOx9A_FF0it5LC3BaGMMwp44=.edb8083c-c3be-45c8-9fa7-16344b4679a2@github.com>
References: <i75aV2GS75Ug9CzaNXKrVq3TMB-t5cJFsrAaYe_puTI=.73e4f0f3-1fa7-4a6a-ab82-95dda2521682@github.com>
 <kCJw03XoQeIh2AFk8yjOOx9A_FF0it5LC3BaGMMwp44=.edb8083c-c3be-45c8-9fa7-16344b4679a2@github.com>
Message-ID: <9NjFXVzq3b7oELm_otfSTnQZ_WurOwH2enKs5_tC2yY=.e5c11b1d-0e6d-4f7c-829f-d3620e1eaa25@github.com>

On Fri, 13 Feb 2026 08:24:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Can I please get a review of this change which introduces a test to verify the usages of `@since` javadoc tags in the `java.naming` module? This addresses https://bugs.openjdk.org/browse/JDK-8377857.
>> 
>> The `SinceChecker` test utility has been in use for several modules, but wasn't added for java.naming. The commit in this PR adds one for that module.
>> 
>> The `SinceChecker` test utility does not handle the presence of a comma in (for example `@since X, Y`) correctly. The javadoc tag spec for `@since` allows that syntax https://docs.oracle.com/en/java/javase/25/docs/specs/javadoc/doc-comment-spec.html#since. As a workaround, the commit in this PR splits the `@since` on `javax.naming.InitialContext` class into two separate declarations (this too is allowed by the `@since` tag spec). I've verified that the generated javadoc continues to correctly show these values. I have also spoken to Nizar about this issue in SinceChecker and it will be addressed separately.
>
> src/java.naming/share/classes/javax/naming/InitialContext.java line 121:
> 
>> 119:  *      NamingManager.setInitialContextFactoryBuilder
>> 120:  * @since 1.3
>> 121:  * @since JNDI 1.1
> 
> Do we really need to keep `@since JNDI 1.1`?

Hello Alan, I am not familiar with the history of these JNDI APIs. I did a quick check and it looks like there are only a few places in the JDK where we refer to the JNDI version. For example, in `javax.naming.Context`:
> Prior to JNDI 1.2, all name arguments were treated as composite names.

and then in `javax.naming.directory.DirContext`:

* Prior to JNDI 1.2, this method
* returned a single schema object representing the class definition of
* the named object.
* Since JNDI 1.2, this method returns a {@code DirContext} containing
* all of the named object's class definitions.

and then are a few places which have this:


Use serialVersionUID from JNDI 1.1.1 for interoperability

on the `serialVersionUID` fields.

Do you suggest I remove the `@since JNDI 1.1` from `IntialContext`?

As a follow up, should we also remove/update the text refering to the JNDI versions in other places?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29705#discussion_r2803408352

From aefimov at openjdk.org  Fri Feb 13 10:43:31 2026
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 13 Feb 2026 10:43:31 GMT
Subject: RFR: 8049630: Custom socket factory is not checked for the
 existence of a getDefault() method
In-Reply-To: <JNvlWlAZn-EXjPRX4-1ZvbAUvOgGFdAqqLpEgeWAZks=.629f21c8-41ec-4156-b32f-d9bbc059938a@github.com>
References: <JNvlWlAZn-EXjPRX4-1ZvbAUvOgGFdAqqLpEgeWAZks=.629f21c8-41ec-4156-b32f-d9bbc059938a@github.com>
Message-ID: <2nLCY2YAu5fOP_xZiv5rJcKF5IznW5pP43bxO7vM4IA=.cd7f1f14-9dea-4f8a-8c23-826538b3a01b@github.com>

On Fri, 13 Feb 2026 02:19:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses the issues noted in https://bugs.openjdk.org/browse/JDK-8049630 and https://bugs.openjdk.org/browse/JDK-8049619?
> 
> The `java.naming` module allows for the `java.naming.ldap.factory.socket` environment property to be configured to point to the class name of the implementation of a `javax.net.SocketFactory`. As noted in the specification of that property https://docs.oracle.com/en/java/javase/25/docs/api/java.naming/module-summary.html:
> 
>> The value of this environment property specifies the fully qualified class name of the socket factory used by the LDAP provider. This class must implement the SocketFactory abstract class and provide an implementation of the static "getDefault()" method that returns an instance of the socket factory.
> 
> The implementation in the JDK default LDAP provider currently doesn't verify that the given class name points to a type which is `javax.net.SocketFactory`, nor does it verify that the correct expected `getDefault()` method exists. The changes in this PR addresses that issue and introduces a jtreg test to reproduce the issue and verify the fix.
> 
> Given the nature of this change, I believe a CSR will be needed which I'll file shortly.

Very good cleanup, and clarification of expectations for the `java.naming.ldap.factory.socket` JNDI/LDAP environment property value.
Looks good to me, thank you!

-------------

Marked as reviewed by aefimov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29706#pullrequestreview-3796562178

From jpai at openjdk.org  Fri Feb 13 10:46:55 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Feb 2026 10:46:55 GMT
Subject: RFR: 8377035: [s390x] Disable JSR166 test cases which uses virtual
 threads [v4]
In-Reply-To: <OSAHszZtIaX88M8YjSIwooS5ovO8OzrLu5jgteEv3Y8=.080b008c-a25c-4166-b67b-885b2c6b15eb@github.com>
References: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
 <OSAHszZtIaX88M8YjSIwooS5ovO8OzrLu5jgteEv3Y8=.080b008c-a25c-4166-b67b-885b2c6b15eb@github.com>
Message-ID: <C3uwcX1KQBxdjftNCcIMBRjVeIA4unzID9meuNv7acg=.7c1f3552-4897-4892-a625-f8394fa47ca0@github.com>

On Fri, 13 Feb 2026 05:23:18 GMT, Harshit470250 <duke at openjdk.org> wrote:

>> ReentrantReadWriteLock20Test.java is failing on s390 due to virtual threads which are not yet implemented on s390. 
>> SynchronousQueue20Test.java also uses virtual thread so I am also disabling it.
>
> Harshit470250 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change java20TestClassNames only if on s390

I ran this change against our CI and it went fine.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29555#pullrequestreview-3796565592

From duke at openjdk.org  Fri Feb 13 10:46:56 2026
From: duke at openjdk.org (Harshit470250)
Date: Fri, 13 Feb 2026 10:46:56 GMT
Subject: Integrated: 8377035: [s390x] Disable JSR166 test cases which uses
 virtual threads
In-Reply-To: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
References: <mF0JjhAQ4P5xUmqW7IDK1bH-hguappnzPQ5KT26dZsU=.08024b55-617d-4c6f-b160-22a351b904e5@github.com>
Message-ID: <3koMK7HHjsth6XyD504wTYYyaKEAC9HEfdqo1LOfe6o=.bb750245-2d51-47ac-b0d6-6eff951082cf@github.com>

On Wed, 4 Feb 2026 06:40:38 GMT, Harshit470250 <duke at openjdk.org> wrote:

> ReentrantReadWriteLock20Test.java is failing on s390 due to virtual threads which are not yet implemented on s390. 
> SynchronousQueue20Test.java also uses virtual thread so I am also disabling it.

This pull request has now been integrated.

Changeset: 4e7106d8
Author:    Harshit <harshitdhiman1402 at gmail.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e7106d8919652c1dcd4a501a11057e1a8179b3e
Stats:     14 lines in 1 file changed: 14 ins; 0 del; 0 mod

8377035: [s390x] Disable JSR166 test cases which uses virtual threads

Reviewed-by: jpai, alanb, amitkumar

-------------

PR: https://git.openjdk.org/jdk/pull/29555

From alanb at openjdk.org  Fri Feb 13 11:01:30 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Feb 2026 11:01:30 GMT
Subject: RFR: 8377857: Add since checker test for java.naming module
In-Reply-To: <9NjFXVzq3b7oELm_otfSTnQZ_WurOwH2enKs5_tC2yY=.e5c11b1d-0e6d-4f7c-829f-d3620e1eaa25@github.com>
References: <i75aV2GS75Ug9CzaNXKrVq3TMB-t5cJFsrAaYe_puTI=.73e4f0f3-1fa7-4a6a-ab82-95dda2521682@github.com>
 <kCJw03XoQeIh2AFk8yjOOx9A_FF0it5LC3BaGMMwp44=.edb8083c-c3be-45c8-9fa7-16344b4679a2@github.com>
 <9NjFXVzq3b7oELm_otfSTnQZ_WurOwH2enKs5_tC2yY=.e5c11b1d-0e6d-4f7c-829f-d3620e1eaa25@github.com>
Message-ID: <pi7BhTzk2dICwMzPqSyqhBvETbCiJLt5DEjD0-MmOl0=.01198804-9139-49f2-8ef4-9c170a643f65@github.com>

On Fri, 13 Feb 2026 10:11:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Do you suggest I remove the `@since JNDI 1.1` from `IntialContext`?

Yes, I think we should remove it with this update.

> As a follow up, should we also remove/update the text refering to the JNDI versions in other places?

That would be good, but low priority of course.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29705#discussion_r2803625500

From jpai at openjdk.org  Fri Feb 13 11:23:34 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Feb 2026 11:23:34 GMT
Subject: RFR: 8296183: jndiprovider.properties contains properties pointing to
 non-existing classes
Message-ID: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com>

Can I please get a review of this change which removes the unused `src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties` file? This addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8296183.

This `jndiprovider.properties` file lists 3 properties `java.naming.factory.control`, `java.naming.factory.object` and `java.naming.factory.state`. The semantics of these environment properties are explained in https://docs.oracle.com/javase/jndi/tutorial/beyond/env/provider.html. The classes configured in `com/sun/jndi/ldap/jndiprovider.properties` for each of these properties are non-existent in the JDK. Looking at the version control history of the JDK, these classes haven't been around for several releases (not even in JDK 8). The `jndiprovier.properties` gets looked up by an JDK internal class in the `java.naming` module - `com.sun.naming.internal.ResourceManager`. The `ResourceManager.getFactories(...)` method is the one that gets called to load the classes configured for those 3 environment properties. The javadoc of `ResourceManager.getFactories(...)` says this:


Retrieves an enumeration of factory classes/object specified by a property.

The property is gotten from the environment and the provider resource file associated with the given context and concatenated.
... The resulting property value is a list of class names.
This method then loads each class using the current thread's context class loader and keeps them in a list.
Any class that cannot be loaded is ignored.
...


The implementation of `ResourceManager.getFactories(...)` matches that javadoc. Because the implementation ignores such missing classes, the reference to these non-existent classes in the `com/sun/jndi/ldap/jndiprovider.properties` has gone unnoticed all this while. Manual experiments of exercising this code path does indeed show that a `ClassNotFoundException` gets raised (and ignored) for the classes referenced in that `jnidprovider.properties` file.

The commit in this PR removes the `jndiprovier.properties`. It also removes a javadoc reference to one of these non-existent classes. Given the nature of the change no new tests have been introduced and the existing tests in tier1, tier2 and tier3 continue to pass.

-------------

Commit messages:
 - remove reference to a non-existent class from @see of EntryChangeResponseControl
 - 8296183: jndiprovider.properties contains properties pointing to non-existing classes

Changes: https://git.openjdk.org/jdk/pull/29712/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29712&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296183
  Stats: 21 lines in 3 files changed: 0 ins; 19 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/29712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29712/head:pull/29712

PR: https://git.openjdk.org/jdk/pull/29712

From jpai at openjdk.org  Fri Feb 13 11:28:17 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Feb 2026 11:28:17 GMT
Subject: RFR: 8377857: Add since checker test for java.naming module [v2]
In-Reply-To: <pi7BhTzk2dICwMzPqSyqhBvETbCiJLt5DEjD0-MmOl0=.01198804-9139-49f2-8ef4-9c170a643f65@github.com>
References: <i75aV2GS75Ug9CzaNXKrVq3TMB-t5cJFsrAaYe_puTI=.73e4f0f3-1fa7-4a6a-ab82-95dda2521682@github.com>
 <kCJw03XoQeIh2AFk8yjOOx9A_FF0it5LC3BaGMMwp44=.edb8083c-c3be-45c8-9fa7-16344b4679a2@github.com>
 <9NjFXVzq3b7oELm_otfSTnQZ_WurOwH2enKs5_tC2yY=.e5c11b1d-0e6d-4f7c-829f-d3620e1eaa25@github.com>
 <pi7BhTzk2dICwMzPqSyqhBvETbCiJLt5DEjD0-MmOl0=.01198804-9139-49f2-8ef4-9c170a643f65@github.com>
Message-ID: <VdK7vbuuweQ2p1mWJ3VwojXpJA4GvivikXYhmsjpBGg=.efe8165f-223b-4150-bc71-a821be5226b9@github.com>

On Fri, 13 Feb 2026 10:58:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hello Alan, I am not familiar with the history of these JNDI APIs. I did a quick check and it looks like there are only a few places in the JDK where we refer to the JNDI version. For example, in `javax.naming.Context`:
>>> Prior to JNDI 1.2, all name arguments were treated as composite names.
>> 
>> and then in `javax.naming.directory.DirContext`:
>> 
>> * Prior to JNDI 1.2, this method
>> * returned a single schema object representing the class definition of
>> * the named object.
>> * Since JNDI 1.2, this method returns a {@code DirContext} containing
>> * all of the named object's class definitions.
>> 
>> and then are a few places which have this:
>> 
>> 
>> Use serialVersionUID from JNDI 1.1.1 for interoperability
>> 
>> on the `serialVersionUID` fields.
>> 
>> Do you suggest I remove the `@since JNDI 1.1` from `IntialContext`?
>> 
>> As a follow up, should we also remove/update the text refering to the JNDI versions in other places?
>
>> Do you suggest I remove the `@since JNDI 1.1` from `IntialContext`?
> 
> Yes, I think we should remove it with this update.
> 
>> As a follow up, should we also remove/update the text refering to the JNDI versions in other places?
> 
> That would be good, but low priority of course.

Done, I've updated the PR to remove the `@since JNDI 1.1` from `InitialContext`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29705#discussion_r2803726256

From jpai at openjdk.org  Fri Feb 13 11:28:16 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Feb 2026 11:28:16 GMT
Subject: RFR: 8377857: Add since checker test for java.naming module [v2]
In-Reply-To: <i75aV2GS75Ug9CzaNXKrVq3TMB-t5cJFsrAaYe_puTI=.73e4f0f3-1fa7-4a6a-ab82-95dda2521682@github.com>
References: <i75aV2GS75Ug9CzaNXKrVq3TMB-t5cJFsrAaYe_puTI=.73e4f0f3-1fa7-4a6a-ab82-95dda2521682@github.com>
Message-ID: <qHKyK1ANNWaYg1H5xJUk_ihQhou2tJVMCgS6KC72vvw=.920f7da7-9956-4ec2-a0e1-b24e0e47cf3b@github.com>

> Can I please get a review of this change which introduces a test to verify the usages of `@since` javadoc tags in the `java.naming` module? This addresses https://bugs.openjdk.org/browse/JDK-8377857.
> 
> The `SinceChecker` test utility has been in use for several modules, but wasn't added for java.naming. The commit in this PR adds one for that module.
> 
> The `SinceChecker` test utility does not handle the presence of a comma in (for example `@since X, Y`) correctly. The javadoc tag spec for `@since` allows that syntax https://docs.oracle.com/en/java/javase/25/docs/specs/javadoc/doc-comment-spec.html#since. As a workaround, the commit in this PR splits the `@since` on `javax.naming.InitialContext` class into two separate declarations (this too is allowed by the `@since` tag spec). I've verified that the generated javadoc continues to correctly show these values. I have also spoken to Nizar about this issue in SinceChecker and it will be addressed separately.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  remove reference to JNDI 1.1 in InitialContext

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29705/files
  - new: https://git.openjdk.org/jdk/pull/29705/files/aeb89dc7..c92b0872

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29705&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29705&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29705.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29705/head:pull/29705

PR: https://git.openjdk.org/jdk/pull/29705

From dfuchs at openjdk.org  Fri Feb 13 12:05:20 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Feb 2026 12:05:20 GMT
Subject: RFR: 8296183: jndiprovider.properties contains properties pointing
 to non-existing classes
In-Reply-To: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com>
References: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com>
Message-ID: <wNxiigIGBq7nnSV1f9QeR7GPppcjM9eAqDF9YWUJkOc=.d7b83dc1-6686-45ea-b5c9-f82dfe0c78f5@github.com>

On Fri, 13 Feb 2026 11:15:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes the unused `src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties` file? This addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8296183.
> 
> This `jndiprovider.properties` file lists 3 properties `java.naming.factory.control`, `java.naming.factory.object` and `java.naming.factory.state`. The semantics of these environment properties are explained in https://docs.oracle.com/javase/jndi/tutorial/beyond/env/provider.html. The classes configured in `com/sun/jndi/ldap/jndiprovider.properties` for each of these properties are non-existent in the JDK. Looking at the version control history of the JDK, these classes haven't been around for several releases (not even in JDK 8). The `jndiprovier.properties` gets looked up by an JDK internal class in the `java.naming` module - `com.sun.naming.internal.ResourceManager`. The `ResourceManager.getFactories(...)` method is the one that gets called to load the classes configured for those 3 environment properties. The javadoc of `ResourceManager.getFactories(...)` says this:
> 
> 
> Retrieves an enumeration of factory classes/object specified by a property.
> 
> The property is gotten from the environment and the provider resource file associated with the given context and concatenated.
> ... The resulting property value is a list of class names.
> This method then loads each class using the current thread's context class loader and keeps them in a list.
> Any class that cannot be loaded is ignored.
> ...
> 
> 
> The implementation of `ResourceManager.getFactories(...)` matches that javadoc. Because the implementation ignores such missing classes, the reference to these non-existent classes in the `com/sun/jndi/ldap/jndiprovider.properties` has gone unnoticed all this while. Manual experiments of exercising this code path does indeed show that a `ClassNotFoundException` gets raised (and ignored) for the classes referenced in that `jnidprovider.properties` file.
> 
> The commit in this PR removes the `jndiprovier.properties`. It also removes a javadoc reference to one of these non-existent classes. Given the nature of the change no new tests have been introduced and the existing tests in tier1, tier2 and tier3 continue to pass.

Generally looks good to me. Good to avoid those unneeded CNFE. If backported, some more checks might be required on JDK 8 - as CORBA is still supported there.

src/java.naming/share/classes/com/sun/jndi/ldap/EntryChangeResponseControl.java line 54:

> 52:  *
> 53:  * @see PersistentSearchControl
> 54:  */

Not that it matters much, but I see that `DefaultResponseControlFactory` and `PersistentSearchControl` both have an `@see EntryChangeResponseControl` so I'd suggest to replace:


-  * @see com.sun.jndi.ldap.ctl.ResponseControlFactory ResponseControlFactory
+  * @see DefaultResponseControlFactory

-------------

PR Review: https://git.openjdk.org/jdk/pull/29712#pullrequestreview-3796864479
PR Review Comment: https://git.openjdk.org/jdk/pull/29712#discussion_r2803848914

From jpai at openjdk.org  Fri Feb 13 12:14:28 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Feb 2026 12:14:28 GMT
Subject: RFR: 8296183: jndiprovider.properties contains properties pointing
 to non-existing classes [v2]
In-Reply-To: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com>
References: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com>
Message-ID: <y14p-e5AulGqByGkPLHzA6Uj7K5jhTUKYY-9QdoqLLU=.13990294-8e6f-4a06-b4c3-28a1cffb9b10@github.com>

> Can I please get a review of this change which removes the unused `src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties` file? This addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8296183.
> 
> This `jndiprovider.properties` file lists 3 properties `java.naming.factory.control`, `java.naming.factory.object` and `java.naming.factory.state`. The semantics of these environment properties are explained in https://docs.oracle.com/javase/jndi/tutorial/beyond/env/provider.html. The classes configured in `com/sun/jndi/ldap/jndiprovider.properties` for each of these properties are non-existent in the JDK. Looking at the version control history of the JDK, these classes haven't been around for several releases (not even in JDK 8). The `jndiprovier.properties` gets looked up by an JDK internal class in the `java.naming` module - `com.sun.naming.internal.ResourceManager`. The `ResourceManager.getFactories(...)` method is the one that gets called to load the classes configured for those 3 environment properties. The javadoc of `ResourceManager.getFactories(...)` says this:
> 
> 
> Retrieves an enumeration of factory classes/object specified by a property.
> 
> The property is gotten from the environment and the provider resource file associated with the given context and concatenated.
> ... The resulting property value is a list of class names.
> This method then loads each class using the current thread's context class loader and keeps them in a list.
> Any class that cannot be loaded is ignored.
> ...
> 
> 
> The implementation of `ResourceManager.getFactories(...)` matches that javadoc. Because the implementation ignores such missing classes, the reference to these non-existent classes in the `com/sun/jndi/ldap/jndiprovider.properties` has gone unnoticed all this while. Manual experiments of exercising this code path does indeed show that a `ClassNotFoundException` gets raised (and ignored) for the classes referenced in that `jnidprovider.properties` file.
> 
> The commit in this PR removes the `jndiprovier.properties`. It also removes a javadoc reference to one of these non-existent classes. Given the nature of the change no new tests have been introduced and the existing tests in tier1, tier2 and tier3 continue to pass.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  add reference to DefaultResponseControlFactory in javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29712/files
  - new: https://git.openjdk.org/jdk/pull/29712/files/1864e84a..b68385a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29712&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29712&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29712/head:pull/29712

PR: https://git.openjdk.org/jdk/pull/29712

From dfuchs at openjdk.org  Fri Feb 13 12:14:28 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Feb 2026 12:14:28 GMT
Subject: RFR: 8296183: jndiprovider.properties contains properties pointing
 to non-existing classes [v2]
In-Reply-To: <y14p-e5AulGqByGkPLHzA6Uj7K5jhTUKYY-9QdoqLLU=.13990294-8e6f-4a06-b4c3-28a1cffb9b10@github.com>
References: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com>
 <y14p-e5AulGqByGkPLHzA6Uj7K5jhTUKYY-9QdoqLLU=.13990294-8e6f-4a06-b4c3-28a1cffb9b10@github.com>
Message-ID: <RNaXlL4AVCVWSbHc6rJ_KDslV4vj82KPcUipA3mKyIE=.ce4c9abe-2f8a-4e7c-b1de-3793e236ed34@github.com>

On Fri, 13 Feb 2026 12:11:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes the unused `src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties` file? This addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8296183.
>> 
>> This `jndiprovider.properties` file lists 3 properties `java.naming.factory.control`, `java.naming.factory.object` and `java.naming.factory.state`. The semantics of these environment properties are explained in https://docs.oracle.com/javase/jndi/tutorial/beyond/env/provider.html. The classes configured in `com/sun/jndi/ldap/jndiprovider.properties` for each of these properties are non-existent in the JDK. Looking at the version control history of the JDK, these classes haven't been around for several releases (not even in JDK 8). The `jndiprovier.properties` gets looked up by an JDK internal class in the `java.naming` module - `com.sun.naming.internal.ResourceManager`. The `ResourceManager.getFactories(...)` method is the one that gets called to load the classes configured for those 3 environment properties. The javadoc of `ResourceManager.getFactories(...)` says this:
>> 
>> 
>> Retrieves an enumeration of factory classes/object specified by a property.
>> 
>> The property is gotten from the environment and the provider resource file associated with the given context and concatenated.
>> ... The resulting property value is a list of class names.
>> This method then loads each class using the current thread's context class loader and keeps them in a list.
>> Any class that cannot be loaded is ignored.
>> ...
>> 
>> 
>> The implementation of `ResourceManager.getFactories(...)` matches that javadoc. Because the implementation ignores such missing classes, the reference to these non-existent classes in the `com/sun/jndi/ldap/jndiprovider.properties` has gone unnoticed all this while. Manual experiments of exercising this code path does indeed show that a `ClassNotFoundException` gets raised (and ignored) for the classes referenced in that `jnidprovider.properties` file.
>> 
>> The commit in this PR removes the `jndiprovier.properties`. It also removes a javadoc reference to one of these non-existent classes. Given the nature of the change no new tests have been introduced and the existing tests in tier1, tier2 and tier3 continue to pass.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add reference to DefaultResponseControlFactory in javadoc

Would be good to get @AlekseiEfimov approval before integrating.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29712#pullrequestreview-3796912823

From jpai at openjdk.org  Fri Feb 13 12:14:30 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Feb 2026 12:14:30 GMT
Subject: RFR: 8296183: jndiprovider.properties contains properties pointing
 to non-existing classes [v2]
In-Reply-To: <wNxiigIGBq7nnSV1f9QeR7GPppcjM9eAqDF9YWUJkOc=.d7b83dc1-6686-45ea-b5c9-f82dfe0c78f5@github.com>
References: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com>
 <wNxiigIGBq7nnSV1f9QeR7GPppcjM9eAqDF9YWUJkOc=.d7b83dc1-6686-45ea-b5c9-f82dfe0c78f5@github.com>
Message-ID: <zydz_15nmzhO-X6__Tgb7HzemxTysD0clMar7XGuUAU=.65f3652e-a4dd-4a67-a24b-0547e724e477@github.com>

On Fri, 13 Feb 2026 11:57:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add reference to DefaultResponseControlFactory in javadoc
>
> src/java.naming/share/classes/com/sun/jndi/ldap/EntryChangeResponseControl.java line 54:
> 
>> 52:  *
>> 53:  * @see PersistentSearchControl
>> 54:  */
> 
> Not that it matters much, but I see that `DefaultResponseControlFactory` and `PersistentSearchControl` both have an `@see EntryChangeResponseControl` so I'd suggest to replace:
> 
> 
> -  * @see com.sun.jndi.ldap.ctl.ResponseControlFactory ResponseControlFactory
> +  * @see DefaultResponseControlFactory

That's a good point, I've updated the PR accordingly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29712#discussion_r2803888024

From asemenyuk at openjdk.org  Fri Feb 13 13:16:06 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 13 Feb 2026 13:16:06 GMT
Subject: RFR: 8374222: jpackage will exit with error if it fails to clean the
 temp directory
Message-ID: <slkcuguuN_dOz_pjLZs_xVDEy0aGeTjk6BiBs5fawzU=.245d6070-5d05-4d4a-a923-414b4cbe515d@github.com>

jpackage will attempt to delete the temp directory a few times. If all attempts fail, it will print remaining files and empty directories (100 entries at most) to the console and continue. It will not exit with an error status as previously, as this is not a critical error.

-------------

Commit messages:
 - Applied blessed-modifier-order.sh
 - TempDirectory: drop redundant synchronization (presumably Files.walkFileTree() will not call method on the supplied FileVisitor concurrently); Better coverage, fix a bug in the implementation.
 - PathDeletionPreventer: helper that encapsulates platform specifics to lock a file or directory and cause IOException in tests when trying to delete it
 - 8374222: jpackage will exit with error if it failes to clean the temp directory

Changes: https://git.openjdk.org/jdk/pull/29664/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29664&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374222
  Stats: 880 lines in 5 files changed: 863 ins; 7 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/29664.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29664/head:pull/29664

PR: https://git.openjdk.org/jdk/pull/29664

From asemenyuk at openjdk.org  Fri Feb 13 13:16:06 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 13 Feb 2026 13:16:06 GMT
Subject: RFR: 8374222: jpackage will exit with error if it fails to clean
 the temp directory
In-Reply-To: <slkcuguuN_dOz_pjLZs_xVDEy0aGeTjk6BiBs5fawzU=.245d6070-5d05-4d4a-a923-414b4cbe515d@github.com>
References: <slkcuguuN_dOz_pjLZs_xVDEy0aGeTjk6BiBs5fawzU=.245d6070-5d05-4d4a-a923-414b4cbe515d@github.com>
Message-ID: <GTpHgxo4j7Z7N07QdU8jEmuxEe2lepjNoTF4Z6vfhNY=.32128573-0bfb-4fb0-8da2-e4d5bcbd9e6d@github.com>

On Wed, 11 Feb 2026 04:13:53 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> jpackage will attempt to delete the temp directory a few times. If all attempts fail, it will print remaining files and empty directories (100 entries at most) to the console and continue. It will not exit with an error status as previously, as this is not a critical error.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29664#issuecomment-3897174982

From duke at openjdk.org  Fri Feb 13 13:21:24 2026
From: duke at openjdk.org (David Beaumont)
Date: Fri, 13 Feb 2026 13:21:24 GMT
Subject: Withdrawn: 8372301: Improve error message for jimage command line tool
 regarding version mismatch
In-Reply-To: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com>
References: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com>
Message-ID: <8A7U5DDwCFZ21WmVbu1pjDgUK7sjFAtAJjjSCX7fKSQ=.3e111910-6c15-4981-8753-2e8f8db04d14@github.com>

On Fri, 21 Nov 2025 16:32:49 GMT, David Beaumont <duke at openjdk.org> wrote:

> Adds a semantic reason for failure which can be optionally interrogated by calling code.
> Use the 'Reason.BAD_VERSION' value to trigger a different translated error message from the JImageTask.
> 
> I would consider moving the error message string into the Reason enum to simplify the code triggering the error and avoid message string duplication, but it's not straightforward due to the need to supply the version numbers.
> 
> We can use this approach to provide translated messages for all the distinct failure reasons if needed.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/28456

From dfenacci at openjdk.org  Fri Feb 13 13:43:04 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Fri, 13 Feb 2026 13:43:04 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v2]
In-Reply-To: <E3MpThx86Yu3C_JpWtNTcoc_WJ5DX5ohKb1j1LmAn84=.b84c33bd-9ea4-433f-bc38-6176b0345a48@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
 <KeNqd83bGg0oPTyA4m5C8HB_F5q5r4jcY_ac96NNMI4=.74f069e3-4ba1-44b2-b9ac-6d84a745d8cb@github.com>
 <E3MpThx86Yu3C_JpWtNTcoc_WJ5DX5ohKb1j1LmAn84=.b84c33bd-9ea4-433f-bc38-6176b0345a48@github.com>
Message-ID: <nPUx9Q4Pw4HQzeALsKmOtT40seJxjHd01XO-rxTMenk=.08d87407-2a65-410d-ad9a-54ae89fdb6f4@github.com>

On Thu, 12 Feb 2026 16:09:45 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringLatin1.java line 172:
>> 
>>> 170:         Objects.requireNonNull(other);
>>> 171:         String.checkOffset(len1, length(value));
>>> 172:         String.checkOffset(len2, length(other));
>> 
>> Are these additional checks? I'm asking because I was expecting them to "replace" intrinsics ones but couldn't find where/how (if so I'm also wondering why they were not there before: did all callers ensure that?).
>
>> Are these additional checks?
> 
> Yes. I'm exercising _"Always validate all input at the Java wrapper"_ stated in the parent issue [JDK-8156534].
> 
>> I'm asking because I was expecting them to "replace" intrinsics ones but couldn't find where/how
> 
> Note the Javadoc of `ArraysSupport#mismatch(byte[] a, byte[] b, int length)`:
> 
>     This method does not perform bounds checks. It is the responsibility
>     of the caller to perform such bounds checks before calling this method.
> 
> AFAICT, `ArraysSupport` should be updated to validate its inputs too. But that is for another day.
> 
>> I'm also wondering why they were not there before: did all callers ensure that?
> 
> Yes, pretty much accidentally.
> 
> [JDK-8156534]: https://bugs.openjdk.org/browse/JDK-8156534

Thanks for the clarification @vy. A bit scary if it was really accidental.
Anyway, C2 should fold the check if unnecessary but maybe a performance check before and after could be nice (just to be on the safe side).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804280137

From alanb at openjdk.org  Fri Feb 13 13:51:14 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Feb 2026 13:51:14 GMT
Subject: RFR: 8377857: Add since checker test for java.naming module [v2]
In-Reply-To: <qHKyK1ANNWaYg1H5xJUk_ihQhou2tJVMCgS6KC72vvw=.920f7da7-9956-4ec2-a0e1-b24e0e47cf3b@github.com>
References: <i75aV2GS75Ug9CzaNXKrVq3TMB-t5cJFsrAaYe_puTI=.73e4f0f3-1fa7-4a6a-ab82-95dda2521682@github.com>
 <qHKyK1ANNWaYg1H5xJUk_ihQhou2tJVMCgS6KC72vvw=.920f7da7-9956-4ec2-a0e1-b24e0e47cf3b@github.com>
Message-ID: <x9J2JFjMPmnDbZkIbndjEBQx5PO1v8wWdWtAeuoVMrs=.92d978ab-90b4-4ead-abfd-0cdbc1d8cc0a@github.com>

On Fri, 13 Feb 2026 11:28:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which introduces a test to verify the usages of `@since` javadoc tags in the `java.naming` module? This addresses https://bugs.openjdk.org/browse/JDK-8377857.
>> 
>> The `SinceChecker` test utility has been in use for several modules, but wasn't added for java.naming. The commit in this PR adds one for that module.
>> 
>> The `SinceChecker` test utility does not handle the presence of a comma in (for example `@since X, Y`) correctly. The javadoc tag spec for `@since` allows that syntax https://docs.oracle.com/en/java/javase/25/docs/specs/javadoc/doc-comment-spec.html#since. As a workaround, the commit in this PR splits the `@since` on `javax.naming.InitialContext` class into two separate declarations (this too is allowed by the `@since` tag spec). I've verified that the generated javadoc continues to correctly show these values. I have also spoken to Nizar about this issue in SinceChecker and it will be addressed separately.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove reference to JNDI 1.1 in InitialContext

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29705#pullrequestreview-3797389263

From alanb at openjdk.org  Fri Feb 13 13:51:17 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Feb 2026 13:51:17 GMT
Subject: RFR: 8377857: Add since checker test for java.naming module [v2]
In-Reply-To: <VdK7vbuuweQ2p1mWJ3VwojXpJA4GvivikXYhmsjpBGg=.efe8165f-223b-4150-bc71-a821be5226b9@github.com>
References: <i75aV2GS75Ug9CzaNXKrVq3TMB-t5cJFsrAaYe_puTI=.73e4f0f3-1fa7-4a6a-ab82-95dda2521682@github.com>
 <kCJw03XoQeIh2AFk8yjOOx9A_FF0it5LC3BaGMMwp44=.edb8083c-c3be-45c8-9fa7-16344b4679a2@github.com>
 <9NjFXVzq3b7oELm_otfSTnQZ_WurOwH2enKs5_tC2yY=.e5c11b1d-0e6d-4f7c-829f-d3620e1eaa25@github.com>
 <pi7BhTzk2dICwMzPqSyqhBvETbCiJLt5DEjD0-MmOl0=.01198804-9139-49f2-8ef4-9c170a643f65@github.com>
 <VdK7vbuuweQ2p1mWJ3VwojXpJA4GvivikXYhmsjpBGg=.efe8165f-223b-4150-bc71-a821be5226b9@github.com>
Message-ID: <Bg9G7N9Jcr2dfHzh3wY7y9Nyp3V2UNlVdQbcu0IwpnY=.c6d6ebdb-12fa-43fb-bf99-1f2a3e6d72b0@github.com>

On Fri, 13 Feb 2026 11:24:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> Do you suggest I remove the `@since JNDI 1.1` from `IntialContext`?
>> 
>> Yes, I think we should remove it with this update.
>> 
>>> As a follow up, should we also remove/update the text refering to the JNDI versions in other places?
>> 
>> That would be good, but low priority of course.
>
> Done, I've updated the PR to remove the `@since JNDI 1.1` from `InitialContext`.

Thanks. When I initially say it when I expected there might be more tags left over from before JNDI was integrated in JDK 1.3 but it seems not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29705#discussion_r2804316331

From rgiulietti at openjdk.org  Fri Feb 13 14:09:35 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 13 Feb 2026 14:09:35 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v2]
In-Reply-To: <rObgPuAWe3qMxqlDCoOSR4Tpj9zHt6g8kb68ATCOCig=.9fce9ad3-8254-489f-9585-1624465da04c@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
 <rObgPuAWe3qMxqlDCoOSR4Tpj9zHt6g8kb68ATCOCig=.9fce9ad3-8254-489f-9585-1624465da04c@github.com>
Message-ID: <kVUXENAo0flzVsMI_T417pqGbNm7hu7vPpuRyDiBO5c=.04899a9b-bb8b-4436-be12-92ed2e005665@github.com>

On Thu, 12 Feb 2026 16:11:25 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Moves input validation checks to Java for `java.lang.StringLatin1` intrinsics. While doing so, affected `java.lang.StringUTF16` methods needed to be updated due to relaxed checks at intrinsics. The javadocs of the touched methods are extensively overhauled.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply review feedback

src/java.base/share/classes/java/lang/StringLatin1.java line 174:

> 172:         String.checkOffset(len2, length(other));
> 173:         int lim = Math.min(len1, len2);
> 174:         int k = ArraysSupport.mismatch(value, other, lim);

>From the `mismatch()` doc it isn't clear that the returned index (if not negative) is the _smallest_ one locating a mismatch.
Without this guarantee, this `compareTo()` method might return an incorrect value.

src/java.base/share/classes/java/lang/StringLatin1.java line 199:

> 197:     // inline_string_compareTo
> 198:     @IntrinsicCandidate
> 199:     private static int compareToUTF16_0(byte[] value, byte[] other) {

I guess the `_` is to visually separate the 16 from the conventional 0?
Other intrinsics names, e.g., `compareTo0()` do not use a separator.

src/java.base/share/classes/java/lang/StringLatin1.java line 242:

> 240:     static int compareToCI(byte[] value, byte[] other) {
> 241:         int len1 = value.length;    // Implicit null check on `value`
> 242:         int len2 = other.length;    // Implicit null check on `other`

Alternatively, if you prefer

Suggestion:

        int len1 = value.length;    // fail fast on null
        int len2 = other.length;    // fail fast on null

src/java.base/share/classes/java/lang/StringLatin1.java line 265:

> 263:     static int compareToCI_UTF16(byte[] value, byte[] other) {
> 264:         Objects.requireNonNull(value);
> 265:         Objects.requireNonNull(other);

You could leave these checks out and rely on the following two lines for a fast fail on `null`, similarly to the latin1 case above.
But adding the checks looks cleaner.

src/java.base/share/classes/java/lang/StringLatin1.java line 428:

> 426:      *
> 427:      * @throws NullPointerException if {@code value} is null
> 428:      * @throws StringIndexOutOfBoundsException if the sub-ranges are out of bounds

Suggestion:

     * @throws StringIndexOutOfBoundsException if the sub-range is out of bounds

src/java.base/share/classes/java/lang/StringLatin1.java line 508:

> 506:     @IntrinsicCandidate
> 507:     private static int indexOf0(byte[] value, int valueToIndex, byte[] str, int strToIndex, int valueFromIndex) {
> 508:         byte first = str[0];

There's no protection in the 5 parameter caller agains an empty (0 length) `str`, so this can throw.
I didn't look at the intrinsic to verify whether it assumes `str.length` > 0.

src/java.base/share/classes/java/lang/StringLatin1.java line 1025:

> 1023: 
> 1024:     /**
> 1025:      * Exhaustively copies characters from a Latin-1 string byte array sub-range

Stylistically, why "Exhaustively"?

src/java.base/share/classes/java/lang/StringLatin1.java line 1072:

> 1070:     static void inflate(byte[] src, int srcOff, byte[] dst, int dstOff, int len) {
> 1071:         String.checkBoundsOffCount(srcOff, len, src.length);    // Implicit null check on `src`
> 1072:         Objects.requireNonNull(dst);

As above, you could rely on `StringUTF16.length(dst)` below to fail fast on `null`.
But it looks fine as it is now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804047503
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804059770
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804087560
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804122486
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804136126
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804205561
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804292351
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804301436

From rgiulietti at openjdk.org  Fri Feb 13 14:33:52 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 13 Feb 2026 14:33:52 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v2]
In-Reply-To: <rObgPuAWe3qMxqlDCoOSR4Tpj9zHt6g8kb68ATCOCig=.9fce9ad3-8254-489f-9585-1624465da04c@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
 <rObgPuAWe3qMxqlDCoOSR4Tpj9zHt6g8kb68ATCOCig=.9fce9ad3-8254-489f-9585-1624465da04c@github.com>
Message-ID: <lrVKSGdSJ-ZrfInsRoKrszqlR_f5FpCi6iVrHNMTodc=.54b8dd06-1d0e-4e49-b91f-d3eba64bb014@github.com>

On Thu, 12 Feb 2026 16:11:25 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Moves input validation checks to Java for `java.lang.StringLatin1` intrinsics. While doing so, affected `java.lang.StringUTF16` methods needed to be updated due to relaxed checks at intrinsics. The javadocs of the touched methods are extensively overhauled.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply review feedback

src/java.base/share/classes/java/lang/StringUTF16.java line 407:

> 405:      * @param srcOff the index (inclusive) of the first character in {@code src}
> 406:      * @param dst the target Latin-1 string byte array
> 407:      * @param srcOff the index (inclusive) of the first character in {@code dst}

Suggestion:

     * @param dstOff the index (inclusive) of the first character in {@code dst}

src/java.base/share/classes/java/lang/StringUTF16.java line 437:

> 435: 
> 436:     /**
> 437:      * Copies the prefix of Latin-1 characters from a UTF-16 string byte array

Since there are offsets, strictly speaking this is not a prefix but a general subrange.

src/java.base/share/classes/java/lang/StringUTF16.java line 499:

> 497: 
> 498:     @IntrinsicCandidate
> 499:     static void getChars(byte[] value, int srcBegin, int srcEnd, char[] dst, int dstBegin) {

What about this intrinsic? It doesn't seem to follow the conventions about `private` and a gatekeeper method.

src/java.base/share/classes/java/lang/StringUTF16.java line 623:

> 621:         Objects.requireNonNull(other);
> 622:         checkOffset(len1, value);
> 623:         String.checkOffset(len2, StringLatin1.length(other));

FYI, all these checks are already performed in the called (non-intrinsic) method.

src/java.base/share/classes/java/lang/StringUTF16.java line 726:

> 724:     static int compareToCI_Latin1(byte[] value, byte[] other) {
> 725:         Objects.requireNonNull(value);
> 726:         Objects.requireNonNull(other);

FYI, checks are already performed in the called method.

src/java.base/share/classes/java/lang/StringUTF16.java line 892:

> 890:     }
> 891: 
> 892:     private static int indexOfUnsafe(byte[] value, int valueToIndex, byte[] str, int strToIndex, int valueFromIndex) {

I think this method requires documentation about what it assumes about the arguments.
While it can be somehow derived from its usages, it would help to have it located here.

src/java.base/share/classes/java/lang/StringUTF16.java line 981:

> 979:     }
> 980: 
> 981:     private static int indexOfLatin1Unsafe(byte[] src, int srcCount, byte[] tgt, int tgtCount, int fromIndex) {

Similarly to above, documenting the expectations about the arguments here would help.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804366706
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804382508
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804368864
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804413083
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804428055
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804470315
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804488037

From rgiulietti at openjdk.org  Fri Feb 13 14:33:54 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 13 Feb 2026 14:33:54 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v2]
In-Reply-To: <lrVKSGdSJ-ZrfInsRoKrszqlR_f5FpCi6iVrHNMTodc=.54b8dd06-1d0e-4e49-b91f-d3eba64bb014@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
 <rObgPuAWe3qMxqlDCoOSR4Tpj9zHt6g8kb68ATCOCig=.9fce9ad3-8254-489f-9585-1624465da04c@github.com>
 <lrVKSGdSJ-ZrfInsRoKrszqlR_f5FpCi6iVrHNMTodc=.54b8dd06-1d0e-4e49-b91f-d3eba64bb014@github.com>
Message-ID: <FAK36ciAgDvCTDrdg7JZmuN6iToaY0S4S5MzULPYwxY=.bbe4f159-dd6e-46ce-841b-bc7bb46a3ebb@github.com>

On Fri, 13 Feb 2026 14:25:17 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply review feedback
>
> src/java.base/share/classes/java/lang/StringUTF16.java line 981:
> 
>> 979:     }
>> 980: 
>> 981:     private static int indexOfLatin1Unsafe(byte[] src, int srcCount, byte[] tgt, int tgtCount, int fromIndex) {
> 
> Similarly to above, documenting the expectations about the arguments here would help.

Be aware that I didn't review the native code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804516345

From asemenyuk at openjdk.org  Fri Feb 13 14:34:06 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 13 Feb 2026 14:34:06 GMT
Subject: RFR: 8377897: jpackage: make jdk.jpackage.internal.MockUtils available
 from other packages
Message-ID: <OkOhOuHJ59h2vCWGp4zbAGicavnLAQqxBw9JFec2dPM=.4509f1cf-b127-4da5-ab7f-5ff80d41d72e@github.com>

- Move jdk.jpackage.internal.MockUtils to jdk.jpackage.test.stdmock.JPackageMockUtils
 - Make ObjectFactory, ExecutorFactory, RetryExecutorFactory, and Executor accessible for creating jpackage mocks in tests outside the jdk.jpackage.internal package

-------------

Commit messages:
 - Make ObjectFactory, ExecutorFactory, RetryExecutorFactory, and Executor accessible for creating jpackage mocks in tests outside the jdk.jpackage.internal package. Relocate MockUtils from jdk.jpackage.internal to jdk.jpackage.test.stdmock.JPackageMockUtils. The jdk.jpackage.test.stdmock package will contain jpackage-specific mock implementations.
 - DefaultBundlingEnvironment: move CachingSupplier to the utils package and fix a race condition (with AtomicReference it allowed calling the supplier twice)

Changes: https://git.openjdk.org/jdk/pull/29536/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29536&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377897
  Stats: 786 lines in 20 files changed: 467 ins; 266 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/29536.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29536/head:pull/29536

PR: https://git.openjdk.org/jdk/pull/29536

From vyazici at openjdk.org  Fri Feb 13 14:41:15 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 13 Feb 2026 14:41:15 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v3]
In-Reply-To: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
Message-ID: <E3qzBi5gU-nacnKGfL1uS3GN3MddJxFHsfYTmIL7v8g=.2004756b-c96a-4194-a69d-cd343f446ab4@github.com>

> Moves input validation checks to Java for `java.lang.StringLatin1` intrinsics. While doing so, affected `java.lang.StringUTF16` methods needed to be updated due to relaxed checks at intrinsics. The javadocs of the touched methods are extensively overhauled.

Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:

 - Use `vmIntrinsics::*` to refer to intrinsics from Java
 - Improve vertical alignment in `vmIntrinsics.hpp`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28832/files
  - new: https://git.openjdk.org/jdk/pull/28832/files/068eb358..9bb6cdee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28832&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28832&range=01-02

  Stats: 20 lines in 3 files changed: 0 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/28832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28832/head:pull/28832

PR: https://git.openjdk.org/jdk/pull/28832

From eirbjo at gmail.com  Fri Feb 13 14:58:24 2026
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 13 Feb 2026 15:58:24 +0100
Subject: RFD: A plan to untangle ZipFile.Source.initCEN
In-Reply-To: <A29CA46B-32BB-41D0-8B09-871296A8E2E7@oracle.com>
References: <CA+pBWhsOxYX7+efPQVMk8c_XWBf5sG0oDrVURq1kM5xAocKiGA@mail.gmail.com>
 <A29CA46B-32BB-41D0-8B09-871296A8E2E7@oracle.com>
Message-ID: <CA+pBWhsSYaqx0n1YPk2pVNT7pvfcSGFQN62QfHrqh843bcBtYA@mail.gmail.com>

On Tue, Feb 10, 2026 at 7:24?PM Lance Andersen <lance.andersen at oracle.com>
wrote:

> While I think there may be some merit/benefit to what your suggesting, I
> think we should take a step back and also look at ZipFS to see what we
> might be able to share as part of a refactoring as there is a somewhat
> similar flow to ZipFS initCEN
>
> The benefit would be reducing the need to have to maintain somewhat
> duplicate code across both APIs.
>

Lance,

I think discussing a reusable CEN parsing library at this point may be a
bit premature. But we certainly don't want refactorings discussed here to
make such a future harder to get to.

If your concern is that the refactorings suggested here may make
ZipFile/ZipFS initCENs diverge further, then perhaps we can add as a goal
that these two should be refactored together?

We could certainly do that. Either in lockstep with each refactoring being
applied across APIs in the same PRs (where applicable), or we could clean
up the ZipFile first, then have a follow up where we realign ZipFS at the
end. Whatever we think makes most sense.

Wdyt?

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260213/a8af4bcc/attachment.htm>

From dl at openjdk.org  Fri Feb 13 15:21:10 2026
From: dl at openjdk.org (Doug Lea)
Date: Fri, 13 Feb 2026 15:21:10 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v34]
In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
Message-ID: <ba2J6GXklusNA0NvOJgD12N-F9iw_kunjk8KXlL8gfw=.2d067b80-5cc8-4f09-b7bb-d7b8a2ded3b6@github.com>

> Changes signal filtering to avoid possible starvation

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  For testing: revert to 26 except for redundant signals

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28797/files
  - new: https://git.openjdk.org/jdk/pull/28797/files/f67bfb19..a888b182

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=32-33

  Stats: 633 lines in 2 files changed: 185 ins; 167 del; 281 mod
  Patch: https://git.openjdk.org/jdk/pull/28797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28797/head:pull/28797

PR: https://git.openjdk.org/jdk/pull/28797

From aefimov at openjdk.org  Fri Feb 13 15:32:25 2026
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 13 Feb 2026 15:32:25 GMT
Subject: RFR: 8296183: jndiprovider.properties contains properties pointing
 to non-existing classes [v2]
In-Reply-To: <y14p-e5AulGqByGkPLHzA6Uj7K5jhTUKYY-9QdoqLLU=.13990294-8e6f-4a06-b4c3-28a1cffb9b10@github.com>
References: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com>
 <y14p-e5AulGqByGkPLHzA6Uj7K5jhTUKYY-9QdoqLLU=.13990294-8e6f-4a06-b4c3-28a1cffb9b10@github.com>
Message-ID: <5VuKXi3KCmZl39MqG7KzHv4pjDOGyR0DAA5p5l5z7n8=.f332a60d-01b8-4056-bd74-125d86571f42@github.com>

On Fri, 13 Feb 2026 12:14:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes the unused `src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties` file? This addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8296183.
>> 
>> This `jndiprovider.properties` file lists 3 properties `java.naming.factory.control`, `java.naming.factory.object` and `java.naming.factory.state`. The semantics of these environment properties are explained in https://docs.oracle.com/javase/jndi/tutorial/beyond/env/provider.html. The classes configured in `com/sun/jndi/ldap/jndiprovider.properties` for each of these properties are non-existent in the JDK. Looking at the version control history of the JDK, these classes haven't been around for several releases (not even in JDK 8). The `jndiprovier.properties` gets looked up by an JDK internal class in the `java.naming` module - `com.sun.naming.internal.ResourceManager`. The `ResourceManager.getFactories(...)` method is the one that gets called to load the classes configured for those 3 environment properties. The javadoc of `ResourceManager.getFactories(...)` says this:
>> 
>> 
>> Retrieves an enumeration of factory classes/object specified by a property.
>> 
>> The property is gotten from the environment and the provider resource file associated with the given context and concatenated.
>> ... The resulting property value is a list of class names.
>> This method then loads each class using the current thread's context class loader and keeps them in a list.
>> Any class that cannot be loaded is ignored.
>> ...
>> 
>> 
>> The implementation of `ResourceManager.getFactories(...)` matches that javadoc. Because the implementation ignores such missing classes, the reference to these non-existent classes in the `com/sun/jndi/ldap/jndiprovider.properties` has gone unnoticed all this while. Manual experiments of exercising this code path does indeed show that a `ClassNotFoundException` gets raised (and ignored) for the classes referenced in that `jnidprovider.properties` file.
>> 
>> The commit in this PR removes the `jndiprovier.properties`. It also removes a javadoc reference to one of these non-existent classes. Given the nature of the change no new tests have been introduced and the existing tests in tier1, tier2 and tier3 continue to pass.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add reference to DefaultResponseControlFactory in javadoc

Looks good to me

-------------

Marked as reviewed by aefimov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29712#pullrequestreview-3797906237

From rriggs at openjdk.org  Fri Feb 13 15:51:46 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 13 Feb 2026 15:51:46 GMT
Subject: RFR: 8356995: Provide default methods min(T, T) and max(T,
 T) in Comparator interface [v7]
In-Reply-To: <Qjq8JDeu2EjXhk9zXql2-bdvNXjRctEc38pd8cdajTE=.b9cc0607-1890-4eb1-abc4-0206c15d04f7@github.com>
References: <w-wOGaCBBoKymX1R-HcnuXfRLQumn087JndaIf7fMB8=.69a04ae3-94d7-4b68-8786-c4b564d2615f@github.com>
 <Qjq8JDeu2EjXhk9zXql2-bdvNXjRctEc38pd8cdajTE=.b9cc0607-1890-4eb1-abc4-0206c15d04f7@github.com>
Message-ID: <2jd9vK8ywBDwawLYb2-vmeRGe-GiVbjQKcmZTPpjVKM=.8102e049-b21a-4f9f-8b87-e293af841a39@github.com>

On Sun, 3 Aug 2025 13:42:41 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
>> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
>> 
>> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
>> 
>> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @implSpec

Please review and/or edit the release note: https://bugs.openjdk.org/browse/JDK-8356995

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-3897920977

From andrew at openjdk.org  Fri Feb 13 16:04:00 2026
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 13 Feb 2026 16:04:00 GMT
Subject: RFR: 8377509: Add licenses for gcc 14.2.0 [v2]
In-Reply-To: <gn3CXBBeMEpkp6Np3bXky0blNXEoJrg0LAxlqULzcBE=.97ce9e57-fec6-4717-80b7-d0ab3a45f01d@github.com>
References: <wQ7FUethHCraDe2hLn27x9N0XIyAlt39CaDnGaHdFo4=.4159ceb5-a44f-4f29-8f54-cf8660b2df57@github.com>
 <fmP6C03nX8WxAQE1cpkInIW2RA-IKcfzcP6bXrHXE-c=.d03c0ab2-2778-4feb-861d-9230c982e05d@github.com>
 <ETC0vYaFxqUyd0C3jF4mgHXE906zaU2yHvonKFfC0Yw=.b45dd9e6-ea2c-401d-b012-5efc6aa5077b@github.com>
 <gn3CXBBeMEpkp6Np3bXky0blNXEoJrg0LAxlqULzcBE=.97ce9e57-fec6-4717-80b7-d0ab3a45f01d@github.com>
Message-ID: <xXk01GbuNDLNayIkmk77UNEH0AE1xoZ8G6NeQEUNcoI=.51416148-9778-4e21-b276-827d0d21e785@github.com>

On Wed, 11 Feb 2026 23:51:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Not sure where you found that info, but the builds that are available here on GitHub don't necessarily represent builds made by those who build and distribute JDK binaries.

That's kind of the point @mrserb is making.  Your binaries may need this license, but you have made a change which affects **everyone** building OpenJDK.

> The changes to the makefiles was already done in JDK-8351603.

These are changes to the devkit build, which is something that has to be manually invoked separately from the OpenJDK build.  The change you've made here will bundle the GCC license in every build. 

This file was included on a build I just did on GNU/Linux with clang:
~~~
configure:108447: Using clang C compiler version 20.1.8 [clang version 20.1.8 ( 20.1.8-2.module+el8.10.0+23372+3f2ea6fa) Target: x86
_64-redhat-linux-gnu]
configure:108573: checking for C compiler version
configure:108582: /usr/bin/clang --version >&5
clang version 20.1.8 ( 20.1.8-2.module+el8.10.0+23372+3f2ea6fa)
...
configure:111815: Using clang C++ compiler version 20.1.8 [clang version 20.1.8 ( 20.1.8-2.module+el8.10.0+23372+3f2ea6fa) Target: x86_64-redhat-linux-gnu]
configure:111936: checking for C++ compiler version
configure:111945: /usr/bin/clang++ --version >&5
clang version 20.1.8 ( 20.1.8-2.module+el8.10.0+23372+3f2ea6fa)

$ ls -l ~/builder/26u/images/jdk/legal/java.base/gcc.md
-r--r--r--. 1 andrew people 128099 Feb 13 15:02 /home/andrew/builder/26u/images/jdk/legal/java.base/gcc.md
~~~
I haven't checked Windows & Mac but I presume this would also get bundled there too, where, again, gcc is not even being used.  I don't see anything in this PR that would prevent that from happening.

I don't see an explanation in this PR or the bug as to **why** this license is now needed.  `gcc` has been used to build for a long time, but this is not updating an existing license, but adding it.  So I presume something from `gcc` is now being bundled which requires this.  If so, inclusion of this license should be tied to whatever that option is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29661#issuecomment-3897974725

From andrew at openjdk.org  Fri Feb 13 16:12:40 2026
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 13 Feb 2026 16:12:40 GMT
Subject: RFR: 8377509: Add licenses for gcc 14.2.0 [v2]
In-Reply-To: <fmP6C03nX8WxAQE1cpkInIW2RA-IKcfzcP6bXrHXE-c=.d03c0ab2-2778-4feb-861d-9230c982e05d@github.com>
References: <wQ7FUethHCraDe2hLn27x9N0XIyAlt39CaDnGaHdFo4=.4159ceb5-a44f-4f29-8f54-cf8660b2df57@github.com>
 <fmP6C03nX8WxAQE1cpkInIW2RA-IKcfzcP6bXrHXE-c=.d03c0ab2-2778-4feb-861d-9230c982e05d@github.com>
Message-ID: <El1-6-N-xf-7ZJQFNlvRfz6mJyOXajjz1OVSpeRW96w=.480f1914-c715-42e6-865e-4272fc7d1ecd@github.com>

On Wed, 11 Feb 2026 18:12:34 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> Added license file for gcc 14.2.0
>
> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added version

Filed [JDK-8377905](https://bugs.openjdk.org/browse/JDK-8377905)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29661#issuecomment-3898021743

From sgehwolf at openjdk.org  Fri Feb 13 16:42:10 2026
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 13 Feb 2026 16:42:10 GMT
Subject: [jdk26] RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some
 tests [v2]
In-Reply-To: <scm91m0sIRDLVXOi6T3MYA9PBG1tQdm1OyepqOALkmE=.b369cb23-b332-4578-a98c-4ed1e5f1111a@github.com>
References: <a9jk4WieiGK6U35ULrnvQNtjVHWuUCiKmV1HQ9GJO4A=.b23b2f46-763e-413d-97bf-1eaa76e7f5f3@github.com>
 <Wjhdn5QObisFsKhWfVdbWdAqro9vQU5gxTEszL7gNMk=.17da51b9-d767-430c-af2d-d55273d142cc@github.com>
 <scm91m0sIRDLVXOi6T3MYA9PBG1tQdm1OyepqOALkmE=.b369cb23-b332-4578-a98c-4ed1e5f1111a@github.com>
Message-ID: <cctjzyltfzo9XKr6AXEXTEozdsOw2lASHkPfPu1-Emk=.7e95303c-0856-48d9-85fc-fb147ead45ee@github.com>

On Fri, 13 Feb 2026 08:08:42 GMT, SendaoYan <syan at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add an whitespace after if
>>   
>>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> I think we should close this PR now

@sendaoYan This PR needs to re-target [openjdk/jdk26u](https://github.com/openjdk/jdk26u/). This first needs to go to JDK 26 and later to older releases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28826#issuecomment-3898152657

From bpb at openjdk.org  Fri Feb 13 17:21:31 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Feb 2026 17:21:31 GMT
Subject: RFR: 8377910: Minor cleanup of java/io/FileDescriptor/Sharing.java
Message-ID: <HEZYKppPd3AWlhRtiKT-IX1yoNSTjLAc0-Fv-bieVMw=.0a3efa23-8583-48ab-b42c-7a656c7ef6b8@github.com>

Null checks potentially mask a more serious, fundamental problem and should be removed to allow a `NullPointerException` to be throw if the variable is `null`.

-------------

Commit messages:
 - 8377910: Minor cleanup of java/io/FileDescriptor/Sharing.java

Changes: https://git.openjdk.org/jdk/pull/29718/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29718&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377910
  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/29718.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29718/head:pull/29718

PR: https://git.openjdk.org/jdk/pull/29718

From bpb at openjdk.org  Fri Feb 13 17:21:32 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Feb 2026 17:21:32 GMT
Subject: RFR: 8377910: Minor cleanup of java/io/FileDescriptor/Sharing.java
In-Reply-To: <HEZYKppPd3AWlhRtiKT-IX1yoNSTjLAc0-Fv-bieVMw=.0a3efa23-8583-48ab-b42c-7a656c7ef6b8@github.com>
References: <HEZYKppPd3AWlhRtiKT-IX1yoNSTjLAc0-Fv-bieVMw=.0a3efa23-8583-48ab-b42c-7a656c7ef6b8@github.com>
Message-ID: <qCHjJoa5zLx1zVxCw5Bu6AVH4oaqwhPilmPIjYgKZ2o=.6d535603-31d6-45c4-acf1-bff9c1618698@github.com>

On Fri, 13 Feb 2026 17:14:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Null checks potentially mask a more serious, fundamental problem and should be removed to allow a `NullPointerException` to be throw if the variable is `null`.

It appears that the `null` checks in question were intended to match others elsewhere in the test where the checks are in a finally block and there are multiple variables among which not all might be `null` depending on which variables were initialized in the `try` block.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29718#issuecomment-3898346004

From alanb at openjdk.org  Fri Feb 13 17:35:41 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Feb 2026 17:35:41 GMT
Subject: RFR: 8377102: cacerts jlink plugin
In-Reply-To: <pRqfyRXHZHI7_wpjlirukGFoiqBdiQ58hH8z7km54Aw=.0e1621b5-1851-4783-bd2e-ba6b28f1ead6@github.com>
References: <pRqfyRXHZHI7_wpjlirukGFoiqBdiQ58hH8z7km54Aw=.0e1621b5-1851-4783-bd2e-ba6b28f1ead6@github.com>
Message-ID: <KO2N_m01Am-QlnpxbvSUrHR89gvgXX0hgz_4tEaVLck=.3883963f-5c47-4ce8-8484-4e23bdfe79d6@github.com>

On Thu, 12 Feb 2026 18:12:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is a new `jlink` plugin which allows the user to specify the CA certificates it wants to include in the `cacerts` keystore in a custom runtime image. This can be very useful for creating runtimes that only contain the CA certificates that are necessary.
> 
> The command-line syntax takes one or more `cacert` keystore aliases as an option, separated by a comma.
> 
> For example: 
> 
> `jlink --cacerts "letsencryptisrgx1 [jdk]"`
> 
> or
> 
> `jlink --cacerts "letsencryptisrgx1 [jdk],digicertglobalrootca [jdk]"`

Are you planning to update the man page?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29700#issuecomment-3898427375

From psandoz at openjdk.org  Fri Feb 13 17:49:25 2026
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 13 Feb 2026 17:49:25 GMT
Subject: RFR: 8376186: [VectorAPI] Nomenclature change for concrete vector
 classes [v3]
In-Reply-To: <rFnnnmZYvqWwSF9swRBWGoK2BXHIuYl_qkplWfy1V94=.25b06d9d-ef15-4d8c-99a3-5c5cb69c280c@github.com>
References: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
 <rFnnnmZYvqWwSF9swRBWGoK2BXHIuYl_qkplWfy1V94=.25b06d9d-ef15-4d8c-99a3-5c5cb69c280c@github.com>
Message-ID: <ZId-zFGCsRugJ3DFRJCY0wZXG8JXGG3IzkQSLYUyUb8=.83ceb5e9-0ba1-47fd-803a-2eb055fe1b91@github.com>

On Fri, 13 Feb 2026 06:33:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
>> 
>> In preparation of Float16 vector API support, changes to nomenclature of concrete vector class by suffixing the vector type with vector bit sizes e.g. FloatVector256 so that we don't end up generating names like Float16256Vector.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolution

Looks good, just one last comment to address. No need for another review.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 142:

> 140:             String suffix = suffix(vspecies);
> 141:             String elemType = (vspecies.elementType() == float.class ? "f" : "");
> 142:             boolean isFloat64Vector = (vspecies.elementType() == float.class) && (vspecies.length() == 2); // FloatVector64 or FloatVectorMax

Change the variable name too, here and at line 214.

-------------

PR Review: https://git.openjdk.org/jdk/pull/29614#pullrequestreview-3798632429
PR Review Comment: https://git.openjdk.org/jdk/pull/29614#discussion_r2805367818

From bpb at openjdk.org  Fri Feb 13 17:52:48 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Feb 2026 17:52:48 GMT
Subject: RFR: 8377910: Minor cleanup of java/io/FileDescriptor/Sharing.java
 [v2]
In-Reply-To: <HEZYKppPd3AWlhRtiKT-IX1yoNSTjLAc0-Fv-bieVMw=.0a3efa23-8583-48ab-b42c-7a656c7ef6b8@github.com>
References: <HEZYKppPd3AWlhRtiKT-IX1yoNSTjLAc0-Fv-bieVMw=.0a3efa23-8583-48ab-b42c-7a656c7ef6b8@github.com>
Message-ID: <GdxOe7ye2VaPvdOKi0UFfAdzEyt7sAx6l1m2GQQzRN4=.4b465f76-46e5-403f-8986-0276c3ee5680@github.com>

> Null checks potentially mask a more serious, fundamental problem and should be removed to allow a `NullPointerException` to be throw if the variable is `null`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8377910: In class OpenClose make arrays local to run method and other instance variables final

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29718/files
  - new: https://git.openjdk.org/jdk/pull/29718/files/9954cca5..9dd1613c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29718&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29718&range=00-01

  Stats: 7 lines in 1 file changed: 3 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/29718.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29718/head:pull/29718

PR: https://git.openjdk.org/jdk/pull/29718

From alanb at openjdk.org  Fri Feb 13 17:52:49 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Feb 2026 17:52:49 GMT
Subject: RFR: 8377910: Minor cleanup of java/io/FileDescriptor/Sharing.java
 [v2]
In-Reply-To: <GdxOe7ye2VaPvdOKi0UFfAdzEyt7sAx6l1m2GQQzRN4=.4b465f76-46e5-403f-8986-0276c3ee5680@github.com>
References: <HEZYKppPd3AWlhRtiKT-IX1yoNSTjLAc0-Fv-bieVMw=.0a3efa23-8583-48ab-b42c-7a656c7ef6b8@github.com>
 <GdxOe7ye2VaPvdOKi0UFfAdzEyt7sAx6l1m2GQQzRN4=.4b465f76-46e5-403f-8986-0276c3ee5680@github.com>
Message-ID: <1YB_duDYga6HYNC_6a_s-_irTqE0SDL7Q5edF9s1tnY=.9a8747c3-6e24-4dc6-9f0f-25c089ee8b2a@github.com>

On Fri, 13 Feb 2026 17:49:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Null checks potentially mask a more serious, fundamental problem and should be removed to allow a `NullPointerException` to be throw if the variable is `null`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8377910: In class OpenClose make arrays local to run method and other instance variables final

test/jdk/java/io/FileDescriptor/Sharing.java line 370:

> 368:                  for(int i=0;i<numFiles;i++) {
> 369:                      fisArray[i].close();
> 370:                      fosArray[i].close();

It might be clearer if you change fisArray and fosArray to be local to the run method. There is no reason for them to be fields in OpenClose. Making fd and done final would help too. 

I can't see from the bug report what failed but hopefully better output with the changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29718#discussion_r2805363903

From bpb at openjdk.org  Fri Feb 13 17:52:50 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Feb 2026 17:52:50 GMT
Subject: RFR: 8377910: Minor cleanup of java/io/FileDescriptor/Sharing.java
 [v2]
In-Reply-To: <1YB_duDYga6HYNC_6a_s-_irTqE0SDL7Q5edF9s1tnY=.9a8747c3-6e24-4dc6-9f0f-25c089ee8b2a@github.com>
References: <HEZYKppPd3AWlhRtiKT-IX1yoNSTjLAc0-Fv-bieVMw=.0a3efa23-8583-48ab-b42c-7a656c7ef6b8@github.com>
 <GdxOe7ye2VaPvdOKi0UFfAdzEyt7sAx6l1m2GQQzRN4=.4b465f76-46e5-403f-8986-0276c3ee5680@github.com>
 <1YB_duDYga6HYNC_6a_s-_irTqE0SDL7Q5edF9s1tnY=.9a8747c3-6e24-4dc6-9f0f-25c089ee8b2a@github.com>
Message-ID: <UWZMl94TWXzAhkmfLa7YtT82wZRrw4XtKkHh21R1j2E=.0d512412-b876-4dae-8274-317d16d9ace4@github.com>

On Fri, 13 Feb 2026 17:42:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I can't see from the bug report what failed but hopefully better output with the changes.

It's not clear exactly what failed (in the parent task issue) but perhaps this will disambiguate the situation a bit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29718#discussion_r2805373689

From bpb at openjdk.org  Fri Feb 13 17:52:51 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Feb 2026 17:52:51 GMT
Subject: RFR: 8377910: Minor cleanup of java/io/FileDescriptor/Sharing.java
 [v2]
In-Reply-To: <UWZMl94TWXzAhkmfLa7YtT82wZRrw4XtKkHh21R1j2E=.0d512412-b876-4dae-8274-317d16d9ace4@github.com>
References: <HEZYKppPd3AWlhRtiKT-IX1yoNSTjLAc0-Fv-bieVMw=.0a3efa23-8583-48ab-b42c-7a656c7ef6b8@github.com>
 <GdxOe7ye2VaPvdOKi0UFfAdzEyt7sAx6l1m2GQQzRN4=.4b465f76-46e5-403f-8986-0276c3ee5680@github.com>
 <1YB_duDYga6HYNC_6a_s-_irTqE0SDL7Q5edF9s1tnY=.9a8747c3-6e24-4dc6-9f0f-25c089ee8b2a@github.com>
 <UWZMl94TWXzAhkmfLa7YtT82wZRrw4XtKkHh21R1j2E=.0d512412-b876-4dae-8274-317d16d9ace4@github.com>
Message-ID: <-jQNNqm3fyWynlMlsBhdfnhTz7KQWfsF_hdqPirbm84=.24cf60db-f4c9-4f54-b31d-afefda96916c@github.com>

On Fri, 13 Feb 2026 17:45:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/io/FileDescriptor/Sharing.java line 370:
>> 
>>> 368:                  for(int i=0;i<numFiles;i++) {
>>> 369:                      fisArray[i].close();
>>> 370:                      fosArray[i].close();
>> 
>> It might be clearer if you change fisArray and fosArray to be local to the run method. There is no reason for them to be fields in OpenClose. Making fd and done final would help too. 
>> 
>> I can't see from the bug report what failed but hopefully better output with the changes.
>
>> I can't see from the bug report what failed but hopefully better output with the changes.
> 
> It's not clear exactly what failed (in the parent task issue) but perhaps this will disambiguate the situation a bit.

> It might be clearer if you change fisArray and fosArray to be local to the run method. There is no reason for them to be fields in OpenClose. Making fd and done final would help too.

Done in 9dd1613.

Note that this code has bad indentation but I am leaving that alone until the end.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29718#discussion_r2805387796

From darcy at openjdk.org  Fri Feb 13 18:13:54 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 13 Feb 2026 18:13:54 GMT
Subject: RFR: 8376665: Port fdlibm acosh to Java [v9]
In-Reply-To: <8Aa15ErOwvGDWlwsoPoDk72EP0Oj0NCV14UMkrpurYc=.d3a6c8a2-b2b1-4845-8550-fcb82bde9786@github.com>
References: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
 <8Aa15ErOwvGDWlwsoPoDk72EP0Oj0NCV14UMkrpurYc=.d3a6c8a2-b2b1-4845-8550-fcb82bde9786@github.com>
Message-ID: <calBn1LB_1L8WviHRdwKBqIrll7YpBFHw9mTs3tZznw=.4f6d621e-1b63-4fdd-ae08-9a1e8cc3e65b@github.com>

On Thu, 12 Feb 2026 12:04:41 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM acosh method.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8376665: Fixed whitespaces.

Marked as reviewed by darcy (Reviewer).

src/java.base/share/classes/java/lang/FdLibm.java line 3585:

> 3583:      */
> 3584:     static final class Acosh {
> 3585:         private static final double ln2 = 6.93147180559945286227e-01;

Note for a possible future refactoring: many of the double constants elsewhere use hexadecimal literals rather than decimal ones.

-------------

PR Review: https://git.openjdk.org/jdk/pull/29488#pullrequestreview-3798732430
PR Review Comment: https://git.openjdk.org/jdk/pull/29488#discussion_r2805462996

From vyazici at openjdk.org  Fri Feb 13 18:17:50 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 13 Feb 2026 18:17:50 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v4]
In-Reply-To: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
Message-ID: <k2wep76JpSQOqjOaTDi2X2UPxRESgbeok11gLFEaSG4=.146ac5c4-c4b5-4d42-890f-315eabfe5aca@github.com>

> Moves input validation checks to Java for `java.lang.StringLatin1` intrinsics. While doing so, affected `java.lang.StringUTF16` methods needed to be updated due to relaxed checks at intrinsics. The javadocs of the touched methods are extensively overhauled.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  More `indexOf` et al. guards and other review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28832/files
  - new: https://git.openjdk.org/jdk/pull/28832/files/9bb6cdee..7efdc944

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28832&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28832&range=02-03

  Stats: 44 lines in 2 files changed: 30 ins; 6 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/28832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28832/head:pull/28832

PR: https://git.openjdk.org/jdk/pull/28832

From vyazici at openjdk.org  Fri Feb 13 18:20:11 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 13 Feb 2026 18:20:11 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v4]
In-Reply-To: <nf0TkStEpXhGFDUzuEBfO-bxKox9QCm_K7OZwiM4tZs=.99ab1261-b993-42c5-8149-5199cec39212@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
 <3ui4ZV1EWo2YpaqabNnOSHlCWN3QJKVBFbYs4fb8hPE=.b8bdb195-43c5-4900-ad61-09b575f3a212@github.com>
 <f4ih6l15znL2Js_rB4kEI88K5OM8-6BpOC5oWnzgWdA=.7eb7b057-32dd-4736-b84c-d305b91e255d@github.com>
 <nf0TkStEpXhGFDUzuEBfO-bxKox9QCm_K7OZwiM4tZs=.99ab1261-b993-42c5-8149-5199cec39212@github.com>
Message-ID: <DjJaOB3sMPs37gg9sASJCtwMMvotryhnCvOtgmDusYc=.9aaae929-0eaa-43a3-b5ae-d24b13accdc3@github.com>

On Fri, 13 Feb 2026 06:59:43 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>>> Is there a HotSpot specific namespace qualifier that can make it easier to cross reference this?
>> 
>> @RogerRiggs, not that I know of. I also considered following alternatives:
>> 
>> - `library_call.cpp:inline_string_equals`
>> - `vmIntrinsics::_compressStringB`
>> 
>> But none really qualifies as a programmatic reference and settled on `inline_string_equals`, the most convenient phrase to do find-and-jump.
>> 
>> @dafedafe, @TobiHartmann, do you have any suggestions/preferences?
>
> I think `vmIntrinsics::_equalsL` would be the best option here.

Adapted `vmIntrinsics::`-prefixed references in 9bb6cdee9cb.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804547249

From vyazici at openjdk.org  Fri Feb 13 18:20:13 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 13 Feb 2026 18:20:13 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v4]
In-Reply-To: <nPUx9Q4Pw4HQzeALsKmOtT40seJxjHd01XO-rxTMenk=.08d87407-2a65-410d-ad9a-54ae89fdb6f4@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
 <KeNqd83bGg0oPTyA4m5C8HB_F5q5r4jcY_ac96NNMI4=.74f069e3-4ba1-44b2-b9ac-6d84a745d8cb@github.com>
 <E3MpThx86Yu3C_JpWtNTcoc_WJ5DX5ohKb1j1LmAn84=.b84c33bd-9ea4-433f-bc38-6176b0345a48@github.com>
 <nPUx9Q4Pw4HQzeALsKmOtT40seJxjHd01XO-rxTMenk=.08d87407-2a65-410d-ad9a-54ae89fdb6f4@github.com>
Message-ID: <NSkGUOQdXAd7kNQnqANm2X41qHM5UnbPEIx-XkMy9H8=.88589faa-77d0-4546-ad1d-91eecdc5c611@github.com>

On Fri, 13 Feb 2026 13:39:42 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> a performance check before and after could be nice

I've already attached a performance report to the ticket. I'd really appreciate it if you can skim through it and let me know if you see any significant regressions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804806715

From vyazici at openjdk.org  Fri Feb 13 18:20:26 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 13 Feb 2026 18:20:26 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v2]
In-Reply-To: <kVUXENAo0flzVsMI_T417pqGbNm7hu7vPpuRyDiBO5c=.04899a9b-bb8b-4436-be12-92ed2e005665@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
 <rObgPuAWe3qMxqlDCoOSR4Tpj9zHt6g8kb68ATCOCig=.9fce9ad3-8254-489f-9585-1624465da04c@github.com>
 <kVUXENAo0flzVsMI_T417pqGbNm7hu7vPpuRyDiBO5c=.04899a9b-bb8b-4436-be12-92ed2e005665@github.com>
Message-ID: <xeJOkFwQ9eeXmsnZZVcVe-rU3kky4yYThNHw_KPQVkA=.8b653e13-bc51-40e1-9d10-942f155fbdc5@github.com>

On Fri, 13 Feb 2026 12:46:01 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply review feedback
>
> src/java.base/share/classes/java/lang/StringLatin1.java line 174:
> 
>> 172:         String.checkOffset(len2, length(other));
>> 173:         int lim = Math.min(len1, len2);
>> 174:         int k = ArraysSupport.mismatch(value, other, lim);
> 
> From the `mismatch()` doc it isn't clear that the returned index (if not negative) is the _smallest_ one locating a mismatch.
> Without this guarantee, this `compareTo()` method might return an incorrect value.

Created [JDK-8377903] to address this.

[JDK-8377903]: https://bugs.openjdk.org/browse/JDK-8377903

> src/java.base/share/classes/java/lang/StringLatin1.java line 199:
> 
>> 197:     // inline_string_compareTo
>> 198:     @IntrinsicCandidate
>> 199:     private static int compareToUTF16_0(byte[] value, byte[] other) {
> 
> I guess the `_` is to visually separate the 16 from the conventional 0?
> Other intrinsics names, e.g., `compareTo0()` do not use a separator.

Correct. I follow the convention of suffixing `@IntrinsicCandidate`-annotated methods with `0`. In this particular case, I thought `compareToUTF160` would be too ambiguous, and hence opted for the `_0` suffix.

> src/java.base/share/classes/java/lang/StringLatin1.java line 242:
> 
>> 240:     static int compareToCI(byte[] value, byte[] other) {
>> 241:         int len1 = value.length;    // Implicit null check on `value`
>> 242:         int len2 = other.length;    // Implicit null check on `other`
> 
> Alternatively, if you prefer
> 
> Suggestion:
> 
>         int len1 = value.length;    // fail fast on null
>         int len2 = other.length;    // fail fast on null

The `implicit null check` phrase was recommended by @stuart-marks, and I've been sticking to it since then in [JDK-8156534].

[JDK-8156534]: https://bugs.openjdk.org/browse/JDK-8156534

> src/java.base/share/classes/java/lang/StringLatin1.java line 265:
> 
>> 263:     static int compareToCI_UTF16(byte[] value, byte[] other) {
>> 264:         Objects.requireNonNull(value);
>> 265:         Objects.requireNonNull(other);
> 
> You could leave these checks out and rely on the following two lines for a fast fail on `null`, similarly to the latin1 case above.
> But adding the checks looks cleaner.

You're right, both `length` and `StringUTF16::length` indirectly check for nullability. But in this particular case, I've leaned towards explicit checks (hence, less cognitive load while looking at the method body) and flagging the invalid input as early as possible in the call stack.

> src/java.base/share/classes/java/lang/StringLatin1.java line 428:
> 
>> 426:      *
>> 427:      * @throws NullPointerException if {@code value} is null
>> 428:      * @throws StringIndexOutOfBoundsException if the sub-ranges are out of bounds
> 
> Suggestion:
> 
>      * @throws StringIndexOutOfBoundsException if the sub-range is out of bounds

Fixed in 7efdc944aa3.

> src/java.base/share/classes/java/lang/StringLatin1.java line 508:
> 
>> 506:     @IntrinsicCandidate
>> 507:     private static int indexOf0(byte[] value, int valueToIndex, byte[] str, int strToIndex, int valueFromIndex) {
>> 508:         byte first = str[0];
> 
> There's no protection in the 5 parameter caller agains an empty (0 length) `str`, so this can throw.
> I didn't look at the intrinsic to verify whether it assumes `str.length` > 0.

Added necessary guards in 7efdc944aa3.

> src/java.base/share/classes/java/lang/StringLatin1.java line 1025:
> 
>> 1023: 
>> 1024:     /**
>> 1025:      * Exhaustively copies characters from a Latin-1 string byte array sub-range
> 
> Stylistically, why "Exhaustively"?

Indeed redundant. Removed in 7efdc944aa3.

> src/java.base/share/classes/java/lang/StringUTF16.java line 407:
> 
>> 405:      * @param srcOff the index (inclusive) of the first character in {@code src}
>> 406:      * @param dst the target Latin-1 string byte array
>> 407:      * @param srcOff the index (inclusive) of the first character in {@code dst}
> 
> Suggestion:
> 
>      * @param dstOff the index (inclusive) of the first character in {@code dst}

Fixed in 7efdc944aa3.

> src/java.base/share/classes/java/lang/StringUTF16.java line 437:
> 
>> 435: 
>> 436:     /**
>> 437:      * Copies the prefix of Latin-1 characters from a UTF-16 string byte array
> 
> Since there are offsets, strictly speaking this is not a prefix but a general subrange.

_"Copies the prefix"_ was requested by @RogerRiggs: https://github.com/openjdk/jdk/pull/28832/files/6e5273ed7df61479b37e491bc272837cca36b192#r2789099768

Note that we say _"Copies the prefix of ... a ... sub-range"_, since the copy might terminate earlier upon encounter with a non-Latin-1 character in the given sub-range.

> src/java.base/share/classes/java/lang/StringUTF16.java line 499:
> 
>> 497: 
>> 498:     @IntrinsicCandidate
>> 499:     static void getChars(byte[] value, int srcBegin, int srcEnd, char[] dst, int dstBegin) {
> 
> What about this intrinsic? It doesn't seem to follow the conventions about `private` and a gatekeeper method.

As stated in the PR description:

> Moves input validation checks to Java for `java.lang.StringLatin1` intrinsics. While doing so, affected `java.lang.StringUTF16` methods needed to be updated due to relaxed checks at intrinsics.

That is, `StringUTF16` is only touched if it is affected by an associated `StringLatin1` change.

> src/java.base/share/classes/java/lang/StringUTF16.java line 623:
> 
>> 621:         Objects.requireNonNull(other);
>> 622:         checkOffset(len1, value);
>> 623:         String.checkOffset(len2, StringLatin1.length(other));
> 
> FYI, all these checks are already performed in the called (non-intrinsic) method.

I was on the fence with these checks ? I've removed them in 7efdc944aa3.

> src/java.base/share/classes/java/lang/StringUTF16.java line 726:
> 
>> 724:     static int compareToCI_Latin1(byte[] value, byte[] other) {
>> 725:         Objects.requireNonNull(value);
>> 726:         Objects.requireNonNull(other);
> 
> FYI, checks are already performed in the called method.

I was on the fence with these checks ? I've removed them in 7efdc944aa3.

> src/java.base/share/classes/java/lang/StringUTF16.java line 892:
> 
>> 890:     }
>> 891: 
>> 892:     private static int indexOfUnsafe(byte[] value, int valueToIndex, byte[] str, int strToIndex, int valueFromIndex) {
> 
> I think this method requires documentation about what it assumes about the arguments.
> While it can be somehow derived from its usages, it would help to have it located here.

Added documentation in 7efdc944aa3.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804891667
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804701905
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804729709
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2804747200
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2805487865
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2805486104
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2805483785
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2805481393
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2805352323
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2805362487
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2805479873
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2805479527
PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2805478651

From vyazici at openjdk.org  Fri Feb 13 18:20:28 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 13 Feb 2026 18:20:28 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v2]
In-Reply-To: <FAK36ciAgDvCTDrdg7JZmuN6iToaY0S4S5MzULPYwxY=.bbe4f159-dd6e-46ce-841b-bc7bb46a3ebb@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
 <rObgPuAWe3qMxqlDCoOSR4Tpj9zHt6g8kb68ATCOCig=.9fce9ad3-8254-489f-9585-1624465da04c@github.com>
 <lrVKSGdSJ-ZrfInsRoKrszqlR_f5FpCi6iVrHNMTodc=.54b8dd06-1d0e-4e49-b91f-d3eba64bb014@github.com>
 <FAK36ciAgDvCTDrdg7JZmuN6iToaY0S4S5MzULPYwxY=.bbe4f159-dd6e-46ce-841b-bc7bb46a3ebb@github.com>
Message-ID: <jB2yEYQ-J38vZ2_t2lVWQRAAo-SZtJcOyqik1yGlEGs=.ae5fc794-9684-481a-a4d5-10a52a56f787@github.com>

On Fri, 13 Feb 2026 14:31:17 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringUTF16.java line 981:
>> 
>>> 979:     }
>>> 980: 
>>> 981:     private static int indexOfLatin1Unsafe(byte[] src, int srcCount, byte[] tgt, int tgtCount, int fromIndex) {
>> 
>> Similarly to above, documenting the expectations about the arguments here would help.
>
> Be aware that I didn't review the native code.

Added documentation in 7efdc944aa3.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2805478142

From bpb at openjdk.org  Fri Feb 13 18:50:25 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Feb 2026 18:50:25 GMT
Subject: RFR: 8377910: Minor cleanup of java/io/FileDescriptor/Sharing.java
 [v2]
In-Reply-To: <GdxOe7ye2VaPvdOKi0UFfAdzEyt7sAx6l1m2GQQzRN4=.4b465f76-46e5-403f-8986-0276c3ee5680@github.com>
References: <HEZYKppPd3AWlhRtiKT-IX1yoNSTjLAc0-Fv-bieVMw=.0a3efa23-8583-48ab-b42c-7a656c7ef6b8@github.com>
 <GdxOe7ye2VaPvdOKi0UFfAdzEyt7sAx6l1m2GQQzRN4=.4b465f76-46e5-403f-8986-0276c3ee5680@github.com>
Message-ID: <GFsj3h5G74mrQnwOj9FH9KuV2KEfz_4YI7bFPaP_jZY=.30786f38-c3dd-4565-926d-166bf0fd6032@github.com>

On Fri, 13 Feb 2026 17:52:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Null checks potentially mask a more serious, fundamental problem and should be removed to allow a `NullPointerException` to be throw if the variable is `null`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8377910: In class OpenClose make arrays local to run method and other instance variables final

test/jdk/java/io/FileDescriptor/Sharing.java line 380:

> 378:                  if (fd.valid()) { // fd should not be valid after first close() call
> 379:                      System.err.println("OpenClose: FileDescriptor shouldn't be valid");
> 380:                      fail = true;

The failure reported in the parent issue occurs because `fd.valid()` is `true` at line 378. Code inspection alone does not reveal any reason for it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29718#discussion_r2805600941

From mullan at openjdk.org  Fri Feb 13 18:56:34 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 13 Feb 2026 18:56:34 GMT
Subject: RFR: 8377102: cacerts jlink plugin
In-Reply-To: <KO2N_m01Am-QlnpxbvSUrHR89gvgXX0hgz_4tEaVLck=.3883963f-5c47-4ce8-8484-4e23bdfe79d6@github.com>
References: <pRqfyRXHZHI7_wpjlirukGFoiqBdiQ58hH8z7km54Aw=.0e1621b5-1851-4783-bd2e-ba6b28f1ead6@github.com>
 <KO2N_m01Am-QlnpxbvSUrHR89gvgXX0hgz_4tEaVLck=.3883963f-5c47-4ce8-8484-4e23bdfe79d6@github.com>
Message-ID: <RTLm4nVWh9omwws3G3XiedqOrrjNtozN17a-tpPnx58=.5e4bd3a9-7bf8-4989-9db1-5fab4c358092@github.com>

On Fri, 13 Feb 2026 17:32:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Are you planning to update the man page?

That's a good question. Part of me is wondering if I have enough data to know if this plugin is covering the most common use cases. I was wondering if it should initially be "experimental" with a plan to make it official. (There are a number of jlink plugins that are experimental or unsupported). I have not thought much about building extensibility into the command line option. Currently, it is very simple and I think covers the most common use case. However, I am curious if there is a need to support adding additional root certs (ex: by specifying a PEM file), or if the developer/admin should be required to import that into the cacerts keystore (before or after).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29700#issuecomment-3898820857

From alanb at openjdk.org  Fri Feb 13 19:07:40 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Feb 2026 19:07:40 GMT
Subject: RFR: 8377910: Minor cleanup of java/io/FileDescriptor/Sharing.java
 [v2]
In-Reply-To: <GdxOe7ye2VaPvdOKi0UFfAdzEyt7sAx6l1m2GQQzRN4=.4b465f76-46e5-403f-8986-0276c3ee5680@github.com>
References: <HEZYKppPd3AWlhRtiKT-IX1yoNSTjLAc0-Fv-bieVMw=.0a3efa23-8583-48ab-b42c-7a656c7ef6b8@github.com>
 <GdxOe7ye2VaPvdOKi0UFfAdzEyt7sAx6l1m2GQQzRN4=.4b465f76-46e5-403f-8986-0276c3ee5680@github.com>
Message-ID: <GbRUpK-S6C_Nfue4YsvkwKQM3ndLmRNpGTM9ZI8xwKE=.4f572c36-30b1-4431-acb4-44725dcbacee@github.com>

On Fri, 13 Feb 2026 17:52:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Null checks potentially mask a more serious, fundamental problem and should be removed to allow a `NullPointerException` to be throw if the variable is `null`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8377910: In class OpenClose make arrays local to run method and other instance variables final

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29718#pullrequestreview-3798972892

From bpb at openjdk.org  Fri Feb 13 19:22:01 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Feb 2026 19:22:01 GMT
Subject: RFR: 8377910: Minor cleanup of java/io/FileDescriptor/Sharing.java
 [v3]
In-Reply-To: <HEZYKppPd3AWlhRtiKT-IX1yoNSTjLAc0-Fv-bieVMw=.0a3efa23-8583-48ab-b42c-7a656c7ef6b8@github.com>
References: <HEZYKppPd3AWlhRtiKT-IX1yoNSTjLAc0-Fv-bieVMw=.0a3efa23-8583-48ab-b42c-7a656c7ef6b8@github.com>
Message-ID: <IKBbGjAdTXdbIMQAjrA-SpzpC8ImhKEM_ZEgVJHnMMw=.15fc0187-c815-487b-8acb-79f973ab512b@github.com>

> Null checks potentially mask a more serious, fundamental problem and should be removed to allow a `NullPointerException` to be throw if the variable is `null`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8377910: Fix indentation and make java.io imports explicit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29718/files
  - new: https://git.openjdk.org/jdk/pull/29718/files/9dd1613c..73d9aeba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29718&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29718&range=01-02

  Stats: 37 lines in 1 file changed: 7 ins; 0 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/29718.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29718/head:pull/29718

PR: https://git.openjdk.org/jdk/pull/29718

From bpb at openjdk.org  Fri Feb 13 19:22:02 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Feb 2026 19:22:02 GMT
Subject: RFR: 8377910: Minor cleanup of java/io/FileDescriptor/Sharing.java
 [v3]
In-Reply-To: <-jQNNqm3fyWynlMlsBhdfnhTz7KQWfsF_hdqPirbm84=.24cf60db-f4c9-4f54-b31d-afefda96916c@github.com>
References: <HEZYKppPd3AWlhRtiKT-IX1yoNSTjLAc0-Fv-bieVMw=.0a3efa23-8583-48ab-b42c-7a656c7ef6b8@github.com>
 <GdxOe7ye2VaPvdOKi0UFfAdzEyt7sAx6l1m2GQQzRN4=.4b465f76-46e5-403f-8986-0276c3ee5680@github.com>
 <1YB_duDYga6HYNC_6a_s-_irTqE0SDL7Q5edF9s1tnY=.9a8747c3-6e24-4dc6-9f0f-25c089ee8b2a@github.com>
 <UWZMl94TWXzAhkmfLa7YtT82wZRrw4XtKkHh21R1j2E=.0d512412-b876-4dae-8274-317d16d9ace4@github.com>
 <-jQNNqm3fyWynlMlsBhdfnhTz7KQWfsF_hdqPirbm84=.24cf60db-f4c9-4f54-b31d-afefda96916c@github.com>
Message-ID: <-xUQO2uKHnRsh-Uyk7AHAjAQ5-SOh2j2RLU3K4t5WPs=.a4051a8a-3a33-424f-9007-3f698f3a4436@github.com>

On Fri, 13 Feb 2026 17:48:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Note that this code has bad indentation but I am leaving that alone until the end.

Indentation fixed in [73d9eab](https://github.com/openjdk/jdk/pull/29718/commits/73d9aebadb13b417945553f8500b32179271656f).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29718#discussion_r2805714196

From lance.andersen at oracle.com  Fri Feb 13 19:43:35 2026
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 13 Feb 2026 19:43:35 +0000
Subject: RFD: A plan to untangle ZipFile.Source.initCEN
In-Reply-To: <CA+pBWhsSYaqx0n1YPk2pVNT7pvfcSGFQN62QfHrqh843bcBtYA@mail.gmail.com>
References: <CA+pBWhsOxYX7+efPQVMk8c_XWBf5sG0oDrVURq1kM5xAocKiGA@mail.gmail.com>
 <A29CA46B-32BB-41D0-8B09-871296A8E2E7@oracle.com>
 <CA+pBWhsSYaqx0n1YPk2pVNT7pvfcSGFQN62QfHrqh843bcBtYA@mail.gmail.com>
Message-ID: <B86C541E-EB10-44E2-B091-C102B419CC7E@oracle.com>

Hi Eirik,

Yes one of the goals should  be to share as much code as possible, regardless of where the initial changes are to ZipFile.   initCEN is similar in both instances WRT flow and would best to keep changes in mind so that they can easily be retrofitted to ZipFS with the hopes of having shared code making it easier to address issues that often apply to both due to CEN processing

Another area which you had indicated looking at is ZipCoder which there are 2 similar implementations between ZipFS and ZipFile et al.  I believe part of that is due to ZipFS starting as a demo but would be good to streamline and ideally get to 1 implementation if possible.  I have asked Sherman, who is the original author of ZipFS and worked extensively on Zip to chime in on your  ZipCoder suggestion.

This has been on the todo list to look at but has not risen to the top of the list so appreciate your time in giving some thought to it.

Hope that answers your question.

Best,
Lance

On Feb 13, 2026, at 9:58?AM, Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:

On Tue, Feb 10, 2026 at 7:24?PM Lance Andersen <lance.andersen at oracle.com<mailto:lance.andersen at oracle.com>> wrote:
While I think there may be some merit/benefit to what your suggesting, I think we should take a step back and also look at ZipFS to see what we might be able to share as part of a refactoring as there is a somewhat similar flow to ZipFS initCEN

The benefit would be reducing the need to have to maintain somewhat duplicate code across both APIs.

Lance,

I think discussing a reusable CEN parsing library at this point may be a bit premature. But we certainly don't want refactorings discussed here to make such a future harder to get to.

If your concern is that the refactorings suggested here may make ZipFile/ZipFS initCENs diverge further, then perhaps we can add as a goal that these two should be refactored together?

We could certainly do that. Either in lockstep with each refactoring being applied across APIs in the same PRs (where applicable), or we could clean up the ZipFile first, then have a follow up where we realign ZipFS at the end. Whatever we think makes most sense.

Wdyt?

Eirik.

[oracle_sig_logo.gif]

Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260213/5a7f2302/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260213/5a7f2302/oracle_sig_logo-0001.gif>

From duke at openjdk.org  Fri Feb 13 21:06:40 2026
From: duke at openjdk.org (David Beaumont)
Date: Fri, 13 Feb 2026 21:06:40 GMT
Subject: RFR: 8372301: Improve error message for jimage command line tool
 regarding version mismatch
Message-ID: <tnZEXnEKoaJ_ks5AwNXEn0mvUk9EjI24gdndpPWmHKo=.545e2ec6-a8b9-4b56-aff0-dece97a5c0f2@github.com>

New implementation of improved JImageTask error message using string matching to detect the "version mismatch" error without needing code changes in the library.

Added tests for the error message and other ways in which the jimage file can be corrupt.

-------------

Commit messages:
 - 8372301: Improve error message for jimage command line tool regarding version mismatch

Changes: https://git.openjdk.org/jdk/pull/29723/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29723&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372301
  Stats: 190 lines in 4 files changed: 185 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/29723.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29723/head:pull/29723

PR: https://git.openjdk.org/jdk/pull/29723

From asarkar at openjdk.org  Fri Feb 13 21:15:40 2026
From: asarkar at openjdk.org (Anirvan Sarkar)
Date: Fri, 13 Feb 2026 21:15:40 GMT
Subject: RFR: 8296183: jndiprovider.properties contains properties pointing
 to non-existing classes [v2]
In-Reply-To: <y14p-e5AulGqByGkPLHzA6Uj7K5jhTUKYY-9QdoqLLU=.13990294-8e6f-4a06-b4c3-28a1cffb9b10@github.com>
References: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com>
 <y14p-e5AulGqByGkPLHzA6Uj7K5jhTUKYY-9QdoqLLU=.13990294-8e6f-4a06-b4c3-28a1cffb9b10@github.com>
Message-ID: <5KrG_KONacK8ssoB822zQJZ2mP772ddAOPrEnAB5dBw=.954d7d11-ba31-405a-a2b1-2b1de23c0b15@github.com>

On Fri, 13 Feb 2026 12:14:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes the unused `src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties` file? This addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8296183.
>> 
>> This `jndiprovider.properties` file lists 3 properties `java.naming.factory.control`, `java.naming.factory.object` and `java.naming.factory.state`. The semantics of these environment properties are explained in https://docs.oracle.com/javase/jndi/tutorial/beyond/env/provider.html. The classes configured in `com/sun/jndi/ldap/jndiprovider.properties` for each of these properties are non-existent in the JDK. Looking at the version control history of the JDK, these classes haven't been around for several releases (not even in JDK 8). The `jndiprovier.properties` gets looked up by an JDK internal class in the `java.naming` module - `com.sun.naming.internal.ResourceManager`. The `ResourceManager.getFactories(...)` method is the one that gets called to load the classes configured for those 3 environment properties. The javadoc of `ResourceManager.getFactories(...)` says this:
>> 
>> 
>> Retrieves an enumeration of factory classes/object specified by a property.
>> 
>> The property is gotten from the environment and the provider resource file associated with the given context and concatenated.
>> ... The resulting property value is a list of class names.
>> This method then loads each class using the current thread's context class loader and keeps them in a list.
>> Any class that cannot be loaded is ignored.
>> ...
>> 
>> 
>> The implementation of `ResourceManager.getFactories(...)` matches that javadoc. Because the implementation ignores such missing classes, the reference to these non-existent classes in the `com/sun/jndi/ldap/jndiprovider.properties` has gone unnoticed all this while. Manual experiments of exercising this code path does indeed show that a `ClassNotFoundException` gets raised (and ignored) for the classes referenced in that `jnidprovider.properties` file.
>> 
>> The commit in this PR removes the `jndiprovier.properties`. It also removes a javadoc reference to one of these non-existent classes. Given the nature of the change no new tests have been introduced and the existing tests in tier1, tier2 and tier3 continue to pass.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add reference to DefaultResponseControlFactory in javadoc

>Looking at the version control history of the JDK, these classes haven't been around for several releases (not even in JDK 8)

It seems these classes were never part of the JDK.
These classes were part of the (legacy?) JNDI/LDAP booster pack `ldapbp.jar` available as a separate download.
The download file is currently `ldap-1_2_4.zip` in the Oracle Java Archive for Java Platform Technologies [1].

Software vendors required `ldapbp.jar` to be added to the `CLASSPATH`.
The very old JNDI tutorial also references `ldapbp.jar` [2].

Booster pack has the following packages:

|          Package           |                     Contents                      |
|----------------------------|---------------------------------------------------|
| com.sun.jndi.ldap.obj      | RMI, CORBA support for LDAP Service Provider for JNDI |
| com.sun.security.sasl.misc | CRAM-MD5, Anonymous, and Plain SASL Drivers       |
| com.sun.jndi.ldap.ctl      | Controls for LDAP Service Provider for JNDI       |

The packages `com.sun.security.sasl.misc` and `com.sun.jndi.ldap.ctl` became obsolete when its support was included in the JDK 5.

I suspect the classes of package `com.sun.jndi.ldap.obj` were not included in JDK, as RFC 2713 & RFC 2714 were not standardized unlike other RFCs related to LDAP.

The booster pack is also available on Maven repository [3].
Do you think any of its dependencies could be impacted by removal of `jndiprovider.properties` file?
Should this removal be mentioned in the release notes? 

If you want to look at the booster pack?s source code, it?s included in GlassFish 5 [4].

[1] : https://www.oracle.com/java/technologies/java-archive-downloads-java-plat-downloads.html#7110-jndi-1.2.1-oth-JPR
[2] : https://docs.oracle.com/javase/jndi/tutorial/objects/storing/index.html
[3] : https://mvnrepository.com/artifact/com.sun/ldapbp
[4] : https://github.com/javaee/glassfish/tree/master/appserver/ldapbp/src/main/java/com/sun/jndi/ldap

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29712#issuecomment-3899500761

From kshiroko at openjdk.org  Sat Feb 14 02:37:25 2026
From: kshiroko at openjdk.org (Kirill Shirokov)
Date: Sat, 14 Feb 2026 02:37:25 GMT
Subject: RFR: 8377729: Running jtreg tests with -agent... option causes
 some tests to fail due to duplicate -agent options provided to a subprocess
 [v2]
In-Reply-To: <Xx7VPlNQy-Svo7fkKo71gYLrSJ4nTxyyGnwEpXyfeyQ=.4cdbed9d-b09c-4c74-8a0e-1c27e620a825@github.com>
References: <Xx7VPlNQy-Svo7fkKo71gYLrSJ4nTxyyGnwEpXyfeyQ=.4cdbed9d-b09c-4c74-8a0e-1c27e620a825@github.com>
Message-ID: <VfYMw1R5GJvQB43PPP-mQbBwQFAbRugPcsrAZEVYFik=.5c67dd1c-0523-4ba4-98c7-5986eaff2123@github.com>

> The fix removes duplicate `-agent...` and `-javaagent:...` options from test subprocess command line, thus allowing to run jtreg tests with agents that should be specified only once.
> 
> The fix tested manually:
> 
> 
> $ make test JTREG="VERBOSE=summary,fail,error" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>    jtreg:test/jdk/sun/tools/jstack/DeadlockDetectionTest.java
>                                                          1     1     0     0     0
>    jtreg:test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java
>                                                          1     1     0     0     0
>    jtreg:test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java
>                                                          1     1     0     0     0
> ==============================
> TEST SUCCESS
> 
> $ make test JTREG="VERBOSE=summary,fail,error;JAVA_OPTIONS=-agentpath.../async-profiler-binaries/lib/libasyncProfiler.dylib=start,event=cpu,cstack=vm,loglevel=none,flat,file=/dev/null" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>    jtreg:test/jdk/sun/tools/jstack/DeadlockDetectionTest.java
>>>                                                       1     0     1     0     0 <<
>    jtreg:test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java
>>>                                                       1     0     1     0     0 <<
>    jtreg:test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java
>>>                                                       1     0     1     0     0 <<
> ==============================
> TEST FAILURE
> 
> $ make test JTREG="VERBOSE=summary,fail,error;VM_OPTIONS=-agentpath:.../async-profiler-binaries/lib/libasyncProfiler.dylib=start,event=cpu,cstack=vm,loglevel=none,flat,file=/dev/null" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"
> 
> (same errors)
> 
> With th...

Kirill Shirokov has updated the pull request incrementally with two additional commits since the last revision:

 - Remove trailing whitespace
 - Removed duplicate VM options from test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java, test/jdk/sun/tools/jstack/DeadlockDetectionTest.java, test/lib/jdk/test/lib/apps/LingeredApp.java, test/lib/jdk/test/lib/cli/CommandLineOptionTest.java. Added duplicate agent options warning to ProcessTools-spawned subprocesses and LingeredApp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29684/files
  - new: https://git.openjdk.org/jdk/pull/29684/files/d45c4fa4..f6835f93

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29684&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29684&range=00-01

  Stats: 26 lines in 5 files changed: 6 ins; 4 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/29684.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29684/head:pull/29684

PR: https://git.openjdk.org/jdk/pull/29684

From kshiroko at openjdk.org  Sat Feb 14 02:37:26 2026
From: kshiroko at openjdk.org (Kirill Shirokov)
Date: Sat, 14 Feb 2026 02:37:26 GMT
Subject: RFR: 8377729: Running jtreg tests with -agent... option causes
 some tests to fail due to duplicate -agent options provided to a subprocess
 [v2]
In-Reply-To: <CsMq1ha2NZrZCz_cACsxF0SSi0FSQieUeXp9pJ0PCdQ=.6c9137eb-c31b-41f4-b670-b0ca626cf6ca@github.com>
References: <Xx7VPlNQy-Svo7fkKo71gYLrSJ4nTxyyGnwEpXyfeyQ=.4cdbed9d-b09c-4c74-8a0e-1c27e620a825@github.com>
 <CsMq1ha2NZrZCz_cACsxF0SSi0FSQieUeXp9pJ0PCdQ=.6c9137eb-c31b-41f4-b670-b0ca626cf6ca@github.com>
Message-ID: <rguX6jew6em3DIyWSHNYjhsPeYpwoKTTDCmazAn0EMI=.3335709b-0ba4-4b0e-80f7-cbfee6f8f887@github.com>

On Thu, 12 Feb 2026 04:51:10 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Kirill Shirokov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove trailing whitespace
>>  - Removed duplicate VM options from test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java, test/jdk/sun/tools/jstack/DeadlockDetectionTest.java, test/lib/jdk/test/lib/apps/LingeredApp.java, test/lib/jdk/test/lib/cli/CommandLineOptionTest.java. Added duplicate agent options warning to ProcessTools-spawned subprocesses and LingeredApp
>
> test/lib/jdk/test/lib/apps/LingeredApp.java line 49:
> 
>> 47: import jdk.test.lib.Utils;
>> 48: import jdk.test.lib.process.OutputBuffer;
>> 49: import jdk.test.lib.process.ProcessTools;
> 
> I don't think that it is good idea to deduplicate options in ProcessTools.
> 
> Better to fix the tests that duplicate options rather then try to deduplicate all options.

I fixed individual tests. Removed deduplication, but kept the check for duplicate agent arguments in place (now it just prints a message to stderr)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29684#discussion_r2806818285

From syan at openjdk.org  Sat Feb 14 02:48:17 2026
From: syan at openjdk.org (SendaoYan)
Date: Sat, 14 Feb 2026 02:48:17 GMT
Subject: [jdk26] RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some
 tests [v2]
In-Reply-To: <scm91m0sIRDLVXOi6T3MYA9PBG1tQdm1OyepqOALkmE=.b369cb23-b332-4578-a98c-4ed1e5f1111a@github.com>
References: <a9jk4WieiGK6U35ULrnvQNtjVHWuUCiKmV1HQ9GJO4A=.b23b2f46-763e-413d-97bf-1eaa76e7f5f3@github.com>
 <Wjhdn5QObisFsKhWfVdbWdAqro9vQU5gxTEszL7gNMk=.17da51b9-d767-430c-af2d-d55273d142cc@github.com>
 <scm91m0sIRDLVXOi6T3MYA9PBG1tQdm1OyepqOALkmE=.b369cb23-b332-4578-a98c-4ed1e5f1111a@github.com>
Message-ID: <bG20ESzV1Wz7Q8f89jDH2la0RGVSIKWz5Uaumn46qiI=.514bd05e-012f-482d-9534-f60917741cbb@github.com>

On Fri, 13 Feb 2026 08:08:42 GMT, SendaoYan <syan at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add an whitespace after if
>>   
>>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> I think we should close this PR now

> @sendaoYan This PR needs to re-target [openjdk/jdk26u](https://github.com/openjdk/jdk26u/). This first needs to go to JDK 26 and later to older releases.

Okey.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28826#issuecomment-3900517137

From jbhateja at openjdk.org  Sat Feb 14 02:57:24 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sat, 14 Feb 2026 02:57:24 GMT
Subject: RFR: 8376186: [VectorAPI] Nomenclature change for concrete vector
 classes [v4]
In-Reply-To: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
References: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
Message-ID: <Bzx3RDLxYReEgvenPP4azkojJILlxkzwkfQSMZJUIwU=.d87d450b-3341-46cb-a1df-59b80321adf8@github.com>

> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
> 
> In preparation of Float16 vector API support, changes to nomenclature of concrete vector class by suffixing the vector type with vector bit sizes e.g. FloatVector256 so that we don't end up generating names like Float16256Vector.
> 
> All existing Vector API jtreg test are passing with the patch.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8376186
 - Reivew comments resolution
 - Review comments resolution
 - Review comment resolution
 - Removing older artifact
 - 8376186: [VectorAPI] Nomenclature change for concrete vector classes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29614/files
  - new: https://git.openjdk.org/jdk/pull/29614/files/8a5615d1..b56d47a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29614&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29614&range=02-03

  Stats: 24658 lines in 551 files changed: 11049 ins; 3406 del; 10203 mod
  Patch: https://git.openjdk.org/jdk/pull/29614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29614/head:pull/29614

PR: https://git.openjdk.org/jdk/pull/29614

From jbhateja at openjdk.org  Sat Feb 14 02:57:27 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sat, 14 Feb 2026 02:57:27 GMT
Subject: RFR: 8376186: [VectorAPI] Nomenclature change for concrete vector
 classes [v3]
In-Reply-To: <ZId-zFGCsRugJ3DFRJCY0wZXG8JXGG3IzkQSLYUyUb8=.83ceb5e9-0ba1-47fd-803a-2eb055fe1b91@github.com>
References: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
 <rFnnnmZYvqWwSF9swRBWGoK2BXHIuYl_qkplWfy1V94=.25b06d9d-ef15-4d8c-99a3-5c5cb69c280c@github.com>
 <ZId-zFGCsRugJ3DFRJCY0wZXG8JXGG3IzkQSLYUyUb8=.83ceb5e9-0ba1-47fd-803a-2eb055fe1b91@github.com>
Message-ID: <pC8iCGDRDH0sD-kLZkwRW_Ib4SixjFEFmqe7XIScG7k=.c07281e7-282c-4c05-9712-2a40d891bbe2@github.com>

On Fri, 13 Feb 2026 17:43:42 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolution
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 142:
> 
>> 140:             String suffix = suffix(vspecies);
>> 141:             String elemType = (vspecies.elementType() == float.class ? "f" : "");
>> 142:             boolean isFloat64Vector = (vspecies.elementType() == float.class) && (vspecies.length() == 2); // FloatVector64 or FloatVectorMax
> 
> Change the variable name too, here and at line 214.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29614#discussion_r2806846567

From lmesnik at openjdk.org  Sat Feb 14 05:59:08 2026
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 14 Feb 2026 05:59:08 GMT
Subject: RFR: 8377729: Running jtreg tests with -agent... option causes
 some tests to fail due to duplicate -agent options provided to a subprocess
 [v2]
In-Reply-To: <VfYMw1R5GJvQB43PPP-mQbBwQFAbRugPcsrAZEVYFik=.5c67dd1c-0523-4ba4-98c7-5986eaff2123@github.com>
References: <Xx7VPlNQy-Svo7fkKo71gYLrSJ4nTxyyGnwEpXyfeyQ=.4cdbed9d-b09c-4c74-8a0e-1c27e620a825@github.com>
 <VfYMw1R5GJvQB43PPP-mQbBwQFAbRugPcsrAZEVYFik=.5c67dd1c-0523-4ba4-98c7-5986eaff2123@github.com>
Message-ID: <9Fk9BPg4ug9T4nhiRg1oWiO_v-ERf8-DhwZkaVjzfXo=.bf3b3bc8-584c-4d1d-801e-6a232bbbcbc1@github.com>

On Sat, 14 Feb 2026 02:37:25 GMT, Kirill Shirokov <kshiroko at openjdk.org> wrote:

>> The fix removes duplicate `-agent...` and `-javaagent:...` options from test subprocess command line, thus allowing to run jtreg tests with agents that should be specified only once.
>> 
>> The fix tested manually:
>> 
>> 
>> $ make test JTREG="VERBOSE=summary,fail,error" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>>    jtreg:test/jdk/sun/tools/jstack/DeadlockDetectionTest.java
>>                                                          1     1     0     0     0
>>    jtreg:test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java
>>                                                          1     1     0     0     0
>>    jtreg:test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java
>>                                                          1     1     0     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> $ make test JTREG="VERBOSE=summary,fail,error;JAVA_OPTIONS=-agentpath.../async-profiler-binaries/lib/libasyncProfiler.dylib=start,event=cpu,cstack=vm,loglevel=none,flat,file=/dev/null" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>>    jtreg:test/jdk/sun/tools/jstack/DeadlockDetectionTest.java
>>>>                                                       1     0     1     0     0 <<
>>    jtreg:test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java
>>>>                                                       1     0     1     0     0 <<
>>    jtreg:test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java
>>>>                                                       1     0     1     0     0 <<
>> ==============================
>> TEST FAILURE
>> 
>> $ make test JTREG="VERBOSE=summary,fail,error;VM_OPTIONS=-agentpath:.../async-profiler-binaries/lib/libasyncProfiler.dylib=start,event=cpu,cstack=vm,loglevel=none,flat,file=/dev/null" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/...
>
> Kirill Shirokov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailing whitespace
>  - Removed duplicate VM options from test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java, test/jdk/sun/tools/jstack/DeadlockDetectionTest.java, test/lib/jdk/test/lib/apps/LingeredApp.java, test/lib/jdk/test/lib/cli/CommandLineOptionTest.java. Added duplicate agent options warning to ProcessTools-spawned subprocesses and LingeredApp

Thanks for fixing tests. The fix looks good.

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29684#pullrequestreview-3801076153

From alanb at openjdk.org  Sat Feb 14 07:22:10 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 14 Feb 2026 07:22:10 GMT
Subject: RFR: 8377910: Minor cleanup of java/io/FileDescriptor/Sharing.java
 [v3]
In-Reply-To: <IKBbGjAdTXdbIMQAjrA-SpzpC8ImhKEM_ZEgVJHnMMw=.15fc0187-c815-487b-8acb-79f973ab512b@github.com>
References: <HEZYKppPd3AWlhRtiKT-IX1yoNSTjLAc0-Fv-bieVMw=.0a3efa23-8583-48ab-b42c-7a656c7ef6b8@github.com>
 <IKBbGjAdTXdbIMQAjrA-SpzpC8ImhKEM_ZEgVJHnMMw=.15fc0187-c815-487b-8acb-79f973ab512b@github.com>
Message-ID: <fbOIDrTvzjCIzeg__V0fSQlzcOJGq6w9mhUyGF-xL84=.9c33c310-de36-4593-aaab-1704e437d18f@github.com>

On Fri, 13 Feb 2026 19:22:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Null checks potentially mask a more serious, fundamental problem and should be removed to allow a `NullPointerException` to be throw if the variable is `null`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8377910: Fix indentation and make java.io imports explicit

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29718#pullrequestreview-3801172808

From iklam at openjdk.org  Sat Feb 14 07:23:01 2026
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 14 Feb 2026 07:23:01 GMT
Subject: RFR: 8377712: ConstantPool of WeakReferenceKey is not
 deterministic in CDS archive [v2]
In-Reply-To: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
References: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
Message-ID: <uxNkdMinqTfNSzIWdNkjttFJckj7ey_gq3sl9b9Pb5k=.b669cf19-f666-42d3-9120-1c5a9119eb1d@github.com>

> We are seeing intermittent failures (12 times in Jan 2026) where the CDS archives generated in the JDK build is not deterministic.
> 
> The symptom is that (perhaps due to the peculiarity of hash codes and memory addressing??) the constant pool entry for `ReferenceKey<?>` in the `WeakReferenceKey` class is not resolved when the failure happens.
> 
> The fix is for the JVM to call a method in `WeakReferenceKey` to force this entry to be resolved.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @liach comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29678/files
  - new: https://git.openjdk.org/jdk/pull/29678/files/ecf3113f..184d575d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29678&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29678&range=00-01

  Stats: 15 lines in 2 files changed: 2 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/29678.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29678/head:pull/29678

PR: https://git.openjdk.org/jdk/pull/29678

From iklam at openjdk.org  Sat Feb 14 07:23:02 2026
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 14 Feb 2026 07:23:02 GMT
Subject: RFR: 8377712: ConstantPool of WeakReferenceKey is not
 deterministic in CDS archive
In-Reply-To: <6zpNwnhptQsaXSbK3lPp53L2I9y7UTSO4tDDsBVbvvA=.12330079-d403-4edd-b20f-3e5e90a51926@github.com>
References: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
 <6zpNwnhptQsaXSbK3lPp53L2I9y7UTSO4tDDsBVbvvA=.12330079-d403-4edd-b20f-3e5e90a51926@github.com>
Message-ID: <TmrvAM5AREN9n1lvMjMee8GfoS5eUcz54NMKPBXRMEA=.90b73aee-6103-47e3-98f4-284a89f016f2@github.com>

On Thu, 12 Feb 2026 05:58:15 GMT, Chen Liang <liach at openjdk.org> wrote:

> Or a better fix would be removing the == path for all reference keys. There's no case where this hits because you are always creating a new strong key. Missing use of class constant means the equals method is completely unused.

As we discussed offline, I updated `ensureDeterministicAOTCache()` to call `WeakReferenceKey::equals()` instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29678#issuecomment-3901302276

From alanb at openjdk.org  Sat Feb 14 08:02:36 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 14 Feb 2026 08:02:36 GMT
Subject: RFR: 8372301: Improve error message for jimage command line tool
 regarding version mismatch
In-Reply-To: <tnZEXnEKoaJ_ks5AwNXEn0mvUk9EjI24gdndpPWmHKo=.545e2ec6-a8b9-4b56-aff0-dece97a5c0f2@github.com>
References: <tnZEXnEKoaJ_ks5AwNXEn0mvUk9EjI24gdndpPWmHKo=.545e2ec6-a8b9-4b56-aff0-dece97a5c0f2@github.com>
Message-ID: <dKepWbG4WtDBxRGSQz_cvr6gnxM_fyK0nuXUUTegoOw=.275ab9b7-1c90-4dd2-a4bb-b1bbfee3f263@github.com>

On Fri, 13 Feb 2026 20:59:09 GMT, David Beaumont <duke at openjdk.org> wrote:

> New implementation of improved JImageTask error message using string matching to detect the "version mismatch" error without needing code changes in the library.
> 
> Added tests for the error message and other ways in which the jimage file can be corrupt.

src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 200:

> 198:                 result.getMinorVersion() != ImageHeader.MINOR_VERSION) {
> 199:             // We rely on the sub-string "not the correct version" to detect
> 200:             // version issues in JImageTask and give a better user message.

Is there any reason not to introduce an ImageVersionMismatchException (extends IOException) to avoid depending on the message text? The jimage already imports jdk.tools.jlink.internal classes so adding an exception to this package is okay.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29723#discussion_r2807179766

From jpai at openjdk.org  Sat Feb 14 09:16:19 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 14 Feb 2026 09:16:19 GMT
Subject: RFR: 8377857: Add since checker test for java.naming module [v2]
In-Reply-To: <qHKyK1ANNWaYg1H5xJUk_ihQhou2tJVMCgS6KC72vvw=.920f7da7-9956-4ec2-a0e1-b24e0e47cf3b@github.com>
References: <i75aV2GS75Ug9CzaNXKrVq3TMB-t5cJFsrAaYe_puTI=.73e4f0f3-1fa7-4a6a-ab82-95dda2521682@github.com>
 <qHKyK1ANNWaYg1H5xJUk_ihQhou2tJVMCgS6KC72vvw=.920f7da7-9956-4ec2-a0e1-b24e0e47cf3b@github.com>
Message-ID: <48OfYHM5uMQPPltS9iPfN1AsNuy5bcrgRTwjRuli36Y=.8ce8f8d1-2438-479a-a919-bbc3c2350110@github.com>

On Fri, 13 Feb 2026 11:28:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which introduces a test to verify the usages of `@since` javadoc tags in the `java.naming` module? This addresses https://bugs.openjdk.org/browse/JDK-8377857.
>> 
>> The `SinceChecker` test utility has been in use for several modules, but wasn't added for java.naming. The commit in this PR adds one for that module.
>> 
>> The `SinceChecker` test utility does not handle the presence of a comma in (for example `@since X, Y`) correctly. The javadoc tag spec for `@since` allows that syntax https://docs.oracle.com/en/java/javase/25/docs/specs/javadoc/doc-comment-spec.html#since. As a workaround, the commit in this PR splits the `@since` on `javax.naming.InitialContext` class into two separate declarations (this too is allowed by the `@since` tag spec). I've verified that the generated javadoc continues to correctly show these values. I have also spoken to Nizar about this issue in SinceChecker and it will be addressed separately.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove reference to JNDI 1.1 in InitialContext

Thank you Alan for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29705#issuecomment-3901539802

From jpai at openjdk.org  Sat Feb 14 09:16:20 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 14 Feb 2026 09:16:20 GMT
Subject: Integrated: 8377857: Add since checker test for java.naming module
In-Reply-To: <i75aV2GS75Ug9CzaNXKrVq3TMB-t5cJFsrAaYe_puTI=.73e4f0f3-1fa7-4a6a-ab82-95dda2521682@github.com>
References: <i75aV2GS75Ug9CzaNXKrVq3TMB-t5cJFsrAaYe_puTI=.73e4f0f3-1fa7-4a6a-ab82-95dda2521682@github.com>
Message-ID: <KB01ereA7G7foVhiLICNM6333Cs1g4LMzozKgsjRF9c=.5da8e449-dfbb-47ea-b977-2111fbd4e3a0@github.com>

On Fri, 13 Feb 2026 02:00:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which introduces a test to verify the usages of `@since` javadoc tags in the `java.naming` module? This addresses https://bugs.openjdk.org/browse/JDK-8377857.
> 
> The `SinceChecker` test utility has been in use for several modules, but wasn't added for java.naming. The commit in this PR adds one for that module.
> 
> The `SinceChecker` test utility does not handle the presence of a comma in (for example `@since X, Y`) correctly. The javadoc tag spec for `@since` allows that syntax https://docs.oracle.com/en/java/javase/25/docs/specs/javadoc/doc-comment-spec.html#since. As a workaround, the commit in this PR splits the `@since` on `javax.naming.InitialContext` class into two separate declarations (this too is allowed by the `@since` tag spec). I've verified that the generated javadoc continues to correctly show these values. I have also spoken to Nizar about this issue in SinceChecker and it will be addressed separately.

This pull request has now been integrated.

Changeset: 49e2a6b6
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/49e2a6b696c2063f0b4331b0a6d064852d676fcd
Stats:     31 lines in 2 files changed: 29 ins; 0 del; 2 mod

8377857: Add since checker test for java.naming module

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/29705

From liach at openjdk.org  Sat Feb 14 12:23:09 2026
From: liach at openjdk.org (Chen Liang)
Date: Sat, 14 Feb 2026 12:23:09 GMT
Subject: RFR: 8377712: ConstantPool of WeakReferenceKey is not
 deterministic in CDS archive [v2]
In-Reply-To: <uxNkdMinqTfNSzIWdNkjttFJckj7ey_gq3sl9b9Pb5k=.b669cf19-f666-42d3-9120-1c5a9119eb1d@github.com>
References: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
 <uxNkdMinqTfNSzIWdNkjttFJckj7ey_gq3sl9b9Pb5k=.b669cf19-f666-42d3-9120-1c5a9119eb1d@github.com>
Message-ID: <UYf2vL_8rTaQYttEfUq9epVmRKsZ-qBND1R1Rriij3k=.ee518079-8227-487f-a92e-c63c9fa79d1f@github.com>

On Sat, 14 Feb 2026 07:23:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> We are seeing intermittent failures (12 times in Jan 2026) where the CDS archives generated in the JDK build is not deterministic.
>> 
>> The symptom is that (perhaps due to the peculiarity of hash codes and memory addressing??) the constant pool entry for `ReferenceKey<?>` in the `WeakReferenceKey` class is not resolved when the failure happens.
>> 
>> The fix is for the JVM to call a method in `WeakReferenceKey` to force this entry to be resolved.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @liach comments

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29678#pullrequestreview-3801736292

From duke at openjdk.org  Sat Feb 14 14:43:16 2026
From: duke at openjdk.org (duke)
Date: Sat, 14 Feb 2026 14:43:16 GMT
Subject: Withdrawn: 8373288: EnumMap spliterators should include more specific
 characteristics
In-Reply-To: <nQF4qypP6w1WLCnM9bCpje7IQ1TdkXWTCELMa3QCG6k=.f9a1928d-df61-4d58-95f9-d450c9917411@github.com>
References: <nQF4qypP6w1WLCnM9bCpje7IQ1TdkXWTCELMa3QCG6k=.f9a1928d-df61-4d58-95f9-d450c9917411@github.com>
Message-ID: <oEIPJPjMOGc9g_C-X8SU_Z0et9aCc_14P6FSXcrPuXs=.74af2251-bdff-4176-9eb2-24941fd2dc15@github.com>

On Tue, 16 Dec 2025 04:42:53 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> The spliterators returned by keySet, entrySet, and values were not reporting additional characteristics, such as ORDERED, SORTED, and NONNULL; the EnumMap iterators all guarantee iteration is in the natural order of the enum key, and nulls are disallowed as keys.
> 
> Null values are allowed, so the values collection can only additionally report ORDERED.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/28840

From duke at openjdk.org  Sat Feb 14 21:57:39 2026
From: duke at openjdk.org (duke)
Date: Sat, 14 Feb 2026 21:57:39 GMT
Subject: RFR: 8377729: Running jtreg tests with -agent... option causes
 some tests to fail due to duplicate -agent options provided to a subprocess
 [v2]
In-Reply-To: <VfYMw1R5GJvQB43PPP-mQbBwQFAbRugPcsrAZEVYFik=.5c67dd1c-0523-4ba4-98c7-5986eaff2123@github.com>
References: <Xx7VPlNQy-Svo7fkKo71gYLrSJ4nTxyyGnwEpXyfeyQ=.4cdbed9d-b09c-4c74-8a0e-1c27e620a825@github.com>
 <VfYMw1R5GJvQB43PPP-mQbBwQFAbRugPcsrAZEVYFik=.5c67dd1c-0523-4ba4-98c7-5986eaff2123@github.com>
Message-ID: <f7kYfuiYn9TWUAv_iyu_dTfawctFQr3ZoHeq4VpAbIg=.1cd106b8-4479-490e-a9bb-cc023d933215@github.com>

On Sat, 14 Feb 2026 02:37:25 GMT, Kirill Shirokov <kshiroko at openjdk.org> wrote:

>> The fix removes duplicate `-agent...` and `-javaagent:...` options from test subprocess command line, thus allowing to run jtreg tests with agents that should be specified only once.
>> 
>> The fix tested manually:
>> 
>> 
>> $ make test JTREG="VERBOSE=summary,fail,error" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>>    jtreg:test/jdk/sun/tools/jstack/DeadlockDetectionTest.java
>>                                                          1     1     0     0     0
>>    jtreg:test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java
>>                                                          1     1     0     0     0
>>    jtreg:test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java
>>                                                          1     1     0     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> $ make test JTREG="VERBOSE=summary,fail,error;JAVA_OPTIONS=-agentpath.../async-profiler-binaries/lib/libasyncProfiler.dylib=start,event=cpu,cstack=vm,loglevel=none,flat,file=/dev/null" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>>    jtreg:test/jdk/sun/tools/jstack/DeadlockDetectionTest.java
>>>>                                                       1     0     1     0     0 <<
>>    jtreg:test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java
>>>>                                                       1     0     1     0     0 <<
>>    jtreg:test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java
>>>>                                                       1     0     1     0     0 <<
>> ==============================
>> TEST FAILURE
>> 
>> $ make test JTREG="VERBOSE=summary,fail,error;VM_OPTIONS=-agentpath:.../async-profiler-binaries/lib/libasyncProfiler.dylib=start,event=cpu,cstack=vm,loglevel=none,flat,file=/dev/null" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/...
>
> Kirill Shirokov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailing whitespace
>  - Removed duplicate VM options from test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java, test/jdk/sun/tools/jstack/DeadlockDetectionTest.java, test/lib/jdk/test/lib/apps/LingeredApp.java, test/lib/jdk/test/lib/cli/CommandLineOptionTest.java. Added duplicate agent options warning to ProcessTools-spawned subprocesses and LingeredApp

@kirill-shirokov 
Your change (at version f6835f93598d43e7bddb5f486c6e5bcb8474dae7) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29684#issuecomment-3902605156

From lmesnik at openjdk.org  Sat Feb 14 22:29:01 2026
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 14 Feb 2026 22:29:01 GMT
Subject: RFR: 8377729: Running jtreg tests with -agent... option causes
 some tests to fail due to duplicate -agent options provided to a subprocess
 [v2]
In-Reply-To: <VfYMw1R5GJvQB43PPP-mQbBwQFAbRugPcsrAZEVYFik=.5c67dd1c-0523-4ba4-98c7-5986eaff2123@github.com>
References: <Xx7VPlNQy-Svo7fkKo71gYLrSJ4nTxyyGnwEpXyfeyQ=.4cdbed9d-b09c-4c74-8a0e-1c27e620a825@github.com>
 <VfYMw1R5GJvQB43PPP-mQbBwQFAbRugPcsrAZEVYFik=.5c67dd1c-0523-4ba4-98c7-5986eaff2123@github.com>
Message-ID: <TUlHtgQ-9_CH60hfJziOAiGfOncQEvaiaesYkG10fB0=.cbbc0af6-b19d-4513-8fb8-b46aa44cb008@github.com>

On Sat, 14 Feb 2026 02:37:25 GMT, Kirill Shirokov <kshiroko at openjdk.org> wrote:

>> The fix removes duplicate `-agent...` and `-javaagent:...` options from test subprocess command line, thus allowing to run jtreg tests with agents that should be specified only once.
>> 
>> The fix tested manually:
>> 
>> 
>> $ make test JTREG="VERBOSE=summary,fail,error" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>>    jtreg:test/jdk/sun/tools/jstack/DeadlockDetectionTest.java
>>                                                          1     1     0     0     0
>>    jtreg:test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java
>>                                                          1     1     0     0     0
>>    jtreg:test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java
>>                                                          1     1     0     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> $ make test JTREG="VERBOSE=summary,fail,error;JAVA_OPTIONS=-agentpath.../async-profiler-binaries/lib/libasyncProfiler.dylib=start,event=cpu,cstack=vm,loglevel=none,flat,file=/dev/null" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>>    jtreg:test/jdk/sun/tools/jstack/DeadlockDetectionTest.java
>>>>                                                       1     0     1     0     0 <<
>>    jtreg:test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java
>>>>                                                       1     0     1     0     0 <<
>>    jtreg:test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java
>>>>                                                       1     0     1     0     0 <<
>> ==============================
>> TEST FAILURE
>> 
>> $ make test JTREG="VERBOSE=summary,fail,error;VM_OPTIONS=-agentpath:.../async-profiler-binaries/lib/libasyncProfiler.dylib=start,event=cpu,cstack=vm,loglevel=none,flat,file=/dev/null" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/...
>
> Kirill Shirokov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailing whitespace
>  - Removed duplicate VM options from test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java, test/jdk/sun/tools/jstack/DeadlockDetectionTest.java, test/lib/jdk/test/lib/apps/LingeredApp.java, test/lib/jdk/test/lib/cli/CommandLineOptionTest.java. Added duplicate agent options warning to ProcessTools-spawned subprocesses and LingeredApp

@kirill-shirokov Just reminder: any non-trivial hotspot-related fix requires at least 2 reviews. Only one of them might be from 'R'eviewer. So I'll wait for second review before sponsoring the fix.
Also, we have rule to wait at least 24 hours before pushing non-trivial fixes. (Totally fine for this fix.)

Trivial fixes require only one review from 'R'eviewer and could be pushed immediately.  
The trivial fix is a simple fix or clean backout, for which author and reviewer explicitly confirm it's 'triviality'.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29684#issuecomment-3902673191

From iklam at openjdk.org  Sun Feb 15 06:01:02 2026
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 15 Feb 2026 06:01:02 GMT
Subject: RFR: 8366736: Closed System.out causes child process to hang on
 Windows [v7]
In-Reply-To: <vqHAVUjnueYJWmDZCsWMfTGSSM1nsB9u0otRCwU8w0k=.f28a2d52-f2cc-4576-8473-510ff02492fa@github.com>
References: <vqHAVUjnueYJWmDZCsWMfTGSSM1nsB9u0otRCwU8w0k=.f28a2d52-f2cc-4576-8473-510ff02492fa@github.com>
Message-ID: <GxvrOhhQRhrtGEn6lAQx5QN_fOKFgT-BOWVs7s9q8AI=.c4a22cc2-c982-4ae5-8f98-50141c2fff20@github.com>

> The bug is here on line 121:
> 
> https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121
> 
> If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168:
> 
> https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184
> 
> However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up.
> 
> The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed.

Ioi Lam 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:

 - Review comment by @AlanBateman: use implNote instead. Also fixed whitespaces
 - Merge branch 'master' into 8366736-closed-system-out-causes-child-process-to-hang-on-windows
 - @RogerRiggs review comments
 - Fixed typo
 - fixed typo
 - Merge branch 'master' into 8366736-closed-system-out-causes-child-process-to-hang-on-windows
 - Review comments from @RogerRiggs
 - Reverted previous unintended commit
 - 8375654: Exclude all array classes from dynamic CDS archive
 - Review comments from @RogerRiggs
 - ... and 1 more: https://git.openjdk.org/jdk/compare/46ecfee8...bc999867

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29198/files
  - new: https://git.openjdk.org/jdk/pull/29198/files/6210d8b2..bc999867

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29198&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29198&range=05-06

  Stats: 105676 lines in 1961 files changed: 50340 ins; 24875 del; 30461 mod
  Patch: https://git.openjdk.org/jdk/pull/29198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29198/head:pull/29198

PR: https://git.openjdk.org/jdk/pull/29198

From iklam at openjdk.org  Sun Feb 15 06:01:03 2026
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 15 Feb 2026 06:01:03 GMT
Subject: RFR: 8366736: Closed System.out causes child process to hang on
 Windows [v5]
In-Reply-To: <fuUh7saw6dP1YYrh5vYbNUHnjNF-BpHUqU00JUm0los=.bbf34113-9d5a-48fb-b551-6453e195694b@github.com>
References: <vqHAVUjnueYJWmDZCsWMfTGSSM1nsB9u0otRCwU8w0k=.f28a2d52-f2cc-4576-8473-510ff02492fa@github.com>
 <NyS9Zqe01kz1OvO3igGTyUJYXY2FnGjJukoHBXgYWiM=.a12c97e7-fac6-4098-ab42-afd451fe2e00@github.com>
 <5xgLKc-ZPAbyGkESLU1q-oBEQxJDM39-GDewSWTH3Qc=.ce699522-77ea-4b4b-88d8-76eb51809868@github.com>
 <VJmb1RVOZq3u0P7zB0ECX0YivRsVW3K-ldp5sNVfDE0=.6adcfb31-6fbd-4cb1-a9b4-15d2f34cb55f@github.com>
 <fuUh7saw6dP1YYrh5vYbNUHnjNF-BpHUqU00JUm0los=.bbf34113-9d5a-48fb-b551-6453e195694b@github.com>
Message-ID: <M_1lKqIWPQrsqkI0rtcViPKRGmeCVeRi4hBTIP3NZoc=.99052aec-8fe2-482e-861d-89baf0560fe8@github.com>

On Tue, 27 Jan 2026 08:02:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thank Roger. I updated the text as you suggested and create the CSR: [JDK-8376413](https://bugs.openjdk.org/browse/JDK-8376413)
>
> API notes provide "commentary, rationale, or examples pertaining to the API". They don't strictly require a CSR as they aren't spec.
> 
> I think the proposed note is closer to an implNote as it is documenting what the JDK implementation does if the out/error streams are closed. We could potentially consider promoting it to spec, requiring all implementations to discard in this case, maybe you've discussed this already?

I changed it to use `@implNote`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29198#discussion_r2808604835

From syan at openjdk.org  Sun Feb 15 13:23:44 2026
From: syan at openjdk.org (SendaoYan)
Date: Sun, 15 Feb 2026 13:23:44 GMT
Subject: RFR: 8377944: LowMemoryTest2.java#id1 intermittent fails OOME:
 Metaspace
Message-ID: <9l50ZncWoVxBjcdo1npkXCgqZyByRF231ajZ9UMDFGc=.b6e1dd11-b2d5-4f94-9e4c-2655183ffc35@github.com>

Hi all,

Test java/lang/management/MemoryMXBean/LowMemoryTest2.java#id1 intermittent fails "java.lang.OutOfMemoryError: Metaspace". The test log shows that MemoryPoolMXBean.isUsageThresholdExceeded() always return true but MemoryPoolMXBean.getUsageThresholdCount() always return zero. The comment in this test says that "UsageThresholdCount is only updated during GC.", so it seems that the System.gc() do not trigger GC actually, so test always allocate new classes and then throw OOME in metaspace.

This PR use `WhiteBox.getWhiteBox().fullGC()` instead of `System.gc()` to make sure the GC to be trigger all the time. Change has been verified locally on linux-aarch64 and linux-x64.

-------------

Commit messages:
 - Update copyright year
 - 8377944: LowMemoryTest2.java#id1 intermittent fails OOME: Metaspace

Changes: https://git.openjdk.org/jdk/pull/29729/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29729&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377944
  Stats: 16 lines in 1 file changed: 2 ins; 4 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/29729.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29729/head:pull/29729

PR: https://git.openjdk.org/jdk/pull/29729

From dl at openjdk.org  Sun Feb 15 18:08:30 2026
From: dl at openjdk.org (Doug Lea)
Date: Sun, 15 Feb 2026 18:08:30 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v35]
In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
Message-ID: <noHOLiLQdN6uz5GSuSxZMbfB9NGt94QAXEeLidtERUM=.7373119f-ae0e-43c9-9b74-dda96a67cd71@github.com>

> Changes signal filtering to avoid possible starvation

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  re-incorporate other improvements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28797/files
  - new: https://git.openjdk.org/jdk/pull/28797/files/a888b182..dc4cf9e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=33-34

  Stats: 640 lines in 2 files changed: 160 ins; 195 del; 285 mod
  Patch: https://git.openjdk.org/jdk/pull/28797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28797/head:pull/28797

PR: https://git.openjdk.org/jdk/pull/28797

From dl at openjdk.org  Sun Feb 15 21:05:06 2026
From: dl at openjdk.org (Doug Lea)
Date: Sun, 15 Feb 2026 21:05:06 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v36]
In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
Message-ID: <9VQj8YKwyyiDNNgojLT_DEG_KUdvs34HgSUWuOMQ0tE=.c04e5c16-8203-42b6-a23d-77443dd1c0a3@github.com>

> Changes signal filtering to avoid possible starvation

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 49 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8373118
 - re-incorporate other improvements
 - For testing: revert to 26 except for redundant signals
 - Revert some layout and sizing, better match spin vs scan
 - Merge branch 'openjdk:master' into JDK-8373118
 - setup for helpJoin
 - Merge branch 'openjdk:master' into JDK-8373118
 - reduce interference after stalls
 - Avoid yield, for performance test
 - Don't oversignal LIFO
 - ... and 39 more: https://git.openjdk.org/jdk/compare/a613b60b...6fc2eb85

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28797/files
  - new: https://git.openjdk.org/jdk/pull/28797/files/dc4cf9e5..6fc2eb85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=34-35

  Stats: 24499 lines in 543 files changed: 11042 ins; 3337 del; 10120 mod
  Patch: https://git.openjdk.org/jdk/pull/28797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28797/head:pull/28797

PR: https://git.openjdk.org/jdk/pull/28797

From dl at openjdk.org  Sun Feb 15 21:29:31 2026
From: dl at openjdk.org (Doug Lea)
Date: Sun, 15 Feb 2026 21:29:31 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v37]
In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
Message-ID: <mdqsboON9HDQdxlmWRQC46WMb8LLSt5iSpOwTZoTOdk=.ce9fc9b5-9304-4a1c-9682-53c3331961db@github.com>

> Changes signal filtering to avoid possible starvation

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Fix incomplete reintroduction of trimStatus

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28797/files
  - new: https://git.openjdk.org/jdk/pull/28797/files/6fc2eb85..50b81c45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=35-36

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28797/head:pull/28797

PR: https://git.openjdk.org/jdk/pull/28797

From rriggs at openjdk.org  Sun Feb 15 22:18:10 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Sun, 15 Feb 2026 22:18:10 GMT
Subject: RFR: 8366736: Closed System.out causes child process to hang on
 Windows [v7]
In-Reply-To: <GxvrOhhQRhrtGEn6lAQx5QN_fOKFgT-BOWVs7s9q8AI=.c4a22cc2-c982-4ae5-8f98-50141c2fff20@github.com>
References: <vqHAVUjnueYJWmDZCsWMfTGSSM1nsB9u0otRCwU8w0k=.f28a2d52-f2cc-4576-8473-510ff02492fa@github.com>
 <GxvrOhhQRhrtGEn6lAQx5QN_fOKFgT-BOWVs7s9q8AI=.c4a22cc2-c982-4ae5-8f98-50141c2fff20@github.com>
Message-ID: <O-wWUdwewIulAMH4_6G_1xDVHAsXIbvWUXnjpATxeQQ=.5fee6668-fc3f-49da-ad62-6fb869a1d001@github.com>

On Sun, 15 Feb 2026 06:01:02 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The bug is here on line 121:
>> 
>> https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121
>> 
>> If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168:
>> 
>> https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184
>> 
>> However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up.
>> 
>> The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed.
>
> Ioi Lam 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:
> 
>  - Review comment by @AlanBateman: use implNote instead. Also fixed whitespaces
>  - Merge branch 'master' into 8366736-closed-system-out-causes-child-process-to-hang-on-windows
>  - @RogerRiggs review comments
>  - Fixed typo
>  - fixed typo
>  - Merge branch 'master' into 8366736-closed-system-out-causes-child-process-to-hang-on-windows
>  - Review comments from @RogerRiggs
>  - Reverted previous unintended commit
>  - 8375654: Exclude all array classes from dynamic CDS archive
>  - Review comments from @RogerRiggs
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/6d00da44...bc999867

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29198#pullrequestreview-3805643832

From aartemov at openjdk.org  Mon Feb 16 08:30:35 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 16 Feb 2026 08:30:35 GMT
Subject: RFR: 8376665: Port fdlibm acosh to Java [v9]
In-Reply-To: <8Aa15ErOwvGDWlwsoPoDk72EP0Oj0NCV14UMkrpurYc=.d3a6c8a2-b2b1-4845-8550-fcb82bde9786@github.com>
References: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
 <8Aa15ErOwvGDWlwsoPoDk72EP0Oj0NCV14UMkrpurYc=.d3a6c8a2-b2b1-4845-8550-fcb82bde9786@github.com>
Message-ID: <Z6BOeJ0Ieypmxvmwjv-ggA_y-NBaOb23pNXlWghE0s4=.c415c1eb-1db4-4344-a375-3b18f3ed4cce@github.com>

On Thu, 12 Feb 2026 12:04:41 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM acosh method.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8376665: Fixed whitespaces.

Thanks for reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29488#issuecomment-3907086316

From aartemov at openjdk.org  Mon Feb 16 08:30:36 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 16 Feb 2026 08:30:36 GMT
Subject: Integrated: 8376665: Port fdlibm acosh to Java
In-Reply-To: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
References: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com>
Message-ID: <juTm-WbCbomJbKxYeNpWUSNy8gkZ679gN-mcy-IEUxA=.db174d4c-cb11-487b-8681-7e1f3b14b194@github.com>

On Thu, 29 Jan 2026 14:56:49 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM acosh method.

This pull request has now been integrated.

Changeset: b9406a5d
Author:    Anton Artemov <aartemov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9406a5dbaac7082419ea936f3cc3e61e6ac96d0
Stats:     580 lines in 7 files changed: 571 ins; 0 del; 9 mod

8376665: Port fdlibm acosh to Java

Reviewed-by: rgiulietti, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/29488

From jpai at openjdk.org  Mon Feb 16 10:37:10 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Feb 2026 10:37:10 GMT
Subject: RFR: 8296183: jndiprovider.properties contains properties pointing
 to non-existing classes [v2]
In-Reply-To: <5KrG_KONacK8ssoB822zQJZ2mP772ddAOPrEnAB5dBw=.954d7d11-ba31-405a-a2b1-2b1de23c0b15@github.com>
References: <0PbWMGiYmaL3AtLCxUsYOMDxmw-fQOjcJnR5KKQEvVo=.c83ca2a4-c2c1-4216-8548-e59dcefc8c94@github.com>
 <y14p-e5AulGqByGkPLHzA6Uj7K5jhTUKYY-9QdoqLLU=.13990294-8e6f-4a06-b4c3-28a1cffb9b10@github.com>
 <5KrG_KONacK8ssoB822zQJZ2mP772ddAOPrEnAB5dBw=.954d7d11-ba31-405a-a2b1-2b1de23c0b15@github.com>
Message-ID: <MNaUDhM8z6773ZoCn3KaDHj8ao5oorvmdRJheo7OS9E=.0bb8d9d0-59ff-4c78-a5f5-977ba3b99032@github.com>

On Fri, 13 Feb 2026 21:13:00 GMT, Anirvan Sarkar <asarkar at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add reference to DefaultResponseControlFactory in javadoc
>
>>Looking at the version control history of the JDK, these classes haven't been around for several releases (not even in JDK 8)
> 
> It seems these classes were never part of the JDK.
> These classes were part of the (legacy?) JNDI/LDAP booster pack `ldapbp.jar` available as a separate download.
> The download file is currently `ldap-1_2_4.zip` in the Oracle Java Archive for Java Platform Technologies [1].
> 
> Software vendors required `ldapbp.jar` to be added to the `CLASSPATH`.
> The very old JNDI tutorial also references `ldapbp.jar` [2].
> 
> Booster pack has the following packages:
> 
> |          Package           |                     Contents                      |
> |----------------------------|---------------------------------------------------|
> | com.sun.jndi.ldap.obj      | RMI, CORBA support for LDAP Service Provider for JNDI |
> | com.sun.security.sasl.misc | CRAM-MD5, Anonymous, and Plain SASL Drivers       |
> | com.sun.jndi.ldap.ctl      | Controls for LDAP Service Provider for JNDI       |
> 
> The packages `com.sun.security.sasl.misc` and `com.sun.jndi.ldap.ctl` became obsolete when its support was included in the JDK 5.
> 
> I suspect the classes of package `com.sun.jndi.ldap.obj` were not included in JDK, as RFC 2713 & RFC 2714 were not standardized unlike other RFCs related to LDAP.
> 
> The booster pack is also available on Maven repository [3].
> Do you think any of its dependencies could be impacted by removal of `jndiprovider.properties` file?
> Should this removal be mentioned in the release notes? 
> 
> If you want to look at the booster pack?s source code, it?s included in GlassFish 5 [4].
> 
> [1] : https://www.oracle.com/java/technologies/java-archive-downloads-java-plat-downloads.html#7110-jndi-1.2.1-oth-JPR
> [2] : https://docs.oracle.com/javase/jndi/tutorial/objects/storing/index.html
> [3] : https://mvnrepository.com/artifact/com.sun/ldapbp
> [4] : https://github.com/javaee/glassfish/tree/master/appserver/ldapbp/src/main/java/com/sun/jndi/ldap

Thank you for those details @AnirvanSarkar. This helped understand where these values came from.

> Do you think any of its dependencies could be impacted by removal of jndiprovider.properties file? Should this removal be mentioned in the release notes?

Having read and reviewed those details, I think this will need a release note and also a CSR. The `jndiprovider.properties` that is shipped by the `java.naming` module references classes that don't belong to the JDK. Yet, some of the (seemingly outdated) documentation (including the tutorial you pointed to) instruct applications to include a LDAP provider specific JAR file in the classpath of the application and expect the LDAP provider to load the classes configured in the `java.naming` module's `jndiprovider.properties`.

Before the changes in this PR, code like the following


public class Test {
    public static void main(final String[] args) throws Exception {
        final Hashtable<String, String> envProps = new Hashtable<>();
        envProps.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
        envProps.put("java.naming.ldap.version", "3");
        envProps.put(Context.PROVIDER_URL, "ldap://127.0.0.1:12345"); // LDAP server
        final Context ctx =  NamingManager.getInitialContext(envProps);
        System.out.println("Got context " + ctx);
        final Object obj = NamingManager.getObjectInstance(new java.rmi.MarshalledObject<String>(new String("foo")), new LdapName("CN=foo"), ctx, envProps);
        System.out.println("Got object instance " + obj + " type " + obj.getClass());
    }
}


when launched with the LDAP booster pack JAR in the application classpath would return:


java -cp ldapbp-1.0.jar Test.java

Got context com.sun.jndi.ldap.LdapCtx at 1f3f4916
Got object instance foo type class java.lang.String

(notice the return type of `obj` is `java.lang.String`)

What this implies is that the LDAP service provider in the JDK picked up the `jndiprovider.properties` from the `java.naming` module and noticed the:


java.naming.factory.object=com.sun.jndi.ldap.obj.AttrsToCorba:com.sun.jndi.ldap.obj.MarshalledToObject


property value and loaded the `com.sun.jndi.ldap.obj.MarshalledToObject` from the JAR file in the application classpath and invoked it to return the `java.lang.String` output.

With the proposed change, the LDAP provider will no longer by default set the `java.naming.factory.object` (and the other two) properties. Thus the LDAP provider will no longer attempt to load `com.sun.jndi.ldap.obj.MarshalledToObject` and as a result, the same application code will now see the following result:



java -cp ldapbp-1.0.jar Test.java

Got context com.sun.jndi.ldap.LdapCtx at 14a2f921
Got object instance java.rmi.MarshalledObject at a546def5 type class java.rmi.MarshalledObject

(notice how the return type is now `java.rmi.MarshalledObject`)

So yes, this change will have an impact on applications.

The javadoc of `javax.naming.Context` specifies how/where the environment properties are picked up https://docs.oracle.com/en/java/javase/25/docs/api/java.naming/javax/naming/Context.html#resource-files-heading. With the change being proposed in this PR, the applications will now have to explicitly pass the values for:


java.naming.factory.control
java.naming.factory.object
java.naming.factory.state

if they want those values to be used by the LDAP service provider. So the application would have to do something like:


...
envProps.put("java.naming.factory.object", "com.sun.jndi.ldap.obj.AttrsToCorba:com.sun.jndi.ldap.obj.MarshalledToObject");
...


to instruct LDAP provider to use those classes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29712#issuecomment-3907698917

From per-ake.minborg at oracle.com  Mon Feb 16 11:06:01 2026
From: per-ake.minborg at oracle.com (Per-Ake Minborg)
Date: Mon, 16 Feb 2026 11:06:01 +0000
Subject: Add @Stable to Class#enumConstants.
In-Reply-To: <CAC4ELwH+76=NQ2k-BUSZiffW6Oz2wXMjB=7Np9vhr+6uBP4jnA@mail.gmail.com>
References: <CAC4ELwECZ-G58UAv-AQ01dtL22ZY8s6WQiU7FiDyh-4nDXhqEw@mail.gmail.com>
 <IA0SPRMB0009615B0623BF22DE50D398A260A@IA0SPRMB0009.namprd10.prod.outlook.com>
 <CAC4ELwH+76=NQ2k-BUSZiffW6Oz2wXMjB=7Np9vhr+6uBP4jnA@mail.gmail.com>
Message-ID: <SA1PR10MB7832CBC023B22034743EEFEBDA6CA@SA1PR10MB7832.namprd10.prod.outlook.com>

Confidential - Oracle Restricted \Including External Recipients

Hi Ryan, and thank you for your observations!

We are currently working on improved support for lazily computed values, where LazyConstant is just the first step.

As you say, there is room for improvement in the Class class, but I feel it would be better to await said improvements rather than doing an intermediate change that would soon be replaced anyhow.

I will add the enum-related methods you mentioned to our internal list of improvement candidates to be made once (and if) the next steps of lazy become available.

Thanks again,
Per Minborg

Confidential - Oracle Restricted \Including External Recipients
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Ryan Hallock <ryan at hallock.us>
Sent: Friday, February 13, 2026 2:20 AM
To: Chen Liang <chen.l.liang at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: Add @Stable to Class#enumConstants.

Hi Chen, just searching GitHub it seems there are 2600 results for Class#getEnumConstants()[0], from looking at them it's mostly used in a fallback scenario in most cases when they only have the Class. So I wouldn't be surprised if most of these callsites would never be able to be resolved, this was meant to be an example that's easy to make an IR test & micro benchmark for.

Class#enumConstants are also used in getting the universe of EnumMap, EnumSet, So call sites like EnumSet.noneOf(Class), and EnumMap(Class) would also benefit from such a change as it may be able to fold the volatile read. (untested)

In defense to using @Stable over LazyConstant is there would be a capturing lambda plus an LazyConstant allocated for every class even if it's not an Enum, then if you wanted to make LazyConstant itself lazy it would also require a @Stable to be able to fold. This seems like an antipattern. Also this kind of goes against the idea behind caching Class#enumConstants here as it is currently null if it's never used. As for the implementation I have in mind would also likely place the Unsafe#compareAndExchangeReference in the existing Class.Atomic as to still allow this being used early in the startup process similar to LazyConstant.

Please let me know if you have any additional questions.

Cheers,
Ryan Hallock

On Thu, Feb 12, 2026 at 11:46?PM Chen Liang <chen.l.liang at oracle.com<mailto:chen.l.liang at oracle.com>> wrote:
Hi Ryan, is there a use case where people call getEnumConstants() and access a fixed index of array element?

This is so far the only use case I can think of that would be negatively impacted by the lack of constant folding for this method.

In addition, I do not recommend adding more @Stable - we should consider better representations like LazyConstant.

Regards
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Ryan Hallock <ryan at hallock.us<mailto:ryan at hallock.us>>
Sent: Thursday, February 12, 2026 3:45 PM
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: Add @Stable to Class#enumConstants.

Hello, I am new to OpenJDK development and I want to propose changes to Class#enumConstants from Class#getEnumConstants()/Class#getSharedEnumConstants().

Currently consider the following example:
```java
enum E {
    A, B, C
}
E[] values = E.values();
E[] constants = E.class.getEnumConstants();
assert Arrays.equals(values, constants);
```
These methods provide an equal array of values, but they are treated differently. This is because the _constants_ stored by Class#enumConstants are non final and declared volatile. So C2 can't trust this call. Consider if I only wanted to access the value from an offset from these arrays.
```java
E value = values[0];
E constant = constants[0];
assert value == constant;
```
_constant_ would never be folded but _value_ would be.

So I propose the addition of @Stable annotation added to Class#enumConstants so _constant_ can be folded by C2. This is not a trivial change as it requires changing the data race to abide by @Stable. Could I be sponsored for this change (JBS issue as well)?

A future proposal would be adding @Stable to Class#enumConstantDirectory, though that can be a seperate enhancement as that might require changing of the data structure to allow folding. Let me know if it should be combined as the Stable annotation itself would be implemented in a similar way for both.

Thanks,
Ryan Hallock

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260216/04fb762c/attachment-0001.htm>

From jbhateja at openjdk.org  Mon Feb 16 11:08:36 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 16 Feb 2026 11:08:36 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v12]
In-Reply-To: <EUYLcTJ-tPZabk2LcLzwYne6MgOdrQ7PDqkx6lOvsJs=.7c5a65d0-0efc-4636-843d-93815f327a25@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <YbIRslmURu8J4TLXTCHEeo7F3IwpvGPiYMDA-6w7_xA=.386a3af7-73ac-42f2-9e05-d34c436872a7@github.com>
 <BCaFfmFgSFPW0kPql80L-9Uic7tu5fwpnXBLpn9uyP8=.b184ac3f-faac-4062-9b15-ad07ac5fe0c0@github.com>
 <EUYLcTJ-tPZabk2LcLzwYne6MgOdrQ7PDqkx6lOvsJs=.7c5a65d0-0efc-4636-843d-93815f327a25@github.com>
Message-ID: <YLta81jVynHz9hRiBgGk_cEdJyIq8fF2bnSZSq8u3bA=.85905c74-1ef3-4630-b519-5b56b4b6e022@github.com>

On Mon, 26 Jan 2026 17:43:41 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> LGTM! Thanks for your updating!
>
>> Hi @XiaohongGong , your comments have been addressed. Hi @sviswa7, can you kindly review x86 part.
> 
> Thanks @jatin-bhateja. I will take a look next week.

Hi @sviswa7, @merykitty  Can you please review x86 backed implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3907840792

From dfuchs at openjdk.org  Mon Feb 16 12:40:59 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 16 Feb 2026 12:40:59 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v3]
In-Reply-To: <puhByiLbFFRHJTwHjnP2QQSmBidL-VksCwLbyYsau7E=.208136b8-5ec3-412e-8586-c8f357d876ce@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
 <puhByiLbFFRHJTwHjnP2QQSmBidL-VksCwLbyYsau7E=.208136b8-5ec3-412e-8586-c8f357d876ce@github.com>
Message-ID: <tf2vaqP1Mv2MdXw6xF7u8DJM3qt3JHQWTsWG6nQAkik=.02bc7816-5312-467e-9146-98091cbebe7d@github.com>

On Thu, 12 Feb 2026 13:49:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?
>> 
>> The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.
>> 
>> When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.
>> 
>> When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.
>> 
>> Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `Outp...
>
> 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 eight additional commits since the last revision:
> 
>  - merge latest from master branch
>  - merge latest from master branch
>  - add comment
>  - copyright years
>  - alternate fix
>  - rename test
>  - 8362268: NPE thrown from SASL GSSAPI impl when  TLS is  used with QOP auth-int against Active Directory
>  - introduce test

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 550:

> 548:             lock.lock();
> 549:             try {
> 550:                 outStream.write(ber.getBuf(), 0, ber.getDataLen());

I believe we should check `ldr.shouldAbandonRequest()` here again, while holding the lock. AFAICS the state is mutated in cleanup() while holding that lock, so we should check it again here once the lock is acquired.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29638#discussion_r2812238493

From qamai at openjdk.org  Mon Feb 16 14:09:23 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 16 Feb 2026 14:09:23 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v13]
In-Reply-To: <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
Message-ID: <CLbjCWRXNzWnGSVtjGympjUYR37KIMi3EFlClCkST5Y=.87a986cf-1b18-4aeb-9c85-89bb4cf596c9@github.com>

On Mon, 9 Feb 2026 21:36:16 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 with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - Review comments resolutions
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - Review comments resolutions
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - Update callGenerator.hpp copyright year
>  - Review comments resolution
>  - Cleanups
>  - Review comments resolutions
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/ffb6279c...1dfff558

I still think it is not a good solution to add an intrinsic method for this operation. We should add constant info to `TypeVect` and transform the slice pattern into `VectorSliceNode`. I think it is adequate to add bit info (zeros and ones) to each `TypeVect` instance so that we can do decent inference without too much additional memory overhead.

src/hotspot/share/opto/callGenerator.cpp line 703:

> 701:     // Attempt inlining fallback implementation in case of
> 702:     // intrinsification failure.
> 703:     if (new_jvms == nullptr && is_vector_late_inline()) {

This may be problematic if the intrinsification does not succeed because the arguments have not been constant-folded. It is because the order in which methods are processed during incremental inline is not deterministic.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24104#pullrequestreview-3808805022
PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2812585102

From eirbjo at openjdk.org  Mon Feb 16 14:38:50 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 16 Feb 2026 14:38:50 GMT
Subject: RFR: 8377978: Add ZipFile test for skipping unrelated ENDSIG found in
 padded bytes
Message-ID: <WOkTNM7MyiwwSvV2_ZK2EvwHgeBTqiSnVv_gVi3QNXs=.9c7cb7fc-1b76-44e9-9310-5c73acd23e34@github.com>

Please review this test-only PR which introduces a test for an edge case in `ZipFile.Source.findEND`.

ZIP files may some times have bytes padded to them after the fixed-size END header. This may be bytes of the comment or just unrelated bytes. Because of this ,`ZipFile.Source.findEnd()` parses the ZIP file in a "backwards" manner, looking for ENDSIG sequences indicating that a candidate END header is found.

If the position of the candidate END header and its declared comment length do not match up with the actual ZIP file length, this indicates padded bytes. In this case, `findEND()` will sanity check that the candidate END header points to LOCOFF  and CENOFF positions which actually have the expected LOCSIG and CENSIG bytes.

The case where a candidate END header is valid but has 'unexpected' bytes padded after it is currently tested by `ReadZip::bytesPaddedAtEnd`. However, there is no current testing for the case where an unrelated `ENDSIG` byte sequence is present in the padded bytes and the sanity check of the LOCOFF and CENOFF contents fails.

This is edge case is propably rare in the real world, but it would still be nice to have an automated test of this  scenario.

-------------

Commit messages:
 - Update copyright year
 - Add test for skipping unrelated ENDSIG bytes while looking for the "real" END header

Changes: https://git.openjdk.org/jdk/pull/29740/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29740&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377978
  Stats: 33 lines in 1 file changed: 32 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29740.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29740/head:pull/29740

PR: https://git.openjdk.org/jdk/pull/29740

From rgiulietti at openjdk.org  Mon Feb 16 14:53:21 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 16 Feb 2026 14:53:21 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v4]
In-Reply-To: <k2wep76JpSQOqjOaTDi2X2UPxRESgbeok11gLFEaSG4=.146ac5c4-c4b5-4d42-890f-315eabfe5aca@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
 <k2wep76JpSQOqjOaTDi2X2UPxRESgbeok11gLFEaSG4=.146ac5c4-c4b5-4d42-890f-315eabfe5aca@github.com>
Message-ID: <dzqIv_zJ21PIyqzqUx6C3TsuIpcDJiF3e5zDe0WyeNk=.b585d5e3-4785-42f5-b8aa-27d0c427e94a@github.com>

On Fri, 13 Feb 2026 18:17:50 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Moves input validation checks to Java for `java.lang.StringLatin1` intrinsics. While doing so, affected `java.lang.StringUTF16` methods needed to be updated due to relaxed checks at intrinsics. The javadocs of the touched methods are extensively overhauled.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More `indexOf` et al. guards and other review feedback

src/java.base/share/classes/java/lang/StringLatin1.java line 475:

> 473:             return 0;
> 474:         }
> 475:         if (value.length == 0) {

These checks could be removed altogether, and instead rely on those in the invoked method.

Alternatively, this line could be
Suggestion:

        if (value.length < str.length) {

to match https://github.com/openjdk/jdk/pull/28832/changes#diff-0429b143c93fceff618ecb5bb78b584f2b2ea4771241c7dd450ddb9151c1c515R511 more closely.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2812779334

From jbhateja at openjdk.org  Mon Feb 16 15:19:23 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 16 Feb 2026 15:19:23 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v13]
In-Reply-To: <CLbjCWRXNzWnGSVtjGympjUYR37KIMi3EFlClCkST5Y=.87a986cf-1b18-4aeb-9c85-89bb4cf596c9@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
 <CLbjCWRXNzWnGSVtjGympjUYR37KIMi3EFlClCkST5Y=.87a986cf-1b18-4aeb-9c85-89bb4cf596c9@github.com>
Message-ID: <kW5zcGPvbHHdyb2rkAR3Hm8Nk2WxI_r-pSDIuISU1lU=.454a4eb4-8e09-4b85-af03-6f02b16021d3@github.com>

On Mon, 16 Feb 2026 14:06:29 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> I still think it is not a good solution to add an intrinsic method for this operation. We should add constant info to `TypeVect` and transform the slice pattern into `VectorSliceNode`. I think it is adequate to add bit info (zeros and ones) to each `TypeVect` instance so that we can do decent inference without too much additional memory overhead.

What you are asking for is a bigger change which can be taken up as a separate RFE.

> src/hotspot/share/opto/callGenerator.cpp line 703:
> 
>> 701:     // Attempt inlining fallback implementation in case of
>> 702:     // intrinsification failure.
>> 703:     if (new_jvms == nullptr && is_vector_late_inline()) {
> 
> This may be problematic if the intrinsification does not succeed because the arguments have not been constant-folded. It is because the order in which methods are processed during incremental inline is not deterministic.

Hi @merykitty , Intrinsicification failure due to any such reason is same with and without this patch, in case of intrinsic failure we simply inline the fallback implementation which is comprised of vector APIs, VectorSupport* entry points of APIs should then go through intrinsification attempts independently.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3909009433
PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2812897947

From eirbjo at openjdk.org  Mon Feb 16 15:24:43 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 16 Feb 2026 15:24:43 GMT
Subject: RFR: 8377983: (zipfs) ZipFileSystem.initCEN needlessly reads END
 header
Message-ID: <R1BI_g2_9_Bi7sSf_cetduR1qiTroi9eFJiF3v9asW4=.fa2626dd-f105-4f95-9838-74c21fd7b27d@github.com>

Please review this cleanup PR which updates `ZipFileSystem.initCEN` to not include the END header when reading the CEN bytes into memory.

The inclusion of the (unused) END header is a remnant from conversion from native to Java in Java 9 and  was already fixed for the corresponding `ZipFile.Source.initCEN` via JDK-8339711.

Fixing this also in `ZipFileSystem` cleans up the code locally but more importantly brings the implemenation more into alignment with the `ZipFile`.

Pure refactoring / cleanup, `noreg-cleanup`.

-------------

Commit messages:
 - Don't include the END header when reading CEN into memory

Changes: https://git.openjdk.org/jdk/pull/29741/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29741&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377983
  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/29741.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29741/head:pull/29741

PR: https://git.openjdk.org/jdk/pull/29741

From eirbjo at gmail.com  Mon Feb 16 15:43:10 2026
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 16 Feb 2026 16:43:10 +0100
Subject: RFD: A plan to untangle ZipFile.Source.initCEN
In-Reply-To: <B86C541E-EB10-44E2-B091-C102B419CC7E@oracle.com>
References: <CA+pBWhsOxYX7+efPQVMk8c_XWBf5sG0oDrVURq1kM5xAocKiGA@mail.gmail.com>
 <A29CA46B-32BB-41D0-8B09-871296A8E2E7@oracle.com>
 <CA+pBWhsSYaqx0n1YPk2pVNT7pvfcSGFQN62QfHrqh843bcBtYA@mail.gmail.com>
 <B86C541E-EB10-44E2-B091-C102B419CC7E@oracle.com>
Message-ID: <CA+pBWhsHmOuTSawJZZ2VO5XfYC=kDwSPVME_22x8YJoPpEeYWQ@mail.gmail.com>

On Fri, Feb 13, 2026 at 8:43?PM Lance Andersen <lance.andersen at oracle.com>
wrote:


> Yes one of the goals should  be to share as much code as possible,
> regardless of where the initial changes are to ZipFile.   initCEN is
> similar in both instances WRT flow and would best to keep changes in mind
> so that they can easily be retrofitted to ZipFS with the hopes of having
> shared code making it easier to address issues that often apply to both due
> to CEN processing
>

Good, it seems our goals here are reasonably aligned: To pick apart initCEN
and make parts reusable across implementations. Reduce maintenance costs
caused by duplicated and difficult-to-understand code paths.


> Another area which you had indicated looking at is ZipCoder which there
> are 2 similar implementations between ZipFS and ZipFile et al.  I believe
> part of that is due to ZipFS starting as a demo but would be good to
> streamline and ideally get to 1 implementation if possible.  I have asked
> Sherman, who is the original author of ZipFS and worked extensively on Zip
> to chime in on your  ZipCoder suggestion.
>

Yes, ZipCoder also have a lot in common but have diverged over the years.
There may be slight differences in client needs, but I think most of it can
be aligned across implementations.

I have done a quick review of differences between ZipFile/ZipFileSystem
implementations and so far I have filed:

https://bugs.openjdk.org/browse/JDK-8377983 to make ZipFileSystem not read
the END header when reading the CEN

https://bugs.openjdk.org/browse/JDK-8377992 to align ZipFileSystem END
header validation with ZipFile.

https://bugs.openjdk.org/browse/JDK-8377978 to add a test for a
ZipFile.Source.findEND edge-case.

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260216/4d96ae96/attachment.htm>

From vyazici at openjdk.org  Mon Feb 16 19:12:38 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 16 Feb 2026 19:12:38 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v5]
In-Reply-To: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
Message-ID: <7ztqU2ZQDSt7EdBbHK4ExgkNKRsbRVTIeHzc3vbpyPo=.0bc5a45c-3535-4aab-a4ae-2035d7e03118@github.com>

> Moves input validation checks to Java for `java.lang.StringLatin1` intrinsics. While doing so, affected `java.lang.StringUTF16` methods needed to be updated due to relaxed checks at intrinsics. The javadocs of the touched methods are extensively overhauled.

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 16 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into sLatin1Intr
 - Remove redundant checks in `indexOf0(byte[] value, byte[] str)`
 - More `indexOf` et al. guards and other review feedback
 - Use `vmIntrinsics::*` to refer to intrinsics from Java
 - Improve vertical alignment in `vmIntrinsics.hpp`
 - Apply review feedback
 - More doc updates
 - Reflect that `VerifyIntrinsicChecks` is removed
 - Merge remote-tracking branch 'upstream/master' into sLatin1Intr
 - Fix `Helper`
 - ... and 6 more: https://git.openjdk.org/jdk/compare/87c57222...6eb75a06

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28832/files
  - new: https://git.openjdk.org/jdk/pull/28832/files/7efdc944..6eb75a06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28832&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28832&range=03-04

  Stats: 26826 lines in 591 files changed: 12839 ins; 3596 del; 10391 mod
  Patch: https://git.openjdk.org/jdk/pull/28832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28832/head:pull/28832

PR: https://git.openjdk.org/jdk/pull/28832

From vyazici at openjdk.org  Mon Feb 16 19:12:39 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 16 Feb 2026 19:12:39 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v4]
In-Reply-To: <dzqIv_zJ21PIyqzqUx6C3TsuIpcDJiF3e5zDe0WyeNk=.b585d5e3-4785-42f5-b8aa-27d0c427e94a@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
 <k2wep76JpSQOqjOaTDi2X2UPxRESgbeok11gLFEaSG4=.146ac5c4-c4b5-4d42-890f-315eabfe5aca@github.com>
 <dzqIv_zJ21PIyqzqUx6C3TsuIpcDJiF3e5zDe0WyeNk=.b585d5e3-4785-42f5-b8aa-27d0c427e94a@github.com>
Message-ID: <cfJ7j0wAvQ8W-mDKU6hybszqirBQqRPfAb-Z7g9TZeQ=.7477c479-72bb-416e-ad15-7ee4a897d6e6@github.com>

On Mon, 16 Feb 2026 14:46:09 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More `indexOf` et al. guards and other review feedback
>
> src/java.base/share/classes/java/lang/StringLatin1.java line 475:
> 
>> 473:             return 0;
>> 474:         }
>> 475:         if (value.length == 0) {
> 
> These checks could be removed altogether, and instead rely on those in the invoked method.
> 
> Alternatively, this line could be
> Suggestion:
> 
>         if (value.length < str.length) {
> 
> to match https://github.com/openjdk/jdk/pull/28832/changes#diff-0429b143c93fceff618ecb5bb78b584f2b2ea4771241c7dd450ddb9151c1c515R511 more closely.

Right. Removed the checks in 0966a6617d4.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28832#discussion_r2813738888

From iklam at openjdk.org  Mon Feb 16 20:27:45 2026
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 16 Feb 2026 20:27:45 GMT
Subject: RFR: 8366736: Closed System.out causes child process to hang on
 Windows [v2]
In-Reply-To: <ZZS77irELDBjVB4IV6JFmNvC6iC7HOMlTII0erkBOrw=.ff58572b-2ca4-4393-8adc-ffb667b1d7dd@github.com>
References: <vqHAVUjnueYJWmDZCsWMfTGSSM1nsB9u0otRCwU8w0k=.f28a2d52-f2cc-4576-8473-510ff02492fa@github.com>
 <G_YhrDHSV_I6rcfHW7O9j9WS8fw-F4geHlmBqX8tJ2E=.5f8ff002-aea2-4891-b2a6-da1a229eaf71@github.com>
 <ZZS77irELDBjVB4IV6JFmNvC6iC7HOMlTII0erkBOrw=.ff58572b-2ca4-4393-8adc-ffb667b1d7dd@github.com>
Message-ID: <URtPPrhYHU_SRcqCb7eFLXlV0GZ3IGc2en0ExXVmF8M=.170cc3eb-7f84-4350-aa89-2f803cac1634@github.com>

On Wed, 14 Jan 2026 14:40:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments from @RogerRiggs
>
> The change in behavior should be documented in an APINote on Process.inheritIO() to say that the output is discarded if it has been closed.

Thank you @RogerRiggs @AlanBateman for your review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29198#issuecomment-3910383520

From iklam at openjdk.org  Mon Feb 16 20:27:47 2026
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 16 Feb 2026 20:27:47 GMT
Subject: Integrated: 8366736: Closed System.out causes child process to hang on
 Windows
In-Reply-To: <vqHAVUjnueYJWmDZCsWMfTGSSM1nsB9u0otRCwU8w0k=.f28a2d52-f2cc-4576-8473-510ff02492fa@github.com>
References: <vqHAVUjnueYJWmDZCsWMfTGSSM1nsB9u0otRCwU8w0k=.f28a2d52-f2cc-4576-8473-510ff02492fa@github.com>
Message-ID: <MBsLR1rBIaEoAhH7qBA39c-Ietdoy2CH8VjBHc89rr4=.630eb7c3-f284-41a6-a6f8-c2beb738c535@github.com>

On Tue, 13 Jan 2026 16:52:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The bug is here on line 121:
> 
> https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121
> 
> If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168:
> 
> https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184
> 
> However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up.
> 
> The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed.

This pull request has now been integrated.

Changeset: c3b67387
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c3b67387c4c0891891c75f9001ba13feaae09017
Stats:     91 lines in 3 files changed: 89 ins; 0 del; 2 mod

8366736: Closed System.out causes child process to hang on Windows

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/29198

From duke at openjdk.org  Mon Feb 16 20:58:29 2026
From: duke at openjdk.org (duke)
Date: Mon, 16 Feb 2026 20:58:29 GMT
Subject: Withdrawn: 8373661: Add edge case tests for Objects.requireNonNull
 methods
In-Reply-To: <im14zlUJ7miczpuXNd_k3c-g6jngmbCowCx9doe8VVg=.a75768f4-6e8b-4893-a451-63eeb4e1230e@github.com>
References: <im14zlUJ7miczpuXNd_k3c-g6jngmbCowCx9doe8VVg=.a75768f4-6e8b-4893-a451-63eeb4e1230e@github.com>
Message-ID: <1oWAG42nvO8xYGMdxPG7Y3MOq9CBdKqB0KgXIDtWiqI=.9d1dd151-bb0f-4bbc-84c8-5d7b0c7420f3@github.com>

On Tue, 16 Dec 2025 13:22:40 GMT, Eunbin Son <duke at openjdk.org> wrote:

> ## Summary
> Adds comprehensive edge case tests for `Objects.requireNonNull`, 
> `requireNonNullElse`, and `requireNonNullElseGet` methods to improve 
> test coverage.
> 
> ## Problem
> The current test suite for `Objects.requireNonNull` methods covers 
> basic cases but lacks edge case coverage.
> 
> ## Solution
> This PR adds tests for the following edge cases:
> - requireNonNull with null Supplier parameter
> - requireNonNull with Supplier that throws exception
> - requireNonNullElse with both arguments null
> - requireNonNullElseGet with null supplier
> - requireNonNullElseGet with supplier returning null
> 
> ## Issue
> Fixes JDK-8373661
> 
> **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661
> 
> ## Type of Change
> - [x] Test addition/modification
> - [ ] Bug fix
> - [ ] New feature
> - [ ] Documentation improvement
> - [ ] Refactoring
> 
> ## Testing
> 
> make test TEST="jtreg:test/jdk/java/util/Objects"

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/28845

From duke at openjdk.org  Mon Feb 16 21:03:24 2026
From: duke at openjdk.org (David Beaumont)
Date: Mon, 16 Feb 2026 21:03:24 GMT
Subject: RFR: 8372301: Improve error message for jimage command line tool
 regarding version mismatch
In-Reply-To: <dKepWbG4WtDBxRGSQz_cvr6gnxM_fyK0nuXUUTegoOw=.275ab9b7-1c90-4dd2-a4bb-b1bbfee3f263@github.com>
References: <tnZEXnEKoaJ_ks5AwNXEn0mvUk9EjI24gdndpPWmHKo=.545e2ec6-a8b9-4b56-aff0-dece97a5c0f2@github.com>
 <dKepWbG4WtDBxRGSQz_cvr6gnxM_fyK0nuXUUTegoOw=.275ab9b7-1c90-4dd2-a4bb-b1bbfee3f263@github.com>
Message-ID: <lC4BC_Bq0flfLYOg1NwayGWxO3sWQQXWEUXi0e9YAQA=.d6bd79bb-01a8-40ef-ade6-62a2fac8f9e5@github.com>

On Sat, 14 Feb 2026 07:59:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> New implementation of improved JImageTask error message using string matching to detect the "version mismatch" error without needing code changes in the library.
>> 
>> Added tests for the error message and other ways in which the jimage file can be corrupt.
>
> src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 200:
> 
>> 198:                 result.getMinorVersion() != ImageHeader.MINOR_VERSION) {
>> 199:             // We rely on the sub-string "not the correct version" to detect
>> 200:             // version issues in JImageTask and give a better user message.
> 
> Is there any reason not to introduce an ImageVersionMismatchException (extends IOException) to avoid depending on the message text? The jimage tool already imports jdk.internal.jimage classes so adding an exception to this package is okay.

Discussing offline. See also:
https://github.com/openjdk/jdk/pull/28456/files/aa40f0c711cf5c02a243bda01d2e2d40d4b2b352#r2550365590

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29723#discussion_r2814027930

From dl at openjdk.org  Tue Feb 17 00:23:35 2026
From: dl at openjdk.org (Doug Lea)
Date: Tue, 17 Feb 2026 00:23:35 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v38]
In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
Message-ID: <PFtqO9afqYoSMl_Cpr78xbvAv4IAPiUaStnrc0GekRw=.576c51c3-dd4b-4507-9d69-4616f2e48475@github.com>

> Changes signal filtering to avoid possible starvation

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  More policy exploration

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28797/files
  - new: https://git.openjdk.org/jdk/pull/28797/files/50b81c45..5f84c2a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=37
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=36-37

  Stats: 107 lines in 1 file changed: 33 ins; 37 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/28797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28797/head:pull/28797

PR: https://git.openjdk.org/jdk/pull/28797

From qamai at openjdk.org  Tue Feb 17 04:59:16 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 17 Feb 2026 04:59:16 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v13]
In-Reply-To: <kW5zcGPvbHHdyb2rkAR3Hm8Nk2WxI_r-pSDIuISU1lU=.454a4eb4-8e09-4b85-af03-6f02b16021d3@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
 <CLbjCWRXNzWnGSVtjGympjUYR37KIMi3EFlClCkST5Y=.87a986cf-1b18-4aeb-9c85-89bb4cf596c9@github.com>
 <kW5zcGPvbHHdyb2rkAR3Hm8Nk2WxI_r-pSDIuISU1lU=.454a4eb4-8e09-4b85-af03-6f02b16021d3@github.com>
Message-ID: <cn0CHZ8CKvm_Uq5_g8g0urH6lJ-1J8zeYFMSlNibdzc=.cc542731-3e06-4904-99cc-ee336199bd67@github.com>

On Mon, 16 Feb 2026 15:12:54 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> What you are asking for is a bigger generic change which can be taken up as a separate RFE once this is committed.

I think there is no need to rush this functionality, and this will become unnecessary when `TypeVect` can track const-ness of the value, so we should not proceed with this change.

>> src/hotspot/share/opto/callGenerator.cpp line 703:
>> 
>>> 701:     // Attempt inlining fallback implementation in case of
>>> 702:     // intrinsification failure.
>>> 703:     if (new_jvms == nullptr && is_vector_late_inline()) {
>> 
>> This may be problematic if the intrinsification does not succeed because the arguments have not been constant-folded. It is because the order in which methods are processed during incremental inline is not deterministic.
>
> Hi @merykitty , Intrinsicification failure due to any such reason is same with and without this patch, in case of slice intrinsic failure we simply inline the fallback implementation which is comprised of vector APIs, VectorSupport* entry points of APIs should then go through intrinsification attempts independently and may succeeded or fail if constraints are not met.

`CallStaticJavaNode::Ideal` will enqueue the call for incremental inline again when it is invoked. That means if the method fails to get intrinsified at first, then its arguments constant-fold, then the intrinsification may succeed upon retry.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3912278853
PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2814976511

From alanb at openjdk.org  Tue Feb 17 06:21:27 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Feb 2026 06:21:27 GMT
Subject: RFR: 8366736: Closed System.out causes child process to hang on
 Windows [v7]
In-Reply-To: <GxvrOhhQRhrtGEn6lAQx5QN_fOKFgT-BOWVs7s9q8AI=.c4a22cc2-c982-4ae5-8f98-50141c2fff20@github.com>
References: <vqHAVUjnueYJWmDZCsWMfTGSSM1nsB9u0otRCwU8w0k=.f28a2d52-f2cc-4576-8473-510ff02492fa@github.com>
 <GxvrOhhQRhrtGEn6lAQx5QN_fOKFgT-BOWVs7s9q8AI=.c4a22cc2-c982-4ae5-8f98-50141c2fff20@github.com>
Message-ID: <hagZDWctHfdhWGM61-fH5n67Qe2iaMCHmRDRNsJigY0=.cd4a6a3d-9c91-4a31-822b-43f4d64a29f7@github.com>

On Sun, 15 Feb 2026 06:01:02 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The bug is here on line 121:
>> 
>> https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121
>> 
>> If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168:
>> 
>> https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184
>> 
>> However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up.
>> 
>> The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed.
>
> Ioi Lam 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:
> 
>  - Review comment by @AlanBateman: use implNote instead. Also fixed whitespaces
>  - Merge branch 'master' into 8366736-closed-system-out-causes-child-process-to-hang-on-windows
>  - @RogerRiggs review comments
>  - Fixed typo
>  - fixed typo
>  - Merge branch 'master' into 8366736-closed-system-out-causes-child-process-to-hang-on-windows
>  - Review comments from @RogerRiggs
>  - Reverted previous unintended commit
>  - 8375654: Exclude all array classes from dynamic CDS archive
>  - Review comments from @RogerRiggs
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f3eaab4c...bc999867

src/java.base/share/classes/java/lang/ProcessBuilder.java line 935:

> 933:      * @implNote
> 934:      * When the process is {@link #start started},
> 935:      * if {#code System.out} and/or {#code System.err} have been

Thanks for moving it to an implNote. For word smithing, It might be better to say "and System.out and/or System.err has been closed". Also it would be better to say the current VM rather than the current process here as these APIs relate to the current VM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29198#discussion_r2815168712

From jbhateja at openjdk.org  Tue Feb 17 08:02:56 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Feb 2026 08:02:56 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v21]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <-FLrWOvyAeSqraU3Z1wSeUrPNrH6K2SJSn9SJ4TqLgo=.10ed3cfc-5c41-440b-b8c6-a73e17ee284c@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Test cleanups and re-factoring
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Adding new lane type constants for intrinsic entries, removing basictype extension changes
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Clanups
 - Refactoring vectorIntrinsics
 - Refactoring and cleanups
 - Refactoring and cleanups
 - Review comments resolutions
 - ... and 28 more: https://git.openjdk.org/jdk/compare/03703f34...01d1579d

-------------

Changes: https://git.openjdk.org/jdk/pull/28002/files
  Webrev: Webrev is not available because diff is too large
  Stats: 520336 lines in 207 files changed: 285091 ins; 234369 del; 876 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

PR: https://git.openjdk.org/jdk/pull/28002

From jbhateja at openjdk.org  Tue Feb 17 08:12:08 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Feb 2026 08:12:08 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v22]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <b_rIiqfqh6Mf5nisNYMhKne8ci-Y6UA_U5BlzsORbAc=.4872b9da-7749-4ad2-98ee-c21cae4b82ef@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  JCheck whitespace fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28002/files
  - new: https://git.openjdk.org/jdk/pull/28002/files/01d1579d..592a9838

Webrevs:
 - full: Webrev is not available because diff is too large
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=20-21

  Stats: 12 lines in 6 files changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

PR: https://git.openjdk.org/jdk/pull/28002

From benjamin at engflow.com  Tue Feb 17 09:03:00 2026
From: benjamin at engflow.com (Benjamin Peterson)
Date: Tue, 17 Feb 2026 01:03:00 -0800
Subject: requesting review on JDK-8348828: Windows dll loading now
 resolves symlinks
In-Reply-To: <CAEmfU+ub+Y4_7QaC+r5fzgHXz_AzS6XLgBbYktJ4V4UNRcbiiw@mail.gmail.com>
References: <CAEmfU+ub+Y4_7QaC+r5fzgHXz_AzS6XLgBbYktJ4V4UNRcbiiw@mail.gmail.com>
Message-ID: <CAEmfU+ur54R6oYF732BC5DjKGsbZYVFwFtLejLHQg6newU55YA@mail.gmail.com>

Hi all, I'm gently probing this again. Since I started this thread,
some test cases were added to the PR. Then, a discussion with security
was privately opened:
https://github.com/openjdk/jdk/pull/24694#issuecomment-3419516424 I
realize some of this must be necessarily opaque to me, but I'm
wondering if any comment can be made about how far away the light at
the end of the tunnel is.

Regards,
Benjamin

On Tue, Oct 7, 2025 at 8:15?AM Benjamin Peterson <benjamin at engflow.com> wrote:
>
> I've had a PR for the native library loading code up for a months that
> I'd appreciate any review on:
> https://github.com/openjdk/jdk/pull/24694
>
> To summarize the issue and proposed fix: Before OpenJDK 24,
> System.loadLibrary on Windows passed symbolic links unresolved to the
> underlying LoadLibrary function. JDK-8003887 caused symbolic links to
> be resolved by Java before the system LoadLibrary function.
> Unfortunately, LoadLibrary is clever and may mangle the filename
> passed to it, which means passing a symlink may not have the same
> behavior as presenting the fully resolved path. I propose to fix this
> problem in the PR by disabling LoadLibrary's clever mangling behavior.
>
> Thank you for your time,
> Benjamin

From jbhateja at openjdk.org  Tue Feb 17 10:43:25 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Feb 2026 10:43:25 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v13]
In-Reply-To: <cn0CHZ8CKvm_Uq5_g8g0urH6lJ-1J8zeYFMSlNibdzc=.cc542731-3e06-4904-99cc-ee336199bd67@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
 <CLbjCWRXNzWnGSVtjGympjUYR37KIMi3EFlClCkST5Y=.87a986cf-1b18-4aeb-9c85-89bb4cf596c9@github.com>
 <kW5zcGPvbHHdyb2rkAR3Hm8Nk2WxI_r-pSDIuISU1lU=.454a4eb4-8e09-4b85-af03-6f02b16021d3@github.com>
 <cn0CHZ8CKvm_Uq5_g8g0urH6lJ-1J8zeYFMSlNibdzc=.cc542731-3e06-4904-99cc-ee336199bd67@github.com>
Message-ID: <-mNN8SPSvPoy7pes58gi6LSjd99zekix1ALZugP4IWE=.172b7fc6-5590-45d1-bcc1-66b2097ec295@github.com>

On Tue, 17 Feb 2026 04:56:54 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> > What you are asking for is a bigger generic change which can be taken up as a separate RFE once this is committed.
> 
> I think there is no need to rush this functionality, and this will become unnecessary when `TypeVect` can track const-ness of the value, so we should not proceed with this change.

Slice operations are used in simdjson UtfValidator and its better to push this patch rather than holding it for some future optimization.
https://github.com/simdjson/simdjson-java/pull/68

>> Hi @merykitty , Intrinsicification failure due to any such reason is same with and without this patch, in case of slice intrinsic failure we simply inline the fallback implementation which is comprised of vector APIs, VectorSupport* entry points of APIs should then go through intrinsification attempts independently and may succeeded or fail if constraints are not met.
>
> `CallStaticJavaNode::Ideal` will enqueue the call for incremental inline again when it is invoked. That means if the method fails to get intrinsified at first, then its arguments constant-fold, then the intrinsification may succeed upon retry.

I think there is no harm in-lining fallback after first un-successful attempt of intrinsification for sliceOp, as fallback is composed of vectorAPI and we are giving them opportunity for intrinsificaiton, this save costly boxing operation and performance will be at par with what we have today.  WDYT ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3913817406
PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2816261630

From jbhateja at openjdk.org  Tue Feb 17 10:50:27 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Feb 2026 10:50:27 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v13]
In-Reply-To: <cn0CHZ8CKvm_Uq5_g8g0urH6lJ-1J8zeYFMSlNibdzc=.cc542731-3e06-4904-99cc-ee336199bd67@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
 <CLbjCWRXNzWnGSVtjGympjUYR37KIMi3EFlClCkST5Y=.87a986cf-1b18-4aeb-9c85-89bb4cf596c9@github.com>
 <kW5zcGPvbHHdyb2rkAR3Hm8Nk2WxI_r-pSDIuISU1lU=.454a4eb4-8e09-4b85-af03-6f02b16021d3@github.com>
 <cn0CHZ8CKvm_Uq5_g8g0urH6lJ-1J8zeYFMSlNibdzc=.cc542731-3e06-4904-99cc-ee336199bd67@github.com>
Message-ID: <wW4vxoTIv9QVYayr1r2Q-PGdmYVoJqGUM1cSc0BtN7A=.b40923a7-1948-4eb4-ba7d-82f0ae6b764d@github.com>

On Tue, 17 Feb 2026 04:56:54 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> > What you are asking for is a bigger generic change which can be taken up as a separate RFE once this is committed.
> 
> I think there is no need to rush this functionality, and this will become unnecessary when `TypeVect` can track const-ness of the value, so we should not proceed with this change.

Slice operations are used in simdjson UtfValidator and its better to push this patch rather than holding it for some future optimization.
https://github.com/simdjson/simdjson-java/pull/68

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3913886057

From syan at openjdk.org  Tue Feb 17 11:07:21 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 17 Feb 2026 11:07:21 GMT
Subject: RFR: 8378083: Mark shenandoah/generational/TestOldGrowthTriggers.java
 as flagless
Message-ID: <pw48SEpIkI5iomzF6329jy_GVfCFmj_UIF9neXPzu9E=.bab851bb-2d35-4499-9b82-932f7f185ae6@github.com>

Hi all,

Test test/hotspot/jtreg/gc/shenandoah/generational/TestOldGrowthTriggers.java invoke ProcessTools.createLimitedTestJavaProcessBuilder call the test java process, I think we should mark this test as flagless to avoid duplication run when jtreg received extra jvm options.

This PR also remove the uesless 'import jdk.test.lib.Asserts' and fix the typo 'choose' in test/lib/jdk/test/lib/process/ProcessTools.java

-------------

Commit messages:
 - Fix typo choose in test/lib/jdk/test/lib/process/ProcessTools.java
 - 8378083: Mark shenandoah/generational/TestOldGrowthTriggers.java as flagless

Changes: https://git.openjdk.org/jdk/pull/29756/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29756&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378083
  Stats: 5 lines in 2 files changed: 1 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/29756.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29756/head:pull/29756

PR: https://git.openjdk.org/jdk/pull/29756

From qamai at openjdk.org  Tue Feb 17 11:33:51 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 17 Feb 2026 11:33:51 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v13]
In-Reply-To: <-mNN8SPSvPoy7pes58gi6LSjd99zekix1ALZugP4IWE=.172b7fc6-5590-45d1-bcc1-66b2097ec295@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
 <CLbjCWRXNzWnGSVtjGympjUYR37KIMi3EFlClCkST5Y=.87a986cf-1b18-4aeb-9c85-89bb4cf596c9@github.com>
 <kW5zcGPvbHHdyb2rkAR3Hm8Nk2WxI_r-pSDIuISU1lU=.454a4eb4-8e09-4b85-af03-6f02b16021d3@github.com>
 <cn0CHZ8CKvm_Uq5_g8g0urH6lJ-1J8zeYFMSlNibdzc=.cc542731-3e06-4904-99cc-ee336199bd67@github.com>
 <-mNN8SPSvPoy7pes58gi6LSjd99zekix1ALZugP4IWE=.172b7fc6-5590-45d1-bcc1-66b2097ec295@github.com>
Message-ID: <WXQJJukSU1B3w19GsBoGdwhK8MJdLRxjU9AkXh1XBmg=.73e41bca-0a0e-4047-b70e-2b95892bb832@github.com>

On Tue, 17 Feb 2026 10:37:09 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> `CallStaticJavaNode::Ideal` will enqueue the call for incremental inline again when it is invoked. That means if the method fails to get intrinsified at first, then its arguments constant-fold, then the intrinsification may succeed upon retry.
>
> I think there is no harm in-lining fallback after first un-successful attempt of intrinsification for sliceOp, as fallback is composed of vectorAPI and we are giving them opportunity for intrinsificaiton, this save costly boxing operation and performance will be at par with what we have today.  WDYT ?

But this will affect other intrinsics, too, they are not implemented using other vector API operations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2816552614

From alanb at openjdk.org  Tue Feb 17 11:43:27 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Feb 2026 11:43:27 GMT
Subject: RFR: 8376234: Migrate java/lang/constant tests away from TestNG
In-Reply-To: <OdyavIz4EF19kdDjM05Un-d0XGg3SNisPGcF_WHvAb4=.b26f0248-eb76-47df-9505-9690c8206b2d@github.com>
References: <OdyavIz4EF19kdDjM05Un-d0XGg3SNisPGcF_WHvAb4=.b26f0248-eb76-47df-9505-9690c8206b2d@github.com>
Message-ID: <oA3WVafJmEUCdOSNWx5mmy2p9cZbJcmS8btt_w9pqZU=.e3241092-489a-434c-a43a-c8f6baf6fe4a@github.com>

On Fri, 23 Jan 2026 22:10:06 GMT, Chen Liang <liach at openjdk.org> wrote:

> Convert all TestNG tests in java/lang/constant to JUnit tests.

I skimmed through the changes (and replaced) files, all looks reasonable.

test/jdk/java/lang/constant/java.base/jdk/internal/constant/ConstantAccess.java line 25:

> 23: package jdk.internal.constant;
> 24: 
> 25: // Exposes packaage-private methods for testing.

Typo in packaage-private

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29396#pullrequestreview-3813509073
PR Review Comment: https://git.openjdk.org/jdk/pull/29396#discussion_r2816598152

From jbhateja at openjdk.org  Tue Feb 17 12:14:36 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Feb 2026 12:14:36 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v13]
In-Reply-To: <WXQJJukSU1B3w19GsBoGdwhK8MJdLRxjU9AkXh1XBmg=.73e41bca-0a0e-4047-b70e-2b95892bb832@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
 <CLbjCWRXNzWnGSVtjGympjUYR37KIMi3EFlClCkST5Y=.87a986cf-1b18-4aeb-9c85-89bb4cf596c9@github.com>
 <kW5zcGPvbHHdyb2rkAR3Hm8Nk2WxI_r-pSDIuISU1lU=.454a4eb4-8e09-4b85-af03-6f02b16021d3@github.com>
 <cn0CHZ8CKvm_Uq5_g8g0urH6lJ-1J8zeYFMSlNibdzc=.cc542731-3e06-4904-99cc-ee336199bd67@github.com>
 <-mNN8SPSvPoy7pes58gi6LSjd99zekix1ALZugP4IWE=.172b7fc6-5590-45d1-bcc1-66b2097ec295@github.com>
 <WXQJJukSU1B3w19GsBoGdwhK8MJdLRxjU9AkXh1XBmg=.73e41bca-0a0e-4047-b70e-2b95892bb832@github.com>
Message-ID: <DbnRd_MfDZ5JhiCyA8gB-URCcUs3A7lMshbGpGgq9gs=.25b6c72d-f595-4912-85ca-4262f1723499@github.com>

On Tue, 17 Feb 2026 11:31:03 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> I think there is no harm in-lining fallback after first un-successful attempt of intrinsification for sliceOp, as fallback is composed of vectorAPI and we are giving them opportunity for intrinsificaiton, this save costly boxing operation and performance will be at par with what we have today.  WDYT ?
>
> But this will affect other intrinsics, too, they are not implemented using other vector API operations.

We only perform fallback inlining on first intrinsification failure for sliceOp, this is a very localized change.
https://github.com/jatin-bhateja/jdk/blob/1dfff5589c8b6c83dfc9810bddbb676c7982c904/src/hotspot/share/opto/callGenerator.cpp#L455

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2816730250

From jpai at openjdk.org  Tue Feb 17 12:15:18 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Feb 2026 12:15:18 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v4]
In-Reply-To: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
Message-ID: <kcqQpRVae7o8qcQS9NhXWnnOeSmwPnPNLO1Qm92AGIQ=.11b32446-6f66-4c47-a16b-d2f8cd6fcad3@github.com>

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?
> 
> The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.
> 
> When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.
> 
> When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.
> 
> Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `OutputStream` is a `Bu...

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 10 additional commits since the last revision:

 - Daniel's review - recheck while holding the lock
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - add comment
 - copyright years
 - alternate fix
 - rename test
 - 8362268: NPE thrown from SASL GSSAPI impl when  TLS is  used with QOP auth-int against Active Directory
 - introduce test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29638/files
  - new: https://git.openjdk.org/jdk/pull/29638/files/2c0973ab..52517a9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29638&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29638&range=02-03

  Stats: 14928 lines in 253 files changed: 5478 ins; 1202 del; 8248 mod
  Patch: https://git.openjdk.org/jdk/pull/29638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29638/head:pull/29638

PR: https://git.openjdk.org/jdk/pull/29638

From jpai at openjdk.org  Tue Feb 17 12:15:21 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Feb 2026 12:15:21 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v4]
In-Reply-To: <tf2vaqP1Mv2MdXw6xF7u8DJM3qt3JHQWTsWG6nQAkik=.02bc7816-5312-467e-9146-98091cbebe7d@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
 <puhByiLbFFRHJTwHjnP2QQSmBidL-VksCwLbyYsau7E=.208136b8-5ec3-412e-8586-c8f357d876ce@github.com>
 <tf2vaqP1Mv2MdXw6xF7u8DJM3qt3JHQWTsWG6nQAkik=.02bc7816-5312-467e-9146-98091cbebe7d@github.com>
Message-ID: <31O0HTXzeDVuP4rR6jxOf4W3mQJix_bCN-TJCMutEYQ=.9e345337-e55a-4ad9-8457-284d2b6463eb@github.com>

On Mon, 16 Feb 2026 12:38:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> 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 10 additional commits since the last revision:
>> 
>>  - Daniel's review - recheck while holding the lock
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - add comment
>>  - copyright years
>>  - alternate fix
>>  - rename test
>>  - 8362268: NPE thrown from SASL GSSAPI impl when  TLS is  used with QOP auth-int against Active Directory
>>  - introduce test
>
> src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 550:
> 
>> 548:             }
>> 549: 
>> 550:             lock.lock();
> 
> I believe we should check `ldr.shouldAbandonRequest()` here again, while holding the lock. AFAICS the state is mutated in cleanup() while holding that lock, so we should check it again here once the lock is acquired.

Thank you for catching that. You are right that a recheck is needed when holding the lock. I've updated the PR accordingly. Locally, the tests continue to pass with this change and tier testing in CI is currently in progress.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29638#discussion_r2816729536

From qamai at openjdk.org  Tue Feb 17 12:19:53 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 17 Feb 2026 12:19:53 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v13]
In-Reply-To: <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
Message-ID: <IQb5728TfwOd7fA2DQhyzODXAXKydcj4ktEJjxvfd6w=.2275fd48-834c-4e4c-8617-a6b6b297ff79@github.com>

On Mon, 9 Feb 2026 21:36:16 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 with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - Review comments resolutions
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - Review comments resolutions
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - Update callGenerator.hpp copyright year
>  - Review comments resolution
>  - Cleanups
>  - Review comments resolutions
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/ffb6279c...1dfff558

I don't agree with this change because the benefit is little, the intrinsic does not stand in the future, and the implementation is hacky and not trivial.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3914393663

From qamai at openjdk.org  Tue Feb 17 12:19:55 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 17 Feb 2026 12:19:55 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v13]
In-Reply-To: <DbnRd_MfDZ5JhiCyA8gB-URCcUs3A7lMshbGpGgq9gs=.25b6c72d-f595-4912-85ca-4262f1723499@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
 <CLbjCWRXNzWnGSVtjGympjUYR37KIMi3EFlClCkST5Y=.87a986cf-1b18-4aeb-9c85-89bb4cf596c9@github.com>
 <kW5zcGPvbHHdyb2rkAR3Hm8Nk2WxI_r-pSDIuISU1lU=.454a4eb4-8e09-4b85-af03-6f02b16021d3@github.com>
 <cn0CHZ8CKvm_Uq5_g8g0urH6lJ-1J8zeYFMSlNibdzc=.cc542731-3e06-4904-99cc-ee336199bd67@github.com>
 <-mNN8SPSvPoy7pes58gi6LSjd99zekix1ALZugP4IWE=.172b7fc6-5590-45d1-bcc1-66b2097ec295@github.com>
 <WXQJJukSU1B3w19GsBoGdwhK8MJdLRxjU9AkXh1XBmg=.73e41bca-0a0e-4047-b70e-2b95892bb832@github.com>
 <DbnRd_MfDZ5JhiCyA8gB-URCcUs3A7lMshbGpGgq9gs=.25b6c72d-f595-4912-85ca-4262f1723499@github.com>
Message-ID: <6uAVPmcvCSfEM966nc9ZOuhX-rfrIWpijWGRnO-Q7MY=.0fdec110-0d38-484f-aba1-0d2fb4f8d3df@github.com>

On Tue, 17 Feb 2026 12:11:49 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> But this will affect other intrinsics, too, they are not implemented using other vector API operations.
>
> We only perform fallback inlining on first intrinsification failure for sliceOp, this is a very localized change.
> https://github.com/jatin-bhateja/jdk/blob/1dfff5589c8b6c83dfc9810bddbb676c7982c904/src/hotspot/share/opto/callGenerator.cpp#L455

Thanks for pointing out the change. I think that's more hacky than I have expected.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2816742757

From duke at openjdk.org  Tue Feb 17 12:48:25 2026
From: duke at openjdk.org (David Beaumont)
Date: Tue, 17 Feb 2026 12:48:25 GMT
Subject: RFR: 8372301: Improve error message for jimage command line tool
 regarding version mismatch [v2]
In-Reply-To: <tnZEXnEKoaJ_ks5AwNXEn0mvUk9EjI24gdndpPWmHKo=.545e2ec6-a8b9-4b56-aff0-dece97a5c0f2@github.com>
References: <tnZEXnEKoaJ_ks5AwNXEn0mvUk9EjI24gdndpPWmHKo=.545e2ec6-a8b9-4b56-aff0-dece97a5c0f2@github.com>
Message-ID: <HaqkFL-8NRxcwPRFUPUah8oAQuR09U1FunNMx0Ld0QI=.715b0ac2-0dfe-4630-8f56-1fe5bfcb4380@github.com>

> New implementation of improved JImageTask error message using string matching to detect the "version mismatch" error without needing code changes in the library.
> 
> Added tests for the error message and other ways in which the jimage file can be corrupt.

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Back to original idea of special case exception

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29723/files
  - new: https://git.openjdk.org/jdk/pull/29723/files/f867683a..e59f33be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29723&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29723&range=00-01

  Stats: 16 lines in 2 files changed: 10 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/29723.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29723/head:pull/29723

PR: https://git.openjdk.org/jdk/pull/29723

From duke at openjdk.org  Tue Feb 17 12:51:05 2026
From: duke at openjdk.org (David Beaumont)
Date: Tue, 17 Feb 2026 12:51:05 GMT
Subject: RFR: 8372301: Improve error message for jimage command line tool
 regarding version mismatch [v2]
In-Reply-To: <HaqkFL-8NRxcwPRFUPUah8oAQuR09U1FunNMx0Ld0QI=.715b0ac2-0dfe-4630-8f56-1fe5bfcb4380@github.com>
References: <tnZEXnEKoaJ_ks5AwNXEn0mvUk9EjI24gdndpPWmHKo=.545e2ec6-a8b9-4b56-aff0-dece97a5c0f2@github.com>
 <HaqkFL-8NRxcwPRFUPUah8oAQuR09U1FunNMx0Ld0QI=.715b0ac2-0dfe-4630-8f56-1fe5bfcb4380@github.com>
Message-ID: <voLRYGYM4un-KBKvd4Z4NX1rQnRbjxpsNnSE3r_Ukv0=.39df4608-34a3-4903-b51f-e28e6dcd7838@github.com>

On Tue, 17 Feb 2026 12:48:25 GMT, David Beaumont <duke at openjdk.org> wrote:

>> New implementation of improved JImageTask error message using string matching to detect the "version mismatch" error without needing code changes in the library.
>> 
>> Added tests for the error message and other ways in which the jimage file can be corrupt.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Back to original idea of special case exception

After offline discussions, the original approach of have a custom exception to capture this case is being used.

src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java line 438:

> 436:                 }
> 437:             } catch (IOException ioe) {
> 438:                 boolean isVersionMismatch = ioe instanceof BasicImageReader.ImageVersionMismatchException;

Or I can have a separate catch block. Either is fine by me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29723#issuecomment-3914529043
PR Review Comment: https://git.openjdk.org/jdk/pull/29723#discussion_r2816868380

From alanb at openjdk.org  Tue Feb 17 13:40:57 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Feb 2026 13:40:57 GMT
Subject: RFR: 8372301: Improve error message for jimage command line tool
 regarding version mismatch [v2]
In-Reply-To: <voLRYGYM4un-KBKvd4Z4NX1rQnRbjxpsNnSE3r_Ukv0=.39df4608-34a3-4903-b51f-e28e6dcd7838@github.com>
References: <tnZEXnEKoaJ_ks5AwNXEn0mvUk9EjI24gdndpPWmHKo=.545e2ec6-a8b9-4b56-aff0-dece97a5c0f2@github.com>
 <HaqkFL-8NRxcwPRFUPUah8oAQuR09U1FunNMx0Ld0QI=.715b0ac2-0dfe-4630-8f56-1fe5bfcb4380@github.com>
 <voLRYGYM4un-KBKvd4Z4NX1rQnRbjxpsNnSE3r_Ukv0=.39df4608-34a3-4903-b51f-e28e6dcd7838@github.com>
Message-ID: <uK3h4l3fuKd839Vwx-su7H2suwdJokN12c7pZnuL2Ew=.7d3da36a-fd71-42b4-82f2-fae1bf4f73dc@github.com>

On Tue, 17 Feb 2026 12:47:04 GMT, David Beaumont <duke at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Back to original idea of special case exception
>
> src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java line 438:
> 
>> 436:                 }
>> 437:             } catch (IOException ioe) {
>> 438:                 boolean isVersionMismatch = ioe instanceof BasicImageReader.ImageVersionMismatchException;
> 
> Or I can have a separate catch block. Either is fine by me.

A catch of ImageVersionMismatchException would be a bit nicer, not important of course.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29723#discussion_r2817087432

From alanb at openjdk.org  Tue Feb 17 13:45:25 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Feb 2026 13:45:25 GMT
Subject: RFR: 8372301: Improve error message for jimage command line tool
 regarding version mismatch [v2]
In-Reply-To: <HaqkFL-8NRxcwPRFUPUah8oAQuR09U1FunNMx0Ld0QI=.715b0ac2-0dfe-4630-8f56-1fe5bfcb4380@github.com>
References: <tnZEXnEKoaJ_ks5AwNXEn0mvUk9EjI24gdndpPWmHKo=.545e2ec6-a8b9-4b56-aff0-dece97a5c0f2@github.com>
 <HaqkFL-8NRxcwPRFUPUah8oAQuR09U1FunNMx0Ld0QI=.715b0ac2-0dfe-4630-8f56-1fe5bfcb4380@github.com>
Message-ID: <3inyKXE7ArJ7aJBT9pv16XKMN5L971OgoXBM-qIo-JA=.c990d376-e86a-4b05-b928-c410714fbc05@github.com>

On Tue, 17 Feb 2026 12:48:25 GMT, David Beaumont <duke at openjdk.org> wrote:

>> New implementation of improved JImageTask error message using string matching to detect the "version mismatch" error without needing code changes in the library.
>> 
>> Added tests for the error message and other ways in which the jimage file can be corrupt.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Back to original idea of special case exception

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29723#pullrequestreview-3814028638

From dfuchs at openjdk.org  Tue Feb 17 13:58:30 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 17 Feb 2026 13:58:30 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v4]
In-Reply-To: <kcqQpRVae7o8qcQS9NhXWnnOeSmwPnPNLO1Qm92AGIQ=.11b32446-6f66-4c47-a16b-d2f8cd6fcad3@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
 <kcqQpRVae7o8qcQS9NhXWnnOeSmwPnPNLO1Qm92AGIQ=.11b32446-6f66-4c47-a16b-d2f8cd6fcad3@github.com>
Message-ID: <sFrtzwKRMsbOIBGmbGd7CqY7dC1lmw9ZqO9lURxJ3Zw=.0f146e46-4234-4658-8bfb-6764e6582c1a@github.com>

On Tue, 17 Feb 2026 12:15:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?
>> 
>> The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.
>> 
>> When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.
>> 
>> When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.
>> 
>> Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `Outp...
>
> 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 10 additional commits since the last revision:
> 
>  - Daniel's review - recheck while holding the lock
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - add comment
>  - copyright years
>  - alternate fix
>  - rename test
>  - 8362268: NPE thrown from SASL GSSAPI impl when  TLS is  used with QOP auth-int against Active Directory
>  - introduce test

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29638#pullrequestreview-3814097545

From rriggs at openjdk.org  Tue Feb 17 14:16:40 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 17 Feb 2026 14:16:40 GMT
Subject: RFR: 8372301: Improve error message for jimage command line tool
 regarding version mismatch [v2]
In-Reply-To: <HaqkFL-8NRxcwPRFUPUah8oAQuR09U1FunNMx0Ld0QI=.715b0ac2-0dfe-4630-8f56-1fe5bfcb4380@github.com>
References: <tnZEXnEKoaJ_ks5AwNXEn0mvUk9EjI24gdndpPWmHKo=.545e2ec6-a8b9-4b56-aff0-dece97a5c0f2@github.com>
 <HaqkFL-8NRxcwPRFUPUah8oAQuR09U1FunNMx0Ld0QI=.715b0ac2-0dfe-4630-8f56-1fe5bfcb4380@github.com>
Message-ID: <2cihpOgL5jqUXr68d8Eg3Cvp6vAQKmDuZ-ovx9EApK0=.6c9b86a1-c542-4d30-bde0-7103c921cbe1@github.com>

On Tue, 17 Feb 2026 12:48:25 GMT, David Beaumont <duke at openjdk.org> wrote:

>> New implementation of improved JImageTask error message using string matching to detect the "version mismatch" error without needing code changes in the library.
>> 
>> Added tests for the error message and other ways in which the jimage file can be corrupt.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Back to original idea of special case exception

Thanks for the clearer messaging.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29723#pullrequestreview-3814193051

From dfuchs at openjdk.org  Tue Feb 17 14:52:01 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 17 Feb 2026 14:52:01 GMT
Subject: RFR: 8377486: com.sun.jndi.ldap.sasl.SaslOutputStream.write()
 throws NullPointerException if it is already closed
In-Reply-To: <VFzdzYDNfmT0HY9lw6GHmfVQ4--FvIw8kpSyNOflHwM=.dbe7fcf4-9368-4d77-943b-b04102dbf17f@github.com>
References: <VFzdzYDNfmT0HY9lw6GHmfVQ4--FvIw8kpSyNOflHwM=.dbe7fcf4-9368-4d77-943b-b04102dbf17f@github.com>
Message-ID: <amReRp2Ufq-CH7gOLjd18DkqkTl5VUHJCs7QxcsuHrc=.3b21d09a-0e37-4c0f-beb9-af5ebc0bf410@github.com>

On Tue, 10 Feb 2026 10:05:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to prevent the `NullPointerException` thrown from `com.sun.jndi.ldap.sasl.SaslOutputStream.write()` methods when the stream is already closed? This addresses https://bugs.openjdk.org/browse/JDK-8377486.
> 
> As noted in that issue, `OutputStream.write(...)` is specified to throw an `IOException` in such cases. The change in this PR updates the `SaslOutputStream.write()` methods to throw an `IOException` when closed.
> 
> A new test has been introduced to verify this change.

Looks reasonable to me. However, is it possible that close() is called asynchronously? If not then the proposed fix looks fine.

-------------

PR Review: https://git.openjdk.org/jdk/pull/29647#pullrequestreview-3814402630

From jpai at openjdk.org  Tue Feb 17 15:35:40 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Feb 2026 15:35:40 GMT
Subject: RFR: 8326487: ZipFileSystem.getPath("").getFileName() returns null
 instead of an empty Path
Message-ID: <qNn100G0Ww9P9JNxjdbCWFg_9Uxi7Z021f1h0Hlsl7c=.d5bfa973-c863-4882-ba85-77a57c1fa1a3@github.com>

Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8326487?

`java.nio.file.Path.getFileName()` is specified to return a non-null value for an empty path. However, the current implementation of zipfs returns null for an empty path. The commit in this PR addresses that issue in zipfs and introduces a test which reproduces the issue and verifies the fix.

-------------

Commit messages:
 - include a test for root path
 - 8326487: ZipFileSystem.getPath().getFileName() returns null instead of an empty string

Changes: https://git.openjdk.org/jdk/pull/29760/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29760&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326487
  Stats: 46 lines in 2 files changed: 40 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/29760.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29760/head:pull/29760

PR: https://git.openjdk.org/jdk/pull/29760

From rgiulietti at openjdk.org  Tue Feb 17 16:25:09 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 17 Feb 2026 16:25:09 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v5]
In-Reply-To: <7ztqU2ZQDSt7EdBbHK4ExgkNKRsbRVTIeHzc3vbpyPo=.0bc5a45c-3535-4aab-a4ae-2035d7e03118@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
 <7ztqU2ZQDSt7EdBbHK4ExgkNKRsbRVTIeHzc3vbpyPo=.0bc5a45c-3535-4aab-a4ae-2035d7e03118@github.com>
Message-ID: <ozWRSKmBEfBcy_T2qDjD61KCdxDN9PPo3IZ2LDlcEQA=.70c2a9fc-7b40-4f1d-89c0-4ea7e420c317@github.com>

On Mon, 16 Feb 2026 19:12:38 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Moves input validation checks to Java for `java.lang.StringLatin1` intrinsics. While doing so, affected `java.lang.StringUTF16` methods needed to be updated due to relaxed checks at intrinsics. The javadocs of the touched methods are extensively overhauled.
>
> 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 16 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into sLatin1Intr
>  - Remove redundant checks in `indexOf0(byte[] value, byte[] str)`
>  - More `indexOf` et al. guards and other review feedback
>  - Use `vmIntrinsics::*` to refer to intrinsics from Java
>  - Improve vertical alignment in `vmIntrinsics.hpp`
>  - Apply review feedback
>  - More doc updates
>  - Reflect that `VerifyIntrinsicChecks` is removed
>  - Merge remote-tracking branch 'upstream/master' into sLatin1Intr
>  - Fix `Helper`
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/d32e3104...6eb75a06

I also checked that all references to `vmIntrinsics::` in the intrinsic methods comments are correct.
LGTM

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28832#pullrequestreview-3814952941

From duke at openjdk.org  Tue Feb 17 16:37:20 2026
From: duke at openjdk.org (David Beaumont)
Date: Tue, 17 Feb 2026 16:37:20 GMT
Subject: RFR: 8372301: Improve error message for jimage command line tool
 regarding version mismatch [v2]
In-Reply-To: <uK3h4l3fuKd839Vwx-su7H2suwdJokN12c7pZnuL2Ew=.7d3da36a-fd71-42b4-82f2-fae1bf4f73dc@github.com>
References: <tnZEXnEKoaJ_ks5AwNXEn0mvUk9EjI24gdndpPWmHKo=.545e2ec6-a8b9-4b56-aff0-dece97a5c0f2@github.com>
 <HaqkFL-8NRxcwPRFUPUah8oAQuR09U1FunNMx0Ld0QI=.715b0ac2-0dfe-4630-8f56-1fe5bfcb4380@github.com>
 <voLRYGYM4un-KBKvd4Z4NX1rQnRbjxpsNnSE3r_Ukv0=.39df4608-34a3-4903-b51f-e28e6dcd7838@github.com>
 <uK3h4l3fuKd839Vwx-su7H2suwdJokN12c7pZnuL2Ew=.7d3da36a-fd71-42b4-82f2-fae1bf4f73dc@github.com>
Message-ID: <d1nQYpSS4bRl9vGk7vkbcAuoqpHw50aQ1qkkffEEQEA=.1dbf79fd-7aad-4183-805a-8b061f0445b1@github.com>

On Tue, 17 Feb 2026 13:38:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java line 438:
>> 
>>> 436:                 }
>>> 437:             } catch (IOException ioe) {
>>> 438:                 boolean isVersionMismatch = ioe instanceof BasicImageReader.ImageVersionMismatchException;
>> 
>> Or I can have a separate catch block. Either is fine by me.
>
> A catch of ImageVersionMismatchException would be a bit nicer, not important of course.

My feeling is that, in this case, it's cleaner to just catch the IOE once, because it keeps the message handling in one place.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29723#discussion_r2817955450

From alanb at openjdk.org  Tue Feb 17 16:40:39 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Feb 2026 16:40:39 GMT
Subject: RFR: 8326487: ZipFileSystem.getPath("").getFileName() returns null
 instead of an empty Path
In-Reply-To: <qNn100G0Ww9P9JNxjdbCWFg_9Uxi7Z021f1h0Hlsl7c=.d5bfa973-c863-4882-ba85-77a57c1fa1a3@github.com>
References: <qNn100G0Ww9P9JNxjdbCWFg_9Uxi7Z021f1h0Hlsl7c=.d5bfa973-c863-4882-ba85-77a57c1fa1a3@github.com>
Message-ID: <4SuQhj1ooBzyoVFSw_FWnK-O0MfIcG_SRBJF0o_5tVk=.854ec609-2789-4a15-8a3d-06c02cebd494@github.com>

On Tue, 17 Feb 2026 15:27:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8326487?
> 
> `java.nio.file.Path.getFileName()` is specified to return a non-null value for an empty path. However, the current implementation of zipfs returns null for an empty path. The commit in this PR addresses that issue in zipfs and introduces a test which reproduces the issue and verifies the fix.

I think this looks okay. At some point we should replace zipfs/Basic.java with a JUnit test as it has growth very large over time.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29760#pullrequestreview-3815035237

From duke at openjdk.org  Tue Feb 17 16:43:08 2026
From: duke at openjdk.org (duke)
Date: Tue, 17 Feb 2026 16:43:08 GMT
Subject: RFR: 8372301: Improve error message for jimage command line tool
 regarding version mismatch [v2]
In-Reply-To: <HaqkFL-8NRxcwPRFUPUah8oAQuR09U1FunNMx0Ld0QI=.715b0ac2-0dfe-4630-8f56-1fe5bfcb4380@github.com>
References: <tnZEXnEKoaJ_ks5AwNXEn0mvUk9EjI24gdndpPWmHKo=.545e2ec6-a8b9-4b56-aff0-dece97a5c0f2@github.com>
 <HaqkFL-8NRxcwPRFUPUah8oAQuR09U1FunNMx0Ld0QI=.715b0ac2-0dfe-4630-8f56-1fe5bfcb4380@github.com>
Message-ID: <IvhiIpUJY7tcpy2RRCVWuKRCiyqXNNHrj2z7PIjypCY=.2753f5c9-4c4e-4ab6-9497-405f346f5b22@github.com>

On Tue, 17 Feb 2026 12:48:25 GMT, David Beaumont <duke at openjdk.org> wrote:

>> New implementation of improved JImageTask error message using string matching to detect the "version mismatch" error without needing code changes in the library.
>> 
>> Added tests for the error message and other ways in which the jimage file can be corrupt.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Back to original idea of special case exception

@david-beaumont 
Your change (at version e59f33be1a952e1af55498da2311548558fe7297) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29723#issuecomment-3915805764

From jpai at openjdk.org  Tue Feb 17 16:47:59 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Feb 2026 16:47:59 GMT
Subject: RFR: 8377486: com.sun.jndi.ldap.sasl.SaslOutputStream.write()
 throws NullPointerException if it is already closed
In-Reply-To: <amReRp2Ufq-CH7gOLjd18DkqkTl5VUHJCs7QxcsuHrc=.3b21d09a-0e37-4c0f-beb9-af5ebc0bf410@github.com>
References: <VFzdzYDNfmT0HY9lw6GHmfVQ4--FvIw8kpSyNOflHwM=.dbe7fcf4-9368-4d77-943b-b04102dbf17f@github.com>
 <amReRp2Ufq-CH7gOLjd18DkqkTl5VUHJCs7QxcsuHrc=.3b21d09a-0e37-4c0f-beb9-af5ebc0bf410@github.com>
Message-ID: <bRGCPAw1JvA3dlEjsdJETOhuDfC8NcTfl86qcuMOmV4=.59a6b07a-379f-4d05-9d4e-5c0c7725b50d@github.com>

On Tue, 17 Feb 2026 14:48:46 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> However, is it possible that close() is called asynchronously?

The `SaslOutputStream` instance gets used by the `com.sun.jndi.ldap.Connection`. That `outStream` instance is `close()`d when that `Connection` is being closed (`cleanup()` calls `flushAndCloseOutputStream()`). Similarly, the `Connection` instance issues `outStream.write(...)` calls in a few places. Both the `outStream.close()` and `outStream.write(...)` calls are issued when holding the (same) `lock`. So there doesn't appear to be any concurrent calls to `close()` and `write(...)` on the `SaslOutputStream` instance.

Other than the `Connection` class, from what I can see in the code, the  `SaslOutputStream` stream instance doesn't get closed or written to.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29647#issuecomment-3915829386

From jpai at openjdk.org  Tue Feb 17 16:52:20 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Feb 2026 16:52:20 GMT
Subject: RFR: 8326487: ZipFileSystem.getPath("").getFileName() returns null
 instead of an empty Path
In-Reply-To: <4SuQhj1ooBzyoVFSw_FWnK-O0MfIcG_SRBJF0o_5tVk=.854ec609-2789-4a15-8a3d-06c02cebd494@github.com>
References: <qNn100G0Ww9P9JNxjdbCWFg_9Uxi7Z021f1h0Hlsl7c=.d5bfa973-c863-4882-ba85-77a57c1fa1a3@github.com>
 <4SuQhj1ooBzyoVFSw_FWnK-O0MfIcG_SRBJF0o_5tVk=.854ec609-2789-4a15-8a3d-06c02cebd494@github.com>
Message-ID: <9vKzXy0tc7wPsvBZ5Al3EINmwWNwTbyjRHp6ZUdg5vY=.35c85613-0542-44ae-8e74-22370cbc920a@github.com>

On Tue, 17 Feb 2026 16:38:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> At some point we should replace zipfs/Basic.java with a JUnit test as it has growth very large over time.

After seeing Basic.java, I was in two minds whether I should introduce a new JUnit test class just for this issue or add it to the existing one :) I decided to add it here and then consider the JUnit migration as a separate task.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29760#issuecomment-3915850273

From lance.andersen at oracle.com  Tue Feb 17 16:55:01 2026
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 17 Feb 2026 16:55:01 +0000
Subject: RFR: 8326487: ZipFileSystem.getPath("").getFileName() returns
 null instead of an empty Path
In-Reply-To: <9vKzXy0tc7wPsvBZ5Al3EINmwWNwTbyjRHp6ZUdg5vY=.35c85613-0542-44ae-8e74-22370cbc920a@github.com>
References: <qNn100G0Ww9P9JNxjdbCWFg_9Uxi7Z021f1h0Hlsl7c=.d5bfa973-c863-4882-ba85-77a57c1fa1a3@github.com>
 <4SuQhj1ooBzyoVFSw_FWnK-O0MfIcG_SRBJF0o_5tVk=.854ec609-2789-4a15-8a3d-06c02cebd494@github.com>
 <9vKzXy0tc7wPsvBZ5Al3EINmwWNwTbyjRHp6ZUdg5vY=.35c85613-0542-44ae-8e74-22370cbc920a@github.com>
Message-ID: <25572954-3645-4645-91B0-9DF53E8CD7B5@oracle.com>

The various tests can probably be incorporated into some of the other existing zipfs tests as they are converted from testng -> junit

On Feb 17, 2026, at 11:52?AM, Jaikiran Pai <jpai at openjdk.org> wrote:

On Tue, 17 Feb 2026 16:38:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

At some point we should replace zipfs/Basic.java with a JUnit test as it has growth very large over time.

After seeing Basic.java, I was in two minds whether I should introduce a new JUnit test class just for this issue or add it to the existing one :) I decided to add it here and then consider the JUnit migration as a separate task.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29760#issuecomment-3915850273

[oracle_sig_logo.gif]

Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260217/ba61e42c/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260217/ba61e42c/oracle_sig_logo-0001.gif>

From bpb at openjdk.org  Tue Feb 17 18:10:07 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Feb 2026 18:10:07 GMT
Subject: Integrated: 8377910: Minor cleanup of
 java/io/FileDescriptor/Sharing.java
In-Reply-To: <HEZYKppPd3AWlhRtiKT-IX1yoNSTjLAc0-Fv-bieVMw=.0a3efa23-8583-48ab-b42c-7a656c7ef6b8@github.com>
References: <HEZYKppPd3AWlhRtiKT-IX1yoNSTjLAc0-Fv-bieVMw=.0a3efa23-8583-48ab-b42c-7a656c7ef6b8@github.com>
Message-ID: <-OqooejGMs_MrB6RGzxz1Ia-Sl6idJRQNuU0ZPLtHng=.a86f8501-bcdc-4709-a172-34ac46f6e232@github.com>

On Fri, 13 Feb 2026 17:14:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Null checks potentially mask a more serious, fundamental problem and should be removed to allow a `NullPointerException` to be throw if the variable is `null`.

This pull request has now been integrated.

Changeset: 7489f75d
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7489f75dbdb1358b7f905aad2d1510b7ffc173bf
Stats:     44 lines in 1 file changed: 10 ins; 2 del; 32 mod

8377910: Minor cleanup of java/io/FileDescriptor/Sharing.java

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/29718

From dfuchs at openjdk.org  Tue Feb 17 18:39:13 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 17 Feb 2026 18:39:13 GMT
Subject: RFR: 8377486: com.sun.jndi.ldap.sasl.SaslOutputStream.write()
 throws NullPointerException if it is already closed
In-Reply-To: <VFzdzYDNfmT0HY9lw6GHmfVQ4--FvIw8kpSyNOflHwM=.dbe7fcf4-9368-4d77-943b-b04102dbf17f@github.com>
References: <VFzdzYDNfmT0HY9lw6GHmfVQ4--FvIw8kpSyNOflHwM=.dbe7fcf4-9368-4d77-943b-b04102dbf17f@github.com>
Message-ID: <Jx806KULNvV0Smbeq_y2WLFdn5W90F7z0z5ZT3BdHrQ=.62372ced-c238-4ba2-a22a-5edb31b215a9@github.com>

On Tue, 10 Feb 2026 10:05:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to prevent the `NullPointerException` thrown from `com.sun.jndi.ldap.sasl.SaslOutputStream.write()` methods when the stream is already closed? This addresses https://bugs.openjdk.org/browse/JDK-8377486.
> 
> As noted in that issue, `OutputStream.write(...)` is specified to throw an `IOException` in such cases. The change in this PR updates the `SaslOutputStream.write()` methods to throw an `IOException` when closed.
> 
> A new test has been introduced to verify this change.

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29647#pullrequestreview-3815656501

From duke at openjdk.org  Tue Feb 17 19:17:48 2026
From: duke at openjdk.org (David Beaumont)
Date: Tue, 17 Feb 2026 19:17:48 GMT
Subject: Integrated: 8372301: Improve error message for jimage command line
 tool regarding version mismatch
In-Reply-To: <tnZEXnEKoaJ_ks5AwNXEn0mvUk9EjI24gdndpPWmHKo=.545e2ec6-a8b9-4b56-aff0-dece97a5c0f2@github.com>
References: <tnZEXnEKoaJ_ks5AwNXEn0mvUk9EjI24gdndpPWmHKo=.545e2ec6-a8b9-4b56-aff0-dece97a5c0f2@github.com>
Message-ID: <292n0E9yCVjt1wHtWvh5Fad3tsYDQFNpkTROwqfH30M=.b1202da3-cf0d-447e-ae9b-a21ff9cb4a1a@github.com>

On Fri, 13 Feb 2026 20:59:09 GMT, David Beaumont <duke at openjdk.org> wrote:

> New implementation of improved JImageTask error message using string matching to detect the "version mismatch" error without needing code changes in the library.
> 
> Added tests for the error message and other ways in which the jimage file can be corrupt.

This pull request has now been integrated.

Changeset: 92d0ea9b
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92d0ea9ba84f549deeb42cae49a9b20711dcf8cf
Stats:     201 lines in 4 files changed: 193 ins; 4 del; 4 mod

8372301: Improve error message for jimage command line tool regarding version mismatch

Reviewed-by: alanb, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/29723

From rriggs at openjdk.org  Tue Feb 17 19:38:29 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 17 Feb 2026 19:38:29 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v5]
In-Reply-To: <7ztqU2ZQDSt7EdBbHK4ExgkNKRsbRVTIeHzc3vbpyPo=.0bc5a45c-3535-4aab-a4ae-2035d7e03118@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
 <7ztqU2ZQDSt7EdBbHK4ExgkNKRsbRVTIeHzc3vbpyPo=.0bc5a45c-3535-4aab-a4ae-2035d7e03118@github.com>
Message-ID: <Rt-bsJ0qtTrQm-BnmKly3Fn-dJS74Gjbyf14_-7n7hs=.b47dd041-2b26-4e10-9b63-ac5a919843d6@github.com>

On Mon, 16 Feb 2026 19:12:38 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Moves input validation checks to Java for `java.lang.StringLatin1` intrinsics. While doing so, affected `java.lang.StringUTF16` methods needed to be updated due to relaxed checks at intrinsics. The javadocs of the touched methods are extensively overhauled.
>
> 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 16 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into sLatin1Intr
>  - Remove redundant checks in `indexOf0(byte[] value, byte[] str)`
>  - More `indexOf` et al. guards and other review feedback
>  - Use `vmIntrinsics::*` to refer to intrinsics from Java
>  - Improve vertical alignment in `vmIntrinsics.hpp`
>  - Apply review feedback
>  - More doc updates
>  - Reflect that `VerifyIntrinsicChecks` is removed
>  - Merge remote-tracking branch 'upstream/master' into sLatin1Intr
>  - Fix `Helper`
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/7f1f87f7...6eb75a06

looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28832#pullrequestreview-3815901802

From mullan at openjdk.org  Tue Feb 17 20:17:37 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 17 Feb 2026 20:17:37 GMT
Subject: RFR: 8364182: Add jcmd VM.security_properties command [v8]
In-Reply-To: <JujEAnglZiuLMQn0edlR1DPfgKfyIEaQTzxsl8A48N8=.b4c9a6ec-c4c7-4028-bd2e-5fcaaebdb6e5@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <JujEAnglZiuLMQn0edlR1DPfgKfyIEaQTzxsl8A48N8=.b4c9a6ec-c4c7-4028-bd2e-5fcaaebdb6e5@github.com>
Message-ID: <cRpR4xtPgFq-xIoRT5mwx0Sa2vA7EVDOEGBV_omaczc=.68114658-628a-4234-a8b3-18e291059643@github.com>

On Mon, 19 Jan 2026 11:25:41 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test

src/java.base/share/classes/java/security/Security.java line 335:

> 333:             @Override
> 334:             public Properties getCurrentProperties() {
> 335:                 return (Properties) props.clone();

It seems you can avoid this clone (and thereby not locking the `Properties` object) since the caller creates a new `Properties` object to store them in. Same pattern as the system properties.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2818879624

From dl at openjdk.org  Wed Feb 18 00:38:18 2026
From: dl at openjdk.org (Doug Lea)
Date: Wed, 18 Feb 2026 00:38:18 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v39]
In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
Message-ID: <DdodhCzjQk7CLm0VPDxJxb-QqvfCzsUYKi3-4U4JLA4=.44384820-578b-4ca8-b6e6-64089755c78f@github.com>

> Changes signal filtering to avoid possible starvation

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  No interleaved reactivate

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28797/files
  - new: https://git.openjdk.org/jdk/pull/28797/files/5f84c2a9..872fd0b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=37-38

  Stats: 93 lines in 1 file changed: 8 ins; 32 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/28797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28797/head:pull/28797

PR: https://git.openjdk.org/jdk/pull/28797

From almatvee at openjdk.org  Wed Feb 18 02:02:57 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 18 Feb 2026 02:02:57 GMT
Subject: RFR: 8374222: jpackage will exit with error if it fails to clean
 the temp directory
In-Reply-To: <slkcuguuN_dOz_pjLZs_xVDEy0aGeTjk6BiBs5fawzU=.245d6070-5d05-4d4a-a923-414b4cbe515d@github.com>
References: <slkcuguuN_dOz_pjLZs_xVDEy0aGeTjk6BiBs5fawzU=.245d6070-5d05-4d4a-a923-414b4cbe515d@github.com>
Message-ID: <xA519FvvpqQYmj68SxQ7NJ6zx0S7_FzmXzye2cfY2m0=.0b361498-3aab-4d1b-80e7-1c0b1f845d32@github.com>

On Wed, 11 Feb 2026 04:13:53 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> jpackage will attempt to delete the temp directory a few times. If all attempts fail, it will print remaining files and empty directories (100 entries at most) to the console and continue. It will not exit with an error status as previously, as this is not a critical error.

Changes requested by almatvee (Reviewer).

src/jdk.jpackage/share/classes/jdk/jpackage/internal/TempDirectory.java line 93:

> 91:                             } else {
> 92:                                 // Collect the list of leftover files. Collect at most the first 100 files.
> 93:                                 var remainingFiles = DirectoryListing.listFilesAndEmptyDirectories(path, 100).paths();

I would define 100 as a constant.

test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/TempDirectoryTest.java line 123:

> 121: 
> 122:     @ParameterizedTest
> 123:     @CsvSource({"100", "0"})

Do we need to test other limits like 101 or 1?

test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/TempDirectoryTest.java line 292:

> 290: 
> 291:         boolean isSuccess() {
> 292:             return this ==  SUCCEED;

Extra space.

-------------

PR Review: https://git.openjdk.org/jdk/pull/29664#pullrequestreview-3817264492
PR Review Comment: https://git.openjdk.org/jdk/pull/29664#discussion_r2819945345
PR Review Comment: https://git.openjdk.org/jdk/pull/29664#discussion_r2819951802
PR Review Comment: https://git.openjdk.org/jdk/pull/29664#discussion_r2819955414

From jpai at openjdk.org  Wed Feb 18 02:17:11 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Feb 2026 02:17:11 GMT
Subject: RFR: 8326487: ZipFileSystem.getPath("").getFileName() returns null
 instead of an empty Path [v2]
In-Reply-To: <qNn100G0Ww9P9JNxjdbCWFg_9Uxi7Z021f1h0Hlsl7c=.d5bfa973-c863-4882-ba85-77a57c1fa1a3@github.com>
References: <qNn100G0Ww9P9JNxjdbCWFg_9Uxi7Z021f1h0Hlsl7c=.d5bfa973-c863-4882-ba85-77a57c1fa1a3@github.com>
Message-ID: <_qYbrpWI2Y3i3XK50PKYTSNgAOq8YCW9mCmmXnw2crA=.212699fe-1b81-4be0-b8b1-e9034b70963c@github.com>

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8326487?
> 
> `java.nio.file.Path.getFileName()` is specified to return a non-null value for an empty path. However, the current implementation of zipfs returns null for an empty path. The commit in this PR addresses that issue in zipfs and introduces a test which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  move the test to PathOps

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29760/files
  - new: https://git.openjdk.org/jdk/pull/29760/files/4a531890..33b848a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29760&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29760&range=00-01

  Stats: 58 lines in 2 files changed: 19 ins; 31 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/29760.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29760/head:pull/29760

PR: https://git.openjdk.org/jdk/pull/29760

From jpai at openjdk.org  Wed Feb 18 02:17:11 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Feb 2026 02:17:11 GMT
Subject: RFR: 8326487: ZipFileSystem.getPath("").getFileName() returns null
 instead of an empty Path
In-Reply-To: <qNn100G0Ww9P9JNxjdbCWFg_9Uxi7Z021f1h0Hlsl7c=.d5bfa973-c863-4882-ba85-77a57c1fa1a3@github.com>
References: <qNn100G0Ww9P9JNxjdbCWFg_9Uxi7Z021f1h0Hlsl7c=.d5bfa973-c863-4882-ba85-77a57c1fa1a3@github.com>
Message-ID: <Ns6sLREeh-HUIZiX00IyJ6r5xE8gOkwJxFYsm9Wj8HU=.27846df8-0033-41f5-88c3-76a0ac160da9@github.com>

On Tue, 17 Feb 2026 15:27:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8326487?
> 
> `java.nio.file.Path.getFileName()` is specified to return a non-null value for an empty path. However, the current implementation of zipfs returns null for an empty path. The commit in this PR addresses that issue in zipfs and introduces a test which reproduces the issue and verifies the fix.

Lance suggested that the existing `test/jdk/jdk/nio/zipfs/PathOps.java` might be a better place for this test. So I've moved the test into that file and updated the PR. I've verified that the test fails without the fix and passes with it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29760#issuecomment-3918102623

From ascarpino at openjdk.org  Wed Feb 18 02:32:32 2026
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 18 Feb 2026 02:32:32 GMT
Subject: RFR: 8377506: Implementation of PEM Encodings of Cryptographic Objects
 (Final)
Message-ID: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>

Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524), include:

- `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied.
- `DEREncodable` is renamed to `BinaryEncodable` to more accurately reflect the binary data stored in PEM text.
- In `EncryptedPrivateKeyInfo`, the `encrypt` methods now accept `BinaryEncodable`, and the `getKey()` and `getKeyPair()` methods no longer include a `Provider` parameter.
- A new `CryptoException` indicates failures during cryptographic processing at runtime.

thanks

-------------

Commit messages:
 - Merge branch 'master' into pem27
 - doc and test updates
 - Initial

Changes: https://git.openjdk.org/jdk/pull/29640/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29640&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377506
  Stats: 752 lines in 33 files changed: 272 ins; 182 del; 298 mod
  Patch: https://git.openjdk.org/jdk/pull/29640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29640/head:pull/29640

PR: https://git.openjdk.org/jdk/pull/29640

From almatvee at openjdk.org  Wed Feb 18 03:07:43 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 18 Feb 2026 03:07:43 GMT
Subject: RFR: 8377897: jpackage: make jdk.jpackage.internal.MockUtils
 available from other packages
In-Reply-To: <OkOhOuHJ59h2vCWGp4zbAGicavnLAQqxBw9JFec2dPM=.4509f1cf-b127-4da5-ab7f-5ff80d41d72e@github.com>
References: <OkOhOuHJ59h2vCWGp4zbAGicavnLAQqxBw9JFec2dPM=.4509f1cf-b127-4da5-ab7f-5ff80d41d72e@github.com>
Message-ID: <_hauP4CarXPWa82308ht6M_NS4aawGVDlT8SO2xD3_E=.c070d789-dba6-45e5-8a4a-a952ea2af0f9@github.com>

On Mon, 2 Feb 2026 22:18:49 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Move jdk.jpackage.internal.MockUtils to jdk.jpackage.test.stdmock.JPackageMockUtils
>  - Make ObjectFactory, ExecutorFactory, RetryExecutorFactory, and Executor accessible for creating jpackage mocks in tests outside the jdk.jpackage.internal package

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29536#pullrequestreview-3817454474

From jbhateja at openjdk.org  Wed Feb 18 04:39:54 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 18 Feb 2026 04:39:54 GMT
Subject: RFR: 8376186: [VectorAPI] Nomenclature change for concrete vector
 classes [v5]
In-Reply-To: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
References: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
Message-ID: <FSGjN2Mx-_Wlco-UYMlD-38L1l4lhEXW4xatAspO97w=.be1b4d07-06d1-402f-b7e5-c6bb65a7eab6@github.com>

> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
> 
> In preparation of Float16 vector API support, changes to nomenclature of concrete vector class by suffixing the vector type with vector bit sizes e.g. FloatVector256 so that we don't end up generating names like Float16256Vector.
> 
> All existing Vector API jtreg test are passing with the patch.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8376186
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8376186
 - Reivew comments resolution
 - Review comments resolution
 - Review comment resolution
 - Removing older artifact
 - 8376186: [VectorAPI] Nomenclature change for concrete vector classes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29614/files
  - new: https://git.openjdk.org/jdk/pull/29614/files/b56d47a7..05b6cbe3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29614&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29614&range=03-04

  Stats: 4221 lines in 98 files changed: 3291 ins; 415 del; 515 mod
  Patch: https://git.openjdk.org/jdk/pull/29614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29614/head:pull/29614

PR: https://git.openjdk.org/jdk/pull/29614

From jbhateja at openjdk.org  Wed Feb 18 04:39:55 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 18 Feb 2026 04:39:55 GMT
Subject: RFR: 8376186: [VectorAPI] Nomenclature change for concrete vector
 classes [v3]
In-Reply-To: <ZId-zFGCsRugJ3DFRJCY0wZXG8JXGG3IzkQSLYUyUb8=.83ceb5e9-0ba1-47fd-803a-2eb055fe1b91@github.com>
References: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
 <rFnnnmZYvqWwSF9swRBWGoK2BXHIuYl_qkplWfy1V94=.25b06d9d-ef15-4d8c-99a3-5c5cb69c280c@github.com>
 <ZId-zFGCsRugJ3DFRJCY0wZXG8JXGG3IzkQSLYUyUb8=.83ceb5e9-0ba1-47fd-803a-2eb055fe1b91@github.com>
Message-ID: <ibBZ751fhQaZjBp-gKsrZ_lQBfTQoBe-3UkrU5oa3gw=.5ae2ef6e-1785-413e-9a3e-30361aeba56d@github.com>

On Fri, 13 Feb 2026 17:46:14 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Looks good, just one last comment to address. No need for another review.

Hi @PaulSandoz , All comments addressed, please approve the PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29614#issuecomment-3918548235

From jpai at openjdk.org  Wed Feb 18 05:11:24 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Feb 2026 05:11:24 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v4]
In-Reply-To: <kcqQpRVae7o8qcQS9NhXWnnOeSmwPnPNLO1Qm92AGIQ=.11b32446-6f66-4c47-a16b-d2f8cd6fcad3@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
 <kcqQpRVae7o8qcQS9NhXWnnOeSmwPnPNLO1Qm92AGIQ=.11b32446-6f66-4c47-a16b-d2f8cd6fcad3@github.com>
Message-ID: <qIlNR3Z-vmm9W19OBWOPlvEzNaX3zSt-tpxUBfH7ae0=.2d7e5443-301c-4eb3-9124-1cf2ce75bdf4@github.com>

On Tue, 17 Feb 2026 12:15:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?
>> 
>> The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.
>> 
>> When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.
>> 
>> When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.
>> 
>> Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `Outp...
>
> 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 10 additional commits since the last revision:
> 
>  - Daniel's review - recheck while holding the lock
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - add comment
>  - copyright years
>  - alternate fix
>  - rename test
>  - 8362268: NPE thrown from SASL GSSAPI impl when  TLS is  used with QOP auth-int against Active Directory
>  - introduce test

Thank you everyone for the reviews. tier1, tier2, tier3 testing with this change came back fine. I'll wait for Aleksei to have a chance at looking at the latest changes in this PR before integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29638#issuecomment-3918701093

From jpai at openjdk.org  Wed Feb 18 05:15:20 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Feb 2026 05:15:20 GMT
Subject: RFR: 8377486: com.sun.jndi.ldap.sasl.SaslOutputStream.write()
 throws NullPointerException if it is already closed
In-Reply-To: <VFzdzYDNfmT0HY9lw6GHmfVQ4--FvIw8kpSyNOflHwM=.dbe7fcf4-9368-4d77-943b-b04102dbf17f@github.com>
References: <VFzdzYDNfmT0HY9lw6GHmfVQ4--FvIw8kpSyNOflHwM=.dbe7fcf4-9368-4d77-943b-b04102dbf17f@github.com>
Message-ID: <6fUdlAnyKtxo2QI0vj72kSTuzX0XNOkHCuZDZYXEZaw=.282adb06-b57b-46b8-844a-20336954488e@github.com>

On Tue, 10 Feb 2026 10:05:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to prevent the `NullPointerException` thrown from `com.sun.jndi.ldap.sasl.SaslOutputStream.write()` methods when the stream is already closed? This addresses https://bugs.openjdk.org/browse/JDK-8377486.
> 
> As noted in that issue, `OutputStream.write(...)` is specified to throw an `IOException` in such cases. The change in this PR updates the `SaslOutputStream.write()` methods to throw an `IOException` when closed.
> 
> A new test has been introduced to verify this change.

Thank you Daniel for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29647#issuecomment-3918707931

From jpai at openjdk.org  Wed Feb 18 05:15:21 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Feb 2026 05:15:21 GMT
Subject: Integrated: 8377486: com.sun.jndi.ldap.sasl.SaslOutputStream.write()
 throws NullPointerException if it is already closed
In-Reply-To: <VFzdzYDNfmT0HY9lw6GHmfVQ4--FvIw8kpSyNOflHwM=.dbe7fcf4-9368-4d77-943b-b04102dbf17f@github.com>
References: <VFzdzYDNfmT0HY9lw6GHmfVQ4--FvIw8kpSyNOflHwM=.dbe7fcf4-9368-4d77-943b-b04102dbf17f@github.com>
Message-ID: <-TSOJsKYafZb399m6fvw-9djU6uarA4xOfzAAUUCcMg=.a9fdf04c-1030-4da0-b939-0f44a9b5d49c@github.com>

On Tue, 10 Feb 2026 10:05:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to prevent the `NullPointerException` thrown from `com.sun.jndi.ldap.sasl.SaslOutputStream.write()` methods when the stream is already closed? This addresses https://bugs.openjdk.org/browse/JDK-8377486.
> 
> As noted in that issue, `OutputStream.write(...)` is specified to throw an `IOException` in such cases. The change in this PR updates the `SaslOutputStream.write()` methods to throw an `IOException` when closed.
> 
> A new test has been introduced to verify this change.

This pull request has now been integrated.

Changeset: 1d713b2b
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1d713b2bbe4daddc8a9b1648296b59412e683186
Stats:     151 lines in 2 files changed: 145 ins; 1 del; 5 mod

8377486: com.sun.jndi.ldap.sasl.SaslOutputStream.write() throws NullPointerException if it is already closed

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/29647

From alanb at openjdk.org  Wed Feb 18 07:20:21 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Feb 2026 07:20:21 GMT
Subject: RFR: 8377506: Implementation of PEM Encodings of Cryptographic
 Objects (Final)
In-Reply-To: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>
References: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>
Message-ID: <ZGmdj--8JlmcndZjsINm9OaIWxyghNV-tAM230BDNsE=.377954d6-0f88-4818-9f5f-6bc4b39760d5@github.com>

On Mon, 9 Feb 2026 21:04:34 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524), include:
> 
> - `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied.
> - `DEREncodable` is renamed to `BinaryEncodable` to more accurately reflect the binary data stored in PEM text.
> - In `EncryptedPrivateKeyInfo`, the `encrypt` methods now accept `BinaryEncodable`, and the `getKey()` and `getKeyPair()` methods no longer include a `Provider` parameter.
> - A new `CryptoException` indicates failures during cryptographic processing at runtime.
> 
> thanks

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 92:

> 90:         @JEP(number=524, title="PEM Encodings of Cryptographic Objects",
> 91:             status="Second Preview")
> 92:         PEM_API,

@lahodaj This comes up each time that a feature proposes to become permanent after being in preview. Do we still leave the value in place for one release and then cleanup in release N+1 ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2820737035

From alanb at openjdk.org  Wed Feb 18 07:38:10 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Feb 2026 07:38:10 GMT
Subject: RFR: 8326487: ZipFileSystem.getPath("").getFileName() returns null
 instead of an empty Path [v2]
In-Reply-To: <_qYbrpWI2Y3i3XK50PKYTSNgAOq8YCW9mCmmXnw2crA=.212699fe-1b81-4be0-b8b1-e9034b70963c@github.com>
References: <qNn100G0Ww9P9JNxjdbCWFg_9Uxi7Z021f1h0Hlsl7c=.d5bfa973-c863-4882-ba85-77a57c1fa1a3@github.com>
 <_qYbrpWI2Y3i3XK50PKYTSNgAOq8YCW9mCmmXnw2crA=.212699fe-1b81-4be0-b8b1-e9034b70963c@github.com>
Message-ID: <S0R-svJudq2rgyv1iECBl-Dpef8xAs6oZFjQxZz8BYg=.54bfc13d-c499-4d28-b853-b7483bf746eb@github.com>

On Wed, 18 Feb 2026 02:17:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8326487?
>> 
>> `java.nio.file.Path.getFileName()` is specified to return a non-null value for an empty path. However, the current implementation of zipfs returns null for an empty path. The commit in this PR addresses that issue in zipfs and introduces a test which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move the test to PathOps

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29760#pullrequestreview-3818228482

From jpai at openjdk.org  Wed Feb 18 07:40:31 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Feb 2026 07:40:31 GMT
Subject: RFR: 8377506: Implementation of PEM Encodings of Cryptographic
 Objects (Final)
In-Reply-To: <ZGmdj--8JlmcndZjsINm9OaIWxyghNV-tAM230BDNsE=.377954d6-0f88-4818-9f5f-6bc4b39760d5@github.com>
References: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>
 <ZGmdj--8JlmcndZjsINm9OaIWxyghNV-tAM230BDNsE=.377954d6-0f88-4818-9f5f-6bc4b39760d5@github.com>
Message-ID: <5jTxKzM1K4OyNJkw7qMrNI_7AUAvBm-3ZJudHiquocE=.ceb99d86-fc0b-478a-bd3c-330e2195633c@github.com>

On Wed, 18 Feb 2026 07:17:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524), include:
>> 
>> - `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied.
>> - `DEREncodable` is renamed to `BinaryEncodable` to more accurately reflect the binary data stored in PEM text.
>> - In `EncryptedPrivateKeyInfo`, the `encrypt` methods now accept `BinaryEncodable`, and the `getKey()` and `getKeyPair()` methods no longer include a `Provider` parameter.
>> - A new `CryptoException` indicates failures during cryptographic processing at runtime.
>> 
>> thanks
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 92:
> 
>> 90:         @JEP(number=524, title="PEM Encodings of Cryptographic Objects",
>> 91:             status="Second Preview")
>> 92:         PEM_API,
> 
> @lahodaj This comes up each time that a feature proposes to become permanent after being in preview. Do we still leave the value in place for one release and then cleanup in release N+1 ?

This came up the last time too and Jan explained how to deal with the removal of these constants. I've now added a comment and pinned it to that previous JBS issue at https://bugs.openjdk.org/browse/JDK-8365699?focusedId=14856891&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14856891

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2820795515

From jpai at openjdk.org  Wed Feb 18 07:47:46 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Feb 2026 07:47:46 GMT
Subject: RFR: 8377506: Implementation of PEM Encodings of Cryptographic
 Objects (Final)
In-Reply-To: <5jTxKzM1K4OyNJkw7qMrNI_7AUAvBm-3ZJudHiquocE=.ceb99d86-fc0b-478a-bd3c-330e2195633c@github.com>
References: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>
 <ZGmdj--8JlmcndZjsINm9OaIWxyghNV-tAM230BDNsE=.377954d6-0f88-4818-9f5f-6bc4b39760d5@github.com>
 <5jTxKzM1K4OyNJkw7qMrNI_7AUAvBm-3ZJudHiquocE=.ceb99d86-fc0b-478a-bd3c-330e2195633c@github.com>
Message-ID: <tdtrbE6DJ7vaxI5N9-J-mtotzUJnZppw_YTWub05ljs=.e2585430-6ce2-4f1e-9a90-f23d41a6b193@github.com>

On Wed, 18 Feb 2026 07:37:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 92:
>> 
>>> 90:         @JEP(number=524, title="PEM Encodings of Cryptographic Objects",
>>> 91:             status="Second Preview")
>>> 92:         PEM_API,
>> 
>> @lahodaj This comes up each time that a feature proposes to become permanent after being in preview. Do we still leave the value in place for one release and then cleanup in release N+1 ?
>
> This came up the last time too and Jan explained how to deal with the removal of these constants. I've now added a comment and pinned it to that previous JBS issue at https://bugs.openjdk.org/browse/JDK-8365699?focusedId=14856891&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14856891

In fact, I just realized that the same detail is available in the source code as comment a few lines above https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java#L67

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2820812830

From alanb at openjdk.org  Wed Feb 18 07:47:47 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Feb 2026 07:47:47 GMT
Subject: RFR: 8377506: Implementation of PEM Encodings of Cryptographic
 Objects (Final)
In-Reply-To: <tdtrbE6DJ7vaxI5N9-J-mtotzUJnZppw_YTWub05ljs=.e2585430-6ce2-4f1e-9a90-f23d41a6b193@github.com>
References: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>
 <ZGmdj--8JlmcndZjsINm9OaIWxyghNV-tAM230BDNsE=.377954d6-0f88-4818-9f5f-6bc4b39760d5@github.com>
 <5jTxKzM1K4OyNJkw7qMrNI_7AUAvBm-3ZJudHiquocE=.ceb99d86-fc0b-478a-bd3c-330e2195633c@github.com>
 <tdtrbE6DJ7vaxI5N9-J-mtotzUJnZppw_YTWub05ljs=.e2585430-6ce2-4f1e-9a90-f23d41a6b193@github.com>
Message-ID: <4VC1Pjawq829NUd1THBy3Jp4medr1FiHVtcBTVql1eE=.bf0d08ad-dbce-49bf-9fab-c32d3446931f@github.com>

On Wed, 18 Feb 2026 07:42:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This came up the last time too and Jan explained how to deal with the removal of these constants. I've now added a comment and pinned it to that previous JBS issue at https://bugs.openjdk.org/browse/JDK-8365699?focusedId=14856891&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14856891
>
> In fact, I just realized that the same detail is available in the source code as comment a few lines above https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java#L67

Thanks. I would be very surprised if interim javac would pull in PEM but as it's not always easy to determine this so best to leave until the release N+1 cleanup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2820819783

From jlahoda at openjdk.org  Wed Feb 18 08:28:34 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 18 Feb 2026 08:28:34 GMT
Subject: RFR: 8377506: Implementation of PEM Encodings of Cryptographic
 Objects (Final)
In-Reply-To: <4VC1Pjawq829NUd1THBy3Jp4medr1FiHVtcBTVql1eE=.bf0d08ad-dbce-49bf-9fab-c32d3446931f@github.com>
References: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>
 <ZGmdj--8JlmcndZjsINm9OaIWxyghNV-tAM230BDNsE=.377954d6-0f88-4818-9f5f-6bc4b39760d5@github.com>
 <5jTxKzM1K4OyNJkw7qMrNI_7AUAvBm-3ZJudHiquocE=.ceb99d86-fc0b-478a-bd3c-330e2195633c@github.com>
 <tdtrbE6DJ7vaxI5N9-J-mtotzUJnZppw_YTWub05ljs=.e2585430-6ce2-4f1e-9a90-f23d41a6b193@github.com>
 <4VC1Pjawq829NUd1THBy3Jp4medr1FiHVtcBTVql1eE=.bf0d08ad-dbce-49bf-9fab-c32d3446931f@github.com>
Message-ID: <2MAYdX3ocxcZ_XHYh5v_-Y6fuSPP1-IknZcYvhc2jhY=.32e4f090-3de8-4c51-bae6-cdc38f930c9a@github.com>

On Wed, 18 Feb 2026 07:44:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> In fact, I just realized that the same detail is available in the source code as comment a few lines above https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java#L67
>
> Thanks. I would be very surprised if interim javac would pull in PEM but as it's not always easy to determine this so best to leave until the release N+1 cleanup.

I am sorry for this situation, but I can't say when or if we will be able to do something about this.

Currently, keeping the constant for one more release is always safe; removing it may be OK, but it is difficult to determine whether the missing constant will cause problems of not. It is only if the interim javac would touch a classfile that uses the constant, but it is not easy to say whether that will be the case. (And, IIRC, we've had a situation in the past that we had to re-introduce a constant, because it was needed in some specific circumstances.)

I'll think again of ways to avoid the need to keep the constants.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2820968470

From alanb at openjdk.org  Wed Feb 18 09:04:44 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Feb 2026 09:04:44 GMT
Subject: RFR: 8377506: Implementation of PEM Encodings of Cryptographic
 Objects (Final)
In-Reply-To: <2MAYdX3ocxcZ_XHYh5v_-Y6fuSPP1-IknZcYvhc2jhY=.32e4f090-3de8-4c51-bae6-cdc38f930c9a@github.com>
References: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>
 <ZGmdj--8JlmcndZjsINm9OaIWxyghNV-tAM230BDNsE=.377954d6-0f88-4818-9f5f-6bc4b39760d5@github.com>
 <5jTxKzM1K4OyNJkw7qMrNI_7AUAvBm-3ZJudHiquocE=.ceb99d86-fc0b-478a-bd3c-330e2195633c@github.com>
 <tdtrbE6DJ7vaxI5N9-J-mtotzUJnZppw_YTWub05ljs=.e2585430-6ce2-4f1e-9a90-f23d41a6b193@github.com>
 <4VC1Pjawq829NUd1THBy3Jp4medr1FiHVtcBTVql1eE=.bf0d08ad-dbce-49bf-9fab-c32d3446931f@github.com>
 <2MAYdX3ocxcZ_XHYh5v_-Y6fuSPP1-IknZcYvhc2jhY=.32e4f090-3de8-4c51-bae6-cdc38f930c9a@github.com>
Message-ID: <8f7gltAPyJA_dJnC6aQiuUH5owVmgTdZmq3Zk7XLij8=.840c2e8c-a781-47e5-9fa1-5649d22d7ae0@github.com>

On Wed, 18 Feb 2026 08:24:51 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> I am sorry for this situation, but I can't say when or if we will be able to do something about this.

No need to be sorry, you've always been very helpful and patient on this matter.

@ascarpino I assume you'll update the PR to leave the constant in place. You can probably drop the core-libs and compiler labels from the PR if you want to keep the review on security-dev.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2821148471

From kfarrell at openjdk.org  Wed Feb 18 09:30:29 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Wed, 18 Feb 2026 09:30:29 GMT
Subject: RFR: 8364182: Add jcmd VM.security_properties command [v9]
In-Reply-To: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <0L27_6Y7inkhN_LTkG2t2HuuvUGyiM9FGVe-J-RmTMY=.c0aebe13-ca63-457e-b7bf-e3efddb1ccc9@github.com>

> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
> 
> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:

  remove clone

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29124/files
  - new: https://git.openjdk.org/jdk/pull/29124/files/2b1de0f0..40c02958

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=07-08

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124

PR: https://git.openjdk.org/jdk/pull/29124

From duke at openjdk.org  Wed Feb 18 10:49:37 2026
From: duke at openjdk.org (David Beaumont)
Date: Wed, 18 Feb 2026 10:49:37 GMT
Subject: RFR: 8378118: Test tools/jimage/JImageBadFileTest.java failed on
 Windows
Message-ID: <osTab7bHlL02EfiBJGHxrsjqzGcRVxrS8jbWWVz_eFg=.ed9d1730-0cd6-425c-9ccf-ebd7e1e96a79@github.com>

Removed the manual file tidyup on the expectation that jtreg will sort that all out.
Switched to using Utils.createTempFile() while I was there.

-------------

Commit messages:
 - Remove file cleanup and switch to Utils.createTempFile()

Changes: https://git.openjdk.org/jdk/pull/29783/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29783&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378118
  Stats: 46 lines in 1 file changed: 2 ins; 23 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/29783.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29783/head:pull/29783

PR: https://git.openjdk.org/jdk/pull/29783

From jpai at openjdk.org  Wed Feb 18 11:23:09 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Feb 2026 11:23:09 GMT
Subject: RFR: 8377388: Replacing "new StringReader(String)" by
 "Reader.of(CharSequence);" in Scanner
In-Reply-To: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
References: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
Message-ID: <wPyyM_wfRy0ga1X5p6QkfZvUejLwBRB3OR4aIDvKUYc=.66eb457f-70ee-4b9c-a357-2fb380707d05@github.com>

On Mon, 9 Feb 2026 07:33:03 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Request provides an implementation for [JDK-8377388](https://bugs.openjdk.org/browse/JDK-8377388): 'Replacing "new StringReader(String)" by "Reader.of(CharSequence);" in Scanner'.

I ran this change in our CI with the latest mainline, and tier1, tier2 and tier3 tests completed without any related issues.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29627#issuecomment-3920244422

From aartemov at openjdk.org  Wed Feb 18 11:32:22 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 18 Feb 2026 11:32:22 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java
Message-ID: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>

Hi, please consider the following changes:

This is a port of FDLIBM atanh method.

-------------

Commit messages:
 - 8377223: Fixed typos.
 - 8377223: Fixed whitespaces.
 - 8377223: Fixed whitespaces.
 - 8377223: Removed commented out line.
 - 8377223: Port fdlibm atanh to java.

Changes: https://git.openjdk.org/jdk/pull/29782/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29782&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377223
  Stats: 652 lines in 7 files changed: 646 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/29782.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29782/head:pull/29782

PR: https://git.openjdk.org/jdk/pull/29782

From aartemov at openjdk.org  Wed Feb 18 11:32:22 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 18 Feb 2026 11:32:22 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java
In-Reply-To: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
Message-ID: <rJokFE_6Z7IhsfhOX4efr86aYzYO7TP3gjLVRsjj7Sc=.f899fd26-6a6c-41c6-b162-f7eb2706aa9b@github.com>

On Wed, 18 Feb 2026 10:10:31 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM atanh method.

Original C vs transliteration port:


$ diff -w fdlib_atanh.c Atanh.translit.java
1c1,3
< /* __ieee754_atanh(x)
---
> /**
>  *  Return the Inverse Hyperbolic Tangent of x
>  *
17a20,23
> private static final class Atanh {
>       private static final double zero = 0.0;
>       private static final double one = 1.0;
>       private static final double huge = 1.0e300;
19,35c25
< #include "fdlibm.h"
<
< #ifdef __STDC__
< static const double one = 1.0, huge = 1e300;
< #else
< static double one = 1.0, huge = 1e300;
< #endif
<
< static double zero = 0.0;
<
< #ifdef __STDC__
<       double __ieee754_atanh(double x)
< #else
<       double __ieee754_atanh(x)
<       double x;
< #endif
< {
---
>       static double compute(double x) {
38c28
<       unsigned lx;
---
>               /*unsigned*/ int lx;
47c37
<       __HI(x) = ix;           /* x <- |x| */
---
>               x = __HI(x, ix);     /* x <- |x| */
53a44
>       }



Transliteration vs more idiomatic port:

$ diff -w Atanh.translit.java Atanh.fdlibm.java
3d2
<  *
5,9d3
<  *    1.Reduced x to positive by atanh(-x) = -atanh(x)
<  *    2.For x>=0.5
<  *                1              2x                          x
<  *    atanh(x) = --- * log(1 + -------) = 0.5 * log1p(2 * --------)
<  *                2             1 - x                      1 - x
11,12d4
<  *  For x<0.5
<  *   atanh(x) = 0.5*log1p(2x+2x*x/(1-x))
14,17c6,12
<  *  Special cases:
<  *    atanh(x) is NaN if |x| > 1 with signal;
<  *    atanh(NaN) is that NaN with no signal;
<  *    atanh(+-1) is +-INF with signal.
---
>  *      atanh(x) is defined so that atanh(tanh(alpha)) = alpha, -&infin; &lt; alpha &lt; &infin;
>  *      and tanh(atanh(x)) = x, -1 &lt x &lt 1;
>  *      It can be written as atanh(x) = 0.5 * log1p(2 * x/(1-x)), -1 &lt; x &lt; 1;
>  *      1.
>  *          atanh(x) := 0.5 * log1p(2 * x/(1 - x)), if |x| >= 0.5,
>  *                   := 0.5 * log1p(2x + 2x * x/(1 - x)), if |x| < 0.5.
>  *
18a14,18
>  *
>  * Special cases:
>  *      only atanh(&plusmn;0)=&plusmn;0 is exact for finite x.
>  *      atanh(NaN) is NaN
>  *      atanh(&plusmn;1) is &plusmn;&infin;
20c20
< private static final class Atanh {
---
> static final class Atanh {
31,32c31,32
<               ix = hx&0x7fffffff;
<               if ((ix|((lx|(-lx))>>31))>0x3ff00000) /* |x|>1 */
---
>               ix = hx & 0x7fff_ffff;
>               if ((ix | ((lx | (-lx)) >> 31)) > 0x3ff0_0000) {     /* |x| > 1 */
34c34,35
<               if(ix==0x3ff00000)
---
>               }
>               if (ix == 0x3ff0_0000) {
36c37,40
<               if(ix<0x3e300000&&(huge+x)>zero) return x;  /* x<2**-28 */
---
>               }
>               if (ix < 0x3e30_0000 && (huge + x) > zero) {
>                       return x;                                        /* x<2**-28 */
>               }
38c42
<               if(ix<0x3fe00000) {     /* x < 0.5 */
---
>               if (ix < 0x3fe0_0000) {                              /* x < 0.5 */
40c44
<                       t = 0.5*log1p(t+t*x/(one-x));
---
>                       t = 0.5 * Log1p.compute(t + t*x/(one - x));
42,43c46,51
<                       t = 0.5*log1p((x+x)/(one-x));
<               if(hx>=0) return t; else return -t;
---
>                       t = 0.5 * Log1p.compute((x + x)/(one - x));
>               if (hx >= 0) {
>                       return t;
>               } else {
>                       return -t;
>               }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29782#issuecomment-3919911569

From duke at openjdk.org  Wed Feb 18 12:01:30 2026
From: duke at openjdk.org (ExE Boss)
Date: Wed, 18 Feb 2026 12:01:30 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java
In-Reply-To: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
Message-ID: <OaeFcWRR3AM6YWoDjDf5IvWdjgbO3UXl07dbTZVlQoI=.58d75532-1852-473e-98ce-94d3794bfc7a@github.com>

On Wed, 18 Feb 2026 10:10:31 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM atanh method.

test/jdk/java/lang/StrictMath/ExhaustingTests.java line 97:

> 95:             new UnaryTestCase("asinh", FdlibmTranslit::asinh, StrictMath::asinh, DEFAULT_SHIFT),
> 96:             new UnaryTestCase("acosh", FdlibmTranslit::acosh, StrictMath::acosh, DEFAULT_SHIFT),
> 97:             new UnaryTestCase("atanh",  FdlibmTranslit::atanh,  StrictMath::atanh,  DEFAULT_SHIFT),

Doubled?spaces:
Suggestion:

            new UnaryTestCase("atanh", FdlibmTranslit::atanh, StrictMath::atanh, DEFAULT_SHIFT),

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2821943706

From lancea at openjdk.org  Wed Feb 18 14:23:27 2026
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 18 Feb 2026 14:23:27 GMT
Subject: RFR: 8326487: ZipFileSystem.getPath("").getFileName() returns null
 instead of an empty Path [v2]
In-Reply-To: <_qYbrpWI2Y3i3XK50PKYTSNgAOq8YCW9mCmmXnw2crA=.212699fe-1b81-4be0-b8b1-e9034b70963c@github.com>
References: <qNn100G0Ww9P9JNxjdbCWFg_9Uxi7Z021f1h0Hlsl7c=.d5bfa973-c863-4882-ba85-77a57c1fa1a3@github.com>
 <_qYbrpWI2Y3i3XK50PKYTSNgAOq8YCW9mCmmXnw2crA=.212699fe-1b81-4be0-b8b1-e9034b70963c@github.com>
Message-ID: <wnwheTVB-vOgv1OH5k3oatwo7zTLkcoe3zMDIpKra9k=.7fef0372-f893-46bd-990f-8c976a652d57@github.com>

On Wed, 18 Feb 2026 02:17:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8326487?
>> 
>> `java.nio.file.Path.getFileName()` is specified to return a non-null value for an empty path. However, the current implementation of zipfs returns null for an empty path. The commit in this PR addresses that issue in zipfs and introduces a test which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move the test to PathOps

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29760#pullrequestreview-3820192149

From lancea at openjdk.org  Wed Feb 18 14:50:37 2026
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 18 Feb 2026 14:50:37 GMT
Subject: RFR: 8377983: (zipfs) ZipFileSystem.initCEN needlessly reads END
 header
In-Reply-To: <R1BI_g2_9_Bi7sSf_cetduR1qiTroi9eFJiF3v9asW4=.fa2626dd-f105-4f95-9838-74c21fd7b27d@github.com>
References: <R1BI_g2_9_Bi7sSf_cetduR1qiTroi9eFJiF3v9asW4=.fa2626dd-f105-4f95-9838-74c21fd7b27d@github.com>
Message-ID: <Am5S1--urmjxbdAGY_iERokXwSaZm7dex8dGaN5ZgVA=.b6b42ecf-5803-4e3f-b83f-6c1c817dac82@github.com>

On Mon, 16 Feb 2026 11:38:03 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which updates `ZipFileSystem.initCEN` to not include the END header when reading the CEN bytes into memory.
> 
> The inclusion of the (unused) END header is a remnant from conversion from native to Java in Java 9 and  was already fixed for the corresponding `ZipFile.Source.initCEN` via JDK-8339711.
> 
> Fixing this also in `ZipFileSystem` cleans up the code locally but more importantly brings the implemenation more into alignment with the `ZipFile`.
> 
> Pure refactoring / cleanup, `noreg-cleanup`.

Thank you for the cleanup PR   I think the changes look reasonable

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29741#pullrequestreview-3820330751

From eirbjo at openjdk.org  Wed Feb 18 15:22:56 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 18 Feb 2026 15:22:56 GMT
Subject: RFR: 8377983: (zipfs) ZipFileSystem.initCEN needlessly reads END
 header
In-Reply-To: <R1BI_g2_9_Bi7sSf_cetduR1qiTroi9eFJiF3v9asW4=.fa2626dd-f105-4f95-9838-74c21fd7b27d@github.com>
References: <R1BI_g2_9_Bi7sSf_cetduR1qiTroi9eFJiF3v9asW4=.fa2626dd-f105-4f95-9838-74c21fd7b27d@github.com>
Message-ID: <GK9ZkDDWZkVNPjiTG70fh9WKD12bukubpLWXxjIQTaY=.fbdf8be5-cd49-415b-9edf-703ba6637b43@github.com>

On Mon, 16 Feb 2026 11:38:03 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which updates `ZipFileSystem.initCEN` to not include the END header when reading the CEN bytes into memory.
> 
> The inclusion of the (unused) END header is a remnant from conversion from native to Java in Java 9 and  was already fixed for the corresponding `ZipFile.Source.initCEN` via JDK-8339711.
> 
> Fixing this also in `ZipFileSystem` cleans up the code locally but more importantly brings the implemenation more into alignment with the `ZipFile`.
> 
> Pure refactoring / cleanup, `noreg-cleanup`.

Thanks for the review Lance

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29741#issuecomment-3921414297

From eirbjo at openjdk.org  Wed Feb 18 15:22:57 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 18 Feb 2026 15:22:57 GMT
Subject: Integrated: 8377983: (zipfs) ZipFileSystem.initCEN needlessly reads
 END header
In-Reply-To: <R1BI_g2_9_Bi7sSf_cetduR1qiTroi9eFJiF3v9asW4=.fa2626dd-f105-4f95-9838-74c21fd7b27d@github.com>
References: <R1BI_g2_9_Bi7sSf_cetduR1qiTroi9eFJiF3v9asW4=.fa2626dd-f105-4f95-9838-74c21fd7b27d@github.com>
Message-ID: <gZR4rFevTfoj3Df1dPHMDChWUanYkD2uh_RV-ABtgY4=.3d25f26a-291b-46b8-a1ee-74b4dfa4e1a1@github.com>

On Mon, 16 Feb 2026 11:38:03 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which updates `ZipFileSystem.initCEN` to not include the END header when reading the CEN bytes into memory.
> 
> The inclusion of the (unused) END header is a remnant from conversion from native to Java in Java 9 and  was already fixed for the corresponding `ZipFile.Source.initCEN` via JDK-8339711.
> 
> Fixing this also in `ZipFileSystem` cleans up the code locally but more importantly brings the implemenation more into alignment with the `ZipFile`.
> 
> Pure refactoring / cleanup, `noreg-cleanup`.

This pull request has now been integrated.

Changeset: d02ac57e
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d02ac57e8469ac77cc4f53de77107a278ac5f346
Stats:     8 lines in 1 file changed: 0 ins; 0 del; 8 mod

8377983: (zipfs) ZipFileSystem.initCEN needlessly reads END header

Reviewed-by: lancea

-------------

PR: https://git.openjdk.org/jdk/pull/29741

From ogillespie at openjdk.org  Wed Feb 18 15:47:51 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Wed, 18 Feb 2026 15:47:51 GMT
Subject: RFR: 8378110: Add -XX: prefix to settings-file flags in
 RuntimeMXBean.getInputArguments()
Message-ID: <syyAUnwjy7bmrSvCNN9HjWDw20xNofCGLSI6ZaKLZPg=.e0eb1c44-0e14-4028-815b-9457ebf115b4@github.com>

Flags passed via a settings file (`.hotspotrc`, or `-XX:Flags=my-file`) do not have the `-XX:` prefix like they would have if passed as command-line args. `JVM_GetVmArguments` then prints these flags also without the prefix, along with command-line flags that _are_ prefixed.

However, users of `JVM_GetVmArguments` expect the arguments to be in a format that they can pass as command-line args, for example [in CDS static_dump](https://github.com/openjdk/jdk/blob/63f00fff921ed4ac0f595a0a013d399700433a2c/src/java.base/share/classes/jdk/internal/misc/CDS.java#L329-L338) - CDS static_dump currently *does not work* if the main VM uses flags from a settings file.

So, always add the `-XX:` prefix to flags from settings files in `JVM_GetVmArguments`. Updated existing test to cover this behaviour.

I looked for existing users of `JVM_GetVmArguments` and they either seem like they'll benefit from this change (CDS, JMH via `RuntimeMXBean.getInputArguments()`) or they won't care.

**Testing**

* Updated the existing InputArgument test with a case that verifies the new behaviour.
* Confirmed that CDS static_dump and JMH now work on a VM with flags from a file.

-------------

Commit messages:
 - 8378110: Add -XX: prefix to settings-file flags in RuntimeMXBean.getInputArguments()

Changes: https://git.openjdk.org/jdk/pull/29793/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29793&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378110
  Stats: 50 lines in 2 files changed: 37 ins; 5 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/29793.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29793/head:pull/29793

PR: https://git.openjdk.org/jdk/pull/29793

From epeter at openjdk.org  Wed Feb 18 16:25:11 2026
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 18 Feb 2026 16:25:11 GMT
Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in
 specific patterns [v10]
In-Reply-To: <_quPIapU_CUjz2J3W-s_3qOjV37ikujROE-CHeEcSZY=.ee511f07-d3dd-4b43-998f-1898167d9297@github.com>
References: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
 <_quPIapU_CUjz2J3W-s_3qOjV37ikujROE-CHeEcSZY=.ee511f07-d3dd-4b43-998f-1898167d9297@github.com>
Message-ID: <OyS2Xe8Q8xHBmN1audPltKsenhI2-E8tZW1fbzJHpkw=.1abf5ff4-7ae0-4a6a-82c5-c37093b1ce83@github.com>

On Thu, 5 Feb 2026 09:08:53 GMT, Eric Fang <erfang at openjdk.org> wrote:

>> `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common.
>> 
>> If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example:
>> 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)`
>> 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`.
>> 
>> In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast.
>> 
>> The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`.
>> 
>> The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain.
>> 
>> Current optimizations related to `VectorMaskCastNode` include:
>> 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760.
>> 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242.
>> 
>> This PR does the following optimizations:
>> 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct.
>> 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vect...
>
> Eric Fang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine the JTReg tests

The updates look good to me :)

Can you please merge with master, so I can run internal testing without any issues?

test/hotspot/jtreg/compiler/vectorapi/VectorMaskCastIdentityTest.java line 127:

> 125:         VectorMask<Integer> mInt128 = mFloat128.cast(IntVector.SPECIES_128);
> 126:         return mInt128.not().trueCount();
> 127:     }

We should probably be able to eventually optimize this, so that we only need a cast from short to int. But that could be a different RFE.

test/hotspot/jtreg/compiler/vectorapi/VectorStoreMaskIdentityTest.java line 31:

> 29: * @modules jdk.incubator.vector
> 30: *
> 31: * @run driver compiler.vectorapi.VectorStoreMaskIdentityTest

Suggestion:

* @run driver ${test.main.class}

This is possible since a recent JTREG version. It prevents copy mistakes, which can lead to the invocation of the wrong test - and then the local test is never executed - yikes ;)

-------------

PR Review: https://git.openjdk.org/jdk/pull/28313#pullrequestreview-3820869265
PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2823200233
PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2823216628

From epeter at openjdk.org  Wed Feb 18 16:25:14 2026
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 18 Feb 2026 16:25:14 GMT
Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in
 specific patterns [v10]
In-Reply-To: <OyS2Xe8Q8xHBmN1audPltKsenhI2-E8tZW1fbzJHpkw=.1abf5ff4-7ae0-4a6a-82c5-c37093b1ce83@github.com>
References: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
 <_quPIapU_CUjz2J3W-s_3qOjV37ikujROE-CHeEcSZY=.ee511f07-d3dd-4b43-998f-1898167d9297@github.com>
 <OyS2Xe8Q8xHBmN1audPltKsenhI2-E8tZW1fbzJHpkw=.1abf5ff4-7ae0-4a6a-82c5-c37093b1ce83@github.com>
Message-ID: <mSs4EYJmc2UCt7j_I6P6G4jXZJQwxbf0eBT4jWN3y74=.d6dfed35-7e8e-4ba7-9986-862c9346080c@github.com>

On Wed, 18 Feb 2026 16:16:08 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Eric Fang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refine the JTReg tests
>
> test/hotspot/jtreg/compiler/vectorapi/VectorMaskCastIdentityTest.java line 127:
> 
>> 125:         VectorMask<Integer> mInt128 = mFloat128.cast(IntVector.SPECIES_128);
>> 126:         return mInt128.not().trueCount();
>> 127:     }
> 
> We should probably be able to eventually optimize this, so that we only need a cast from short to int. But that could be a different RFE.

But it would be good if you left a comment here, that this would eventually be possible.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2823204791

From coffeys at openjdk.org  Wed Feb 18 17:17:23 2026
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 18 Feb 2026 17:17:23 GMT
Subject: RFR: 8364182: Add jcmd VM.security_properties command [v9]
In-Reply-To: <0L27_6Y7inkhN_LTkG2t2HuuvUGyiM9FGVe-J-RmTMY=.c0aebe13-ca63-457e-b7bf-e3efddb1ccc9@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <0L27_6Y7inkhN_LTkG2t2HuuvUGyiM9FGVe-J-RmTMY=.c0aebe13-ca63-457e-b7bf-e3efddb1ccc9@github.com>
Message-ID: <EQhXHwccrqusAehdwRJoBmHnWnhlo-a9b2zZ19Ro7jY=.5e0a9390-f5c7-46b9-984c-5f7356d23c48@github.com>

On Wed, 18 Feb 2026 09:30:29 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove clone

Looks good Kieran. Thanks for pushing ahead with this. Minor comments,

src/java.base/share/classes/java/security/Security.java line 334:

> 332:             }
> 333:             @Override
> 334:             public Properties getCurrentProperties() { return props;

minor nit: new line for "return props;"

test/hotspot/jtreg/serviceability/dcmd/vm/SecurityPropertiesTest.java line 33:

> 31: 
> 32: /*
> 33:  * @test

should a bug tag be added to this test ? Not sure if it's the norm for hotspot tests

-------------

PR Review: https://git.openjdk.org/jdk/pull/29124#pullrequestreview-3821178943
PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2823487016
PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2823490366

From eirbjo at openjdk.org  Wed Feb 18 17:17:46 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 18 Feb 2026 17:17:46 GMT
Subject: RFR: 8377992: (zipfs) Align ZipFileSystem END header validation with
 the ZipFile implementation
Message-ID: <1tONCY1QoXxaeUtr3LE4YoZk0UitQ5NqadNJOPFjREQ=.9b237170-fb07-4713-82fb-26b968b268de@github.com>

Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`.

This brings two validation checks over to `ZipFileSystem`:

* Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746)
* Rejection of END headers with a total entry count which cannot fit within the CEN byte array  (JDK-8341625)

The test `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is updated to to verify that ZIP files  rejected by the `ZipFile` constructor are now also rejected by `ZipFileSystem.newFileSystem`.

Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries.  Similar adjustments to `ZipFile` was done in JDK-8341625.

`ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`.

-------------

Commit messages:
 - Fix merge commit
 - Merge branch 'master' into zipfs-endofcen-validation
 - Realign comment whitespace
 - Use Math.toIntExact once in End::write
 - Align ZipFileSystem END header validation with the ZipFile validation

Changes: https://git.openjdk.org/jdk/pull/29747/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29747&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377992
  Stats: 85 lines in 3 files changed: 42 ins; 16 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/29747.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29747/head:pull/29747

PR: https://git.openjdk.org/jdk/pull/29747

From kfarrell at openjdk.org  Wed Feb 18 17:55:54 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Wed, 18 Feb 2026 17:55:54 GMT
Subject: RFR: 8364182: Add jcmd VM.security_properties command [v10]
In-Reply-To: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <2CAJOB43ZWZnLTLumQsG3F9K2hRqUzpgBzZ11HKHUI8=.abd8949e-aeb5-4cb5-b8ef-c8ff918ecbb3@github.com>

> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
> 
> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:

  newline

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29124/files
  - new: https://git.openjdk.org/jdk/pull/29124/files/40c02958..332ef7df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=08-09

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124

PR: https://git.openjdk.org/jdk/pull/29124

From kfarrell at openjdk.org  Wed Feb 18 17:55:57 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Wed, 18 Feb 2026 17:55:57 GMT
Subject: RFR: 8364182: Add jcmd VM.security_properties command [v9]
In-Reply-To: <EQhXHwccrqusAehdwRJoBmHnWnhlo-a9b2zZ19Ro7jY=.5e0a9390-f5c7-46b9-984c-5f7356d23c48@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <0L27_6Y7inkhN_LTkG2t2HuuvUGyiM9FGVe-J-RmTMY=.c0aebe13-ca63-457e-b7bf-e3efddb1ccc9@github.com>
 <EQhXHwccrqusAehdwRJoBmHnWnhlo-a9b2zZ19Ro7jY=.5e0a9390-f5c7-46b9-984c-5f7356d23c48@github.com>
Message-ID: <YTEipsxEyRJauICJMv9oQN8DxhNe7xmNf-NFLJggWnk=.46f518bd-8dde-4983-a7bc-07a8ce67d19c@github.com>

On Wed, 18 Feb 2026 17:13:49 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove clone
>
> test/hotspot/jtreg/serviceability/dcmd/vm/SecurityPropertiesTest.java line 33:
> 
>> 31: 
>> 32: /*
>> 33:  * @test
> 
> should a bug tag be added to this test ? Not sure if it's the norm for hotspot tests

I couldnt see it used in any test in this directory, but a few tests in other directories have it so not sure what best practise is here, maybe @kevinjwalls can advise?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2823662347

From nbenalla at openjdk.org  Wed Feb 18 17:58:26 2026
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 18 Feb 2026 17:58:26 GMT
Subject: RFR: 8309748: Improve host selection in `External Specifications`
 page [v2]
In-Reply-To: <FfFVf-qGUWALc-YIUgLGqMYhYw9WkkiHAhn7KPFccPc=.a7fb3f67-9066-4dd1-9857-e5a812b25200@github.com>
References: <VRQeGKu9h86k5u3kjRt83_F3Ig42hAjgx8Es7rQDrR4=.12c9ad24-a8d1-4ce9-9e49-3dcb701007b7@github.com>
 <FfFVf-qGUWALc-YIUgLGqMYhYw9WkkiHAhn7KPFccPc=.a7fb3f67-9066-4dd1-9857-e5a812b25200@github.com>
Message-ID: <ah9mE1SJIj11XdFDD2GABJrJziM8zRBCu_EV0d0_JFY=.72b44773-90dc-474a-a982-39e277116687@github.com>

On Wed, 17 Dec 2025 12:24:22 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to improve selection by host name in the External Specifications page. After trying a list of checkboxes as used in the API summary pages and finding it not a suitable solution, I found that a select/dropdown menu works best for this page. 
>> 
>>  - [New external specs page](https://cr.openjdk.org/~hannesw/8309748/api.00/external-specs.html)
>>  - [Old external specs page](https://docs.oracle.com/en/java/javase/25/docs/api/external-specs.html) for comparsion
>> 
>> I also updated `@spec` tags in `java.lang.Character` to point to `www.unicode.org` rather than `unicode.org` to avoid a  `unicode.org` entry in the host list (other `@spec` tags use the `www.unicode.org` host name). The short `unicode.org` URL is still used elsewhere in the `java.lang.Character` class, I can update those links to the canonical host name as well if desired.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove pointless parentheses

I think this looks good and is a positive change, but you will need to update the copyright version years to 2026

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28863#issuecomment-3922306646

From alanb at openjdk.org  Wed Feb 18 18:45:52 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Feb 2026 18:45:52 GMT
Subject: RFR: 8364182: Add jcmd VM.security_properties command [v10]
In-Reply-To: <2CAJOB43ZWZnLTLumQsG3F9K2hRqUzpgBzZ11HKHUI8=.abd8949e-aeb5-4cb5-b8ef-c8ff918ecbb3@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <2CAJOB43ZWZnLTLumQsG3F9K2hRqUzpgBzZ11HKHUI8=.abd8949e-aeb5-4cb5-b8ef-c8ff918ecbb3@github.com>
Message-ID: <FvH_Q75DYNEqKwSs2ITG1-VGUJGe0D5HFh13nZ4W_zU=.e5ca3b05-da37-4c38-b596-e1208693a6a4@github.com>

On Wed, 18 Feb 2026 17:55:54 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   newline

test/hotspot/jtreg/serviceability/dcmd/vm/SecurityPropertiesTest.java line 40:

> 38:  *          java.management
> 39:  *          jdk.internal.jvmstat/sun.jvmstat.monitor
> 40:  * @run testng SecurityPropertiesTest

Probably best to have this test start out as a JUnit rather than TestNG tests as there is effort to try to have new tests not use TestNG.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2823878639

From alanb at openjdk.org  Wed Feb 18 18:50:25 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Feb 2026 18:50:25 GMT
Subject: RFR: 8364182: Add jcmd VM.security_properties command [v10]
In-Reply-To: <2CAJOB43ZWZnLTLumQsG3F9K2hRqUzpgBzZ11HKHUI8=.abd8949e-aeb5-4cb5-b8ef-c8ff918ecbb3@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <2CAJOB43ZWZnLTLumQsG3F9K2hRqUzpgBzZ11HKHUI8=.abd8949e-aeb5-4cb5-b8ef-c8ff918ecbb3@github.com>
Message-ID: <fwbHjjoRZ7UyB6clfNWimqDXD-5t48P8Mzf2EV1ZQHc=.c4375e23-b3f8-4ded-87e6-0ed602b11787@github.com>

On Wed, 18 Feb 2026 17:55:54 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   newline

src/hotspot/share/services/diagnosticCommand.hpp line 101:

> 99:     PrintSecurityPropertiesDCmd(outputStream* output, bool heap) : DCmd(output, heap) { }
> 100:     static const char* name() { return "VM.security_properties"; }
> 101:     static const char* description() { return "Print java.security.Security properties."; }

I think the command name and description is good as the "-security" option in the early iterations would have tripped up at least some people that aren't aware that java.security.Security properties are different thing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2823897718

From ascarpino at openjdk.org  Wed Feb 18 19:32:02 2026
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 18 Feb 2026 19:32:02 GMT
Subject: RFR: 8377506: Implementation of PEM Encodings of Cryptographic
 Objects (Final)
In-Reply-To: <8f7gltAPyJA_dJnC6aQiuUH5owVmgTdZmq3Zk7XLij8=.840c2e8c-a781-47e5-9fa1-5649d22d7ae0@github.com>
References: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>
 <ZGmdj--8JlmcndZjsINm9OaIWxyghNV-tAM230BDNsE=.377954d6-0f88-4818-9f5f-6bc4b39760d5@github.com>
 <5jTxKzM1K4OyNJkw7qMrNI_7AUAvBm-3ZJudHiquocE=.ceb99d86-fc0b-478a-bd3c-330e2195633c@github.com>
 <tdtrbE6DJ7vaxI5N9-J-mtotzUJnZppw_YTWub05ljs=.e2585430-6ce2-4f1e-9a90-f23d41a6b193@github.com>
 <4VC1Pjawq829NUd1THBy3Jp4medr1FiHVtcBTVql1eE=.bf0d08ad-dbce-49bf-9fab-c32d3446931f@github.com>
 <2MAYdX3ocxcZ_XHYh5v_-Y6fuSPP1-IknZcYvhc2jhY=.32e4f090-3de8-4c51-bae6-cdc38f930c9a@github.com>
 <8f7gltAPyJA_dJnC6aQiuUH5owVmgTdZmq3Zk7XLij8=.840c2e8c-a781-47e5-9fa1-5649d22d7ae0@github.com>
Message-ID: <ylWJ91qkg0lhs3B9gbTNb9fgkMUHHEQzcrdW50U8RM0=.9897bc7e-af6f-439b-a26a-72d4b3876888@github.com>

On Wed, 18 Feb 2026 09:00:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I am sorry for this situation, but I can't say when or if we will be able to do something about this.
>> 
>> Currently, keeping the constant for one more release is always safe; removing it may be OK, but it is difficult to determine whether the missing constant will cause problems of not. It is only if the interim javac would touch a classfile that uses the constant, but it is not easy to say whether that will be the case. (And, IIRC, we've had a situation in the past that we had to re-introduce a constant, because it was needed in some specific circumstances.)
>> 
>> I'll think again of ways to avoid the need to keep the constants.
>
>> I am sorry for this situation, but I can't say when or if we will be able to do something about this.
> 
> No need to be sorry, you've always been very helpful and patient on this matter.
> 
> @ascarpino I assume you'll update the PR to leave the constant in place. You can probably drop the core-libs and compiler labels from the PR if you want to keep the review on security-dev.

To be sure, I need to leave `PEM_API`, but I can remove the `@JEP` line, correct?

@AlanBateman will do.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2824069480

From darcy at openjdk.org  Wed Feb 18 20:46:47 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 18 Feb 2026 20:46:47 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java
In-Reply-To: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
Message-ID: <UHjpCptOq7RwLka6qsXv8QmEJQK1OJaD_5i5qvZxbwc=.96589eac-1f37-4295-acd5-a822cafdfbc8@github.com>

On Wed, 18 Feb 2026 10:10:31 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM atanh method.

src/java.base/share/classes/java/lang/FdLibm.java line 3639:

> 3637:             int hx,ix;
> 3638:             /*unsigned*/ int lx;
> 3639:             hx = __HI(x);                                        /* high word */

Nit: I'd prefer "//" style comments for the one-liners here.

src/java.base/share/classes/java/lang/FdLibm.java line 3657:

> 3655:             } else
> 3656:                 t = 0.5 * Log1p.compute((x + x)/(one - x));
> 3657:             if (hx >= 0) {

Please consider some smaller-vertical space idiom for this, like a use of the ?: construct, etc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2824361225
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2824366170

From darcy at openjdk.org  Wed Feb 18 20:49:56 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 18 Feb 2026 20:49:56 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java
In-Reply-To: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
Message-ID: <Lwtm5OFKuLIowYMl70IddacLjMRAiwb9vUThSD7vVYk=.ef05b6c8-5fd2-46d3-807f-6f4d419b6dbb@github.com>

On Wed, 18 Feb 2026 10:10:31 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM atanh method.

src/java.base/share/classes/java/lang/FdLibm.java line 3631:

> 3629:      */
> 3630:     static final class Atanh {
> 3631:         private static final double zero = 0.0;

Earlier refactorings over Fdlibm.java removed use of "zero" and "one" in favor of having those literals in-line (JDK-8304423, etc). I think that would be a good convention to follow here as support for the new method is introduced.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2824380162

From darcy at openjdk.org  Wed Feb 18 20:53:02 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 18 Feb 2026 20:53:02 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java
In-Reply-To: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
Message-ID: <CFCeVFhtHHq7BXRDhVE2Em24INmr7EN4UBbIqBaosKc=.15964690-46b7-46e1-8de0-b8efad578b2a@github.com>

On Wed, 18 Feb 2026 10:10:31 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM atanh method.

I'd like @rgiulietti to review this PR before it goes back too; thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29782#issuecomment-3923145154

From kvn at openjdk.org  Wed Feb 18 22:51:18 2026
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 18 Feb 2026 22:51:18 GMT
Subject: RFR: 8377712: ConstantPool of WeakReferenceKey is not
 deterministic in CDS archive [v2]
In-Reply-To: <uxNkdMinqTfNSzIWdNkjttFJckj7ey_gq3sl9b9Pb5k=.b669cf19-f666-42d3-9120-1c5a9119eb1d@github.com>
References: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
 <uxNkdMinqTfNSzIWdNkjttFJckj7ey_gq3sl9b9Pb5k=.b669cf19-f666-42d3-9120-1c5a9119eb1d@github.com>
Message-ID: <Vxzdy7OPkxO-Jq4-Dv3QQIi03s03XiUHTQSh6EQQd7M=.07f81f5c-62a1-4e7c-ac29-cfab5e885335@github.com>

On Sat, 14 Feb 2026 07:23:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> We are seeing intermittent failures (12 times in Jan 2026) where the CDS archives generated in the JDK build is not deterministic.
>> 
>> The symptom is that (perhaps due to the peculiarity of hash codes and memory addressing??) the constant pool entry for `ReferenceKey<?>` in the `WeakReferenceKey` class is not resolved when the failure happens. Probably it's due to a particular layout in the hashtable such that we have no collisions so the `WeakReferenceKey::equals()` method is never called.
>> 
>> The fix is for the JVM to call a method in `WeakReferenceKey` to force this entry to be resolved.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @liach comments

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29678#pullrequestreview-3822602720

From psandoz at openjdk.org  Thu Feb 19 00:45:42 2026
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 19 Feb 2026 00:45:42 GMT
Subject: RFR: 8376186: [VectorAPI] Nomenclature change for concrete vector
 classes [v5]
In-Reply-To: <FSGjN2Mx-_Wlco-UYMlD-38L1l4lhEXW4xatAspO97w=.be1b4d07-06d1-402f-b7e5-c6bb65a7eab6@github.com>
References: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
 <FSGjN2Mx-_Wlco-UYMlD-38L1l4lhEXW4xatAspO97w=.be1b4d07-06d1-402f-b7e5-c6bb65a7eab6@github.com>
Message-ID: <_PfgR6lkqwX5dq4k72qdzLmtN9WcQ3EUDARnrubBPjY=.165de43c-877a-48b6-8357-f96db9dda667@github.com>

On Wed, 18 Feb 2026 04:39:54 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
>> 
>> In preparation of Float16 vector API support, changes to nomenclature of concrete vector class by suffixing the vector type with vector bit sizes e.g. FloatVector256 so that we don't end up generating names like Float16256Vector.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8376186
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8376186
>  - Reivew comments resolution
>  - Review comments resolution
>  - Review comment resolution
>  - Removing older artifact
>  - 8376186: [VectorAPI] Nomenclature change for concrete vector classes

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29614#pullrequestreview-3822919343

From jpai at openjdk.org  Thu Feb 19 01:44:16 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 19 Feb 2026 01:44:16 GMT
Subject: RFR: 8326487: ZipFileSystem.getPath("").getFileName() returns null
 instead of an empty Path [v2]
In-Reply-To: <_qYbrpWI2Y3i3XK50PKYTSNgAOq8YCW9mCmmXnw2crA=.212699fe-1b81-4be0-b8b1-e9034b70963c@github.com>
References: <qNn100G0Ww9P9JNxjdbCWFg_9Uxi7Z021f1h0Hlsl7c=.d5bfa973-c863-4882-ba85-77a57c1fa1a3@github.com>
 <_qYbrpWI2Y3i3XK50PKYTSNgAOq8YCW9mCmmXnw2crA=.212699fe-1b81-4be0-b8b1-e9034b70963c@github.com>
Message-ID: <Sxc8qcquCEkJ0_5iZtPuGIE6MfJUbRwhm3TsWs4ay8c=.06dbfcad-5839-42aa-ab02-f7ec4822c7a8@github.com>

On Wed, 18 Feb 2026 02:17:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8326487?
>> 
>> `java.nio.file.Path.getFileName()` is specified to return a non-null value for an empty path. However, the current implementation of zipfs returns null for an empty path. The commit in this PR addresses that issue in zipfs and introduces a test which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move the test to PathOps

Thank you Lance and Alan for the reviews. tier testing completed without any issues. I'll integrate this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29760#issuecomment-3924189048

From jpai at openjdk.org  Thu Feb 19 01:44:18 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 19 Feb 2026 01:44:18 GMT
Subject: Integrated: 8326487: ZipFileSystem.getPath("").getFileName() returns
 null instead of an empty Path
In-Reply-To: <qNn100G0Ww9P9JNxjdbCWFg_9Uxi7Z021f1h0Hlsl7c=.d5bfa973-c863-4882-ba85-77a57c1fa1a3@github.com>
References: <qNn100G0Ww9P9JNxjdbCWFg_9Uxi7Z021f1h0Hlsl7c=.d5bfa973-c863-4882-ba85-77a57c1fa1a3@github.com>
Message-ID: <vfhXaeKSx6virrK44hTJ4ttE3di4BsRiRTawHWSqsy8=.9c612571-d317-4da2-b613-775b0de2dd49@github.com>

On Tue, 17 Feb 2026 15:27:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8326487?
> 
> `java.nio.file.Path.getFileName()` is specified to return a non-null value for an empty path. However, the current implementation of zipfs returns null for an empty path. The commit in this PR addresses that issue in zipfs and introduces a test which reproduces the issue and verifies the fix.

This pull request has now been integrated.

Changeset: c594da73
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c594da7304b2e76a1833e7ef89a5f186fd7d65bb
Stats:     34 lines in 2 files changed: 28 ins; 0 del; 6 mod

8326487: ZipFileSystem.getPath("").getFileName() returns null instead of an empty Path

Reviewed-by: alanb, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/29760

From iklam at openjdk.org  Thu Feb 19 05:27:15 2026
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 19 Feb 2026 05:27:15 GMT
Subject: RFR: 8377712: ConstantPool of WeakReferenceKey is not
 deterministic in CDS archive
In-Reply-To: <6zpNwnhptQsaXSbK3lPp53L2I9y7UTSO4tDDsBVbvvA=.12330079-d403-4edd-b20f-3e5e90a51926@github.com>
References: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
 <6zpNwnhptQsaXSbK3lPp53L2I9y7UTSO4tDDsBVbvvA=.12330079-d403-4edd-b20f-3e5e90a51926@github.com>
Message-ID: <JdLqHXUCVTVl2u3_zdMj5IwnPCqlqPMVh_AL5FJNCiY=.137d9508-2aa5-466e-a885-3260e6c5ecde@github.com>

On Thu, 12 Feb 2026 05:58:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> We are seeing intermittent failures (12 times in Jan 2026) where the CDS archives generated in the JDK build is not deterministic.
>> 
>> The symptom is that (perhaps due to the peculiarity of hash codes and memory addressing??) the constant pool entry for `ReferenceKey<?>` in the `WeakReferenceKey` class is not resolved when the failure happens. Probably it's due to a particular layout in the hashtable such that we have no collisions so the `WeakReferenceKey::equals()` method is never called.
>> 
>> The fix is for the JVM to call a method in `WeakReferenceKey` to force this entry to be resolved.
>
> Or a better fix would be removing the == path for all reference keys. There's no case where this hits because you are always creating a new strong key. Missing use of class constant means the equals method is completely unused.

Thank you @liach @vnkozlov for the review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29678#issuecomment-3924758708

From iklam at openjdk.org  Thu Feb 19 05:27:16 2026
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 19 Feb 2026 05:27:16 GMT
Subject: Integrated: 8377712: ConstantPool of WeakReferenceKey is not
 deterministic in CDS archive
In-Reply-To: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
References: <kNdX01i08VvuiTH2Fvz1Sos67NK1iRvBpWdhK3rU3_c=.d32c584b-9430-4c04-89cd-4d4794486814@github.com>
Message-ID: <duaJyFKOwebkCtjpgsB1MNxkztHbQeC1_DAjod48qLg=.256a7801-f34a-4ec9-a329-56f137bf2679@github.com>

On Wed, 11 Feb 2026 20:28:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> We are seeing intermittent failures (12 times in Jan 2026) where the CDS archives generated in the JDK build is not deterministic.
> 
> The symptom is that (perhaps due to the peculiarity of hash codes and memory addressing??) the constant pool entry for `ReferenceKey<?>` in the `WeakReferenceKey` class is not resolved when the failure happens. Probably it's due to a particular layout in the hashtable such that we have no collisions so the `WeakReferenceKey::equals()` method is never called.
> 
> The fix is for the JVM to call a method in `WeakReferenceKey` to force this entry to be resolved.

This pull request has now been integrated.

Changeset: 33c9f20b
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33c9f20bef05239ee016d980dc69a3d583ce8293
Stats:     42 lines in 4 files changed: 39 ins; 1 del; 2 mod

8377712: ConstantPool of WeakReferenceKey is not deterministic in CDS archive

Reviewed-by: liach, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/29678

From liach at openjdk.org  Thu Feb 19 05:28:52 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Feb 2026 05:28:52 GMT
Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps
In-Reply-To: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
References: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
Message-ID: <bsO48_DHpJSPwWh2E0_r5lg_KM7dOp9oSN9aCuIEzCg=.47310ef9-9fcd-4cfd-b99d-c15095906504@github.com>

On Thu, 29 Jan 2026 12:40:42 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps.
> 
> Two interesting parts:
> 
> 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators.
> 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps.

The code change looks fine to me. Let another core library engineer double check.

Note this patch requires a release note according to the CSR: some calls like `new TreeSet<Integer>().subSet(-1, 1).stream().forEach(null);` now throws NPE instead of completing normally.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29485#pullrequestreview-3823568148

From liach at openjdk.org  Thu Feb 19 05:33:27 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Feb 2026 05:33:27 GMT
Subject: RFR: 8376186: [VectorAPI] Nomenclature change for concrete vector
 classes [v5]
In-Reply-To: <FSGjN2Mx-_Wlco-UYMlD-38L1l4lhEXW4xatAspO97w=.be1b4d07-06d1-402f-b7e5-c6bb65a7eab6@github.com>
References: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
 <FSGjN2Mx-_Wlco-UYMlD-38L1l4lhEXW4xatAspO97w=.be1b4d07-06d1-402f-b7e5-c6bb65a7eab6@github.com>
Message-ID: <8RAq9HJZCAT_4UfknShgMmygyUv_W2UcRsJW7YLdUEA=.de97a822-5fbb-4106-b2c9-1c9a2716c03b@github.com>

On Wed, 18 Feb 2026 04:39:54 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
>> 
>> In preparation of Float16 vector API support, changes to nomenclature of concrete vector class by suffixing the vector type with vector bit sizes e.g. FloatVector256 so that we don't end up generating names like Float16256Vector.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8376186
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8376186
>  - Reivew comments resolution
>  - Review comments resolution
>  - Review comment resolution
>  - Removing older artifact
>  - 8376186: [VectorAPI] Nomenclature change for concrete vector classes

The incremental changes look good.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29614#pullrequestreview-3823578127

From liach at openjdk.org  Thu Feb 19 05:50:13 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Feb 2026 05:50:13 GMT
Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps
In-Reply-To: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
References: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
Message-ID: <xFSkvBkVnG2mPXio_tLH_cEPUILCxh3xByv32N1AAQQ=.c4264eb0-78d2-40ef-8c3d-f0eb7807e7ea@github.com>

On Thu, 29 Jan 2026 12:40:42 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps.
> 
> Two interesting parts:
> 
> 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators.
> 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps.

These two modified files also need their copyright years updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29485#issuecomment-3924820609

From jbhateja at openjdk.org  Thu Feb 19 06:24:11 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 19 Feb 2026 06:24:11 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v13]
In-Reply-To: <IQb5728TfwOd7fA2DQhyzODXAXKydcj4ktEJjxvfd6w=.2275fd48-834c-4e4c-8617-a6b6b297ff79@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
 <IQb5728TfwOd7fA2DQhyzODXAXKydcj4ktEJjxvfd6w=.2275fd48-834c-4e4c-8617-a6b6b297ff79@github.com>
Message-ID: <R8bS5yRqOHQ8Gwv_kpI0xZPJM5266X5fMkFrJktOiWE=.1e4138f2-532e-4b1b-b524-166a5bc77665@github.com>

On Tue, 17 Feb 2026 12:16:43 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> I don't agree with this change because the benefit is little, the intrinsic does not stand in the future, and the implementation is hacky and not trivial. I think I can accept this PR if:
> 
> * It can be proved that the intrinsic is necessary even when we have constant information for `TypeVect`.
> * The fall back inlining can be made more generally applicable, and it is reliable under the non-determinism of incremental inlining.

Hi @merykitty,

Thank you for the detailed feedback. I?ve looked into the alternative you suggested?adding constant/lane info to TypeVect and having the compiler recognize the slice pattern (rearrange + blend with constant shuffle and mask) and replace it with VectorSliceNode, without a dedicated intrinsic?and I?d like to explain why I still believe the hybrid call generator is the more practical choice for this change, while keeping the door open for the pattern-based approach later.

**Why the pattern-based approach is still very non-trivial**

Even *after* we have constant shuffle and constant mask recognizing the slice idiom and recovering `origin` remains highly non-trivial:

1. **The shuffle is not a single constant node.** It is the output of `iotaShuffle(origin, 1, true)`, which is implemented by *several* nodes in the IR. So we must match that iotaShuffle subgraph and find the node whose input is the scalar `origin` (and require that to be ConI), 

2. **The mask** is compare-with-constant (e.g. `iota.compare(LT, filter)` with `filter = vlen - origin`) . 

3. **Actual patten match involving constant shuffle / mask ** depends on getting the blend/rearrange wiring right (which input is vec1 vs vec2, both rearranges using the *same* shuffle, mask semantics matching slice). 

So even with TypeVect constant info, we still need very complex / non-trivial *pattern* match probable the biggest pattern match in idiealization

**Why the hybrid call generator is a better fit for this change**

- **Bounded complexity:** We have one clear boundary?the slice call?and one check?`origin->is_con()`. If true, we emit VectorSliceNode; otherwise we inline the Java fallback. No graph pattern matching, no decoding of shuffle/mask vectors, no dependency on the exact shape of iotaShuffle or compare nodes.

- **Same user benefit when it works:** In both approaches, constant-index slice gets VectorSliceNode ? VPALIGNR. With the hybrid approach, if we don?t intrinsify (e.g. origin not yet constant), we still inline the fallback and the subsequent Vector API calls can be optimized as today. 

**Proposed path**

I think the most practical path is to **proceed with the hybrid call generator** for this PR so we can ship a reliable slice optimization (including for use cases like simdjson) without taking on the full cost and risk of TypeVect constant info and slice-pattern matching right now. Once this is in, we have a clear baseline: constant-index slice is optimized; variable index uses the inlined fallback.

If we later introduce TypeVect constant info and a more generic framework for recognizing vector idioms (e.g. patterns that consume constant shuffle/mask or that match subgraphs like iotaShuffle), we can **revisit** slice: add a pattern-based recognition that either supplements or eventually replaces the intrinsic.  Please note x86 back end implimentation will still be usable if we later remove intrinsic and use complex patten  matching to deduce VectorSliceNode

Thanks again for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3924942814

From jbhateja at openjdk.org  Thu Feb 19 06:24:13 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 19 Feb 2026 06:24:13 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v13]
In-Reply-To: <6uAVPmcvCSfEM966nc9ZOuhX-rfrIWpijWGRnO-Q7MY=.0fdec110-0d38-484f-aba1-0d2fb4f8d3df@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
 <CLbjCWRXNzWnGSVtjGympjUYR37KIMi3EFlClCkST5Y=.87a986cf-1b18-4aeb-9c85-89bb4cf596c9@github.com>
 <kW5zcGPvbHHdyb2rkAR3Hm8Nk2WxI_r-pSDIuISU1lU=.454a4eb4-8e09-4b85-af03-6f02b16021d3@github.com>
 <cn0CHZ8CKvm_Uq5_g8g0urH6lJ-1J8zeYFMSlNibdzc=.cc542731-3e06-4904-99cc-ee336199bd67@github.com>
 <-mNN8SPSvPoy7pes58gi6LSjd99zekix1ALZugP4IWE=.172b7fc6-5590-45d1-bcc1-66b2097ec295@github.com>
 <WXQJJukSU1B3w19GsBoGdwhK8MJdLRxjU9AkXh1XBmg=.73e41bca-0a0e-4047-b70e-2b95892bb832@github.com>
 <DbnRd_MfDZ5JhiCyA8gB-URCcUs3A7lMshbGpGgq9gs=.25b6c72d-f595-4912-85ca-4262f1723499@github.com>
 <6uAVPmcvCSfEM966nc9ZOuhX-rfrIWpijWGRnO-Q7MY=.0fdec110-0d38-484f-aba1-0d2fb4f8d3df@github.com>
Message-ID: <P2aarnOjq_sr_JT59t8OYPJpQWRb9ttPQeDKs81zfhU=.2d7c3cf3-0400-403f-b1db-95d6d510188d@github.com>

On Tue, 17 Feb 2026 12:14:54 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> We only perform fallback inlining on first intrinsification failure for sliceOp, this is a very localized change.
>> https://github.com/jatin-bhateja/jdk/blob/1dfff5589c8b6c83dfc9810bddbb676c7982c904/src/hotspot/share/opto/callGenerator.cpp#L455
>
> Thanks for pointing out the change. I think that's more hacky than I have expected.

This is selective enablement of inlining for intrinsic failures which uses vector API in the fall back implimentation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2825899746

From jbhateja at openjdk.org  Thu Feb 19 06:27:04 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 19 Feb 2026 06:27:04 GMT
Subject: RFR: 8376186: [VectorAPI] Nomenclature change for concrete vector
 classes [v5]
In-Reply-To: <_PfgR6lkqwX5dq4k72qdzLmtN9WcQ3EUDARnrubBPjY=.165de43c-877a-48b6-8357-f96db9dda667@github.com>
References: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
 <FSGjN2Mx-_Wlco-UYMlD-38L1l4lhEXW4xatAspO97w=.be1b4d07-06d1-402f-b7e5-c6bb65a7eab6@github.com>
 <_PfgR6lkqwX5dq4k72qdzLmtN9WcQ3EUDARnrubBPjY=.165de43c-877a-48b6-8357-f96db9dda667@github.com>
Message-ID: <Rphchiszgg9iwYKz4gZmCU6DJdAoCoodKlUr_pZoPqo=.1e7cd6d9-79f8-458a-849c-16ae62e39c00@github.com>

On Thu, 19 Feb 2026 00:43:14 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8376186
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8376186
>>  - Reivew comments resolution
>>  - Review comments resolution
>>  - Review comment resolution
>>  - Removing older artifact
>>  - 8376186: [VectorAPI] Nomenclature change for concrete vector classes
>
> Marked as reviewed by psandoz (Reviewer).

Thanks @PaulSandoz and @liach

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29614#issuecomment-3924949600

From jbhateja at openjdk.org  Thu Feb 19 06:27:06 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 19 Feb 2026 06:27:06 GMT
Subject: Integrated: 8376186: [VectorAPI] Nomenclature change for concrete
 vector classes
In-Reply-To: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
References: <WWOwFCUAooSS2uYcuNBNAwXbM_tbcP_CiqRrGvKp_aQ=.83766ea8-2e97-4b04-a2b7-40cc8d347745@github.com>
Message-ID: <ChOhB4LCld6sLQ59g4E0lkO9E3RyUrCVlYGYNPABu-E=.f6644b9d-9ae9-470d-8767-268d89a33269@github.com>

On Fri, 6 Feb 2026 18:33:17 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
> 
> In preparation of Float16 vector API support, changes to nomenclature of concrete vector class by suffixing the vector type with vector bit sizes e.g. FloatVector256 so that we don't end up generating names like Float16256Vector.
> 
> All existing Vector API jtreg test are passing with the patch.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

This pull request has now been integrated.

Changeset: 759fe588
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/759fe58877ac75a9157e831cc5e54aaa70250223
Stats:     74831 lines in 131 files changed: 31371 ins; 31372 del; 12088 mod

8376186: [VectorAPI] Nomenclature change for concrete vector classes

Reviewed-by: liach, psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/29614

From qamai at openjdk.org  Thu Feb 19 06:57:19 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 19 Feb 2026 06:57:19 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v13]
In-Reply-To: <R8bS5yRqOHQ8Gwv_kpI0xZPJM5266X5fMkFrJktOiWE=.1e4138f2-532e-4b1b-b524-166a5bc77665@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
 <IQb5728TfwOd7fA2DQhyzODXAXKydcj4ktEJjxvfd6w=.2275fd48-834c-4e4c-8617-a6b6b297ff79@github.com>
 <R8bS5yRqOHQ8Gwv_kpI0xZPJM5266X5fMkFrJktOiWE=.1e4138f2-532e-4b1b-b524-166a5bc77665@github.com>
Message-ID: <-LJNI3YsyPlBX8nxSKLK45z7gSqAfOy3Lv4_HVlMw1c=.4fbdb78e-6255-4bff-81a4-7f17422f2802@github.com>

On Thu, 19 Feb 2026 06:21:39 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Even after we have constant shuffle and constant mask recognizing the slice idiom and recovering origin remains highly non-trivial

I think you are misunderstanding, when `TypeVect` has constant information, the shuffle indices and the blend mask will constant fold, and there is no `iotaShuffle` subgraph or the compare-with-constant node there to inspect to extract the `origin`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3925041361

From alanb at openjdk.org  Thu Feb 19 07:37:13 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 19 Feb 2026 07:37:13 GMT
Subject: RFR: 8378118: Test tools/jimage/JImageBadFileTest.java failed on
 Windows
In-Reply-To: <osTab7bHlL02EfiBJGHxrsjqzGcRVxrS8jbWWVz_eFg=.ed9d1730-0cd6-425c-9ccf-ebd7e1e96a79@github.com>
References: <osTab7bHlL02EfiBJGHxrsjqzGcRVxrS8jbWWVz_eFg=.ed9d1730-0cd6-425c-9ccf-ebd7e1e96a79@github.com>
Message-ID: <6wGpybFCDWVzQtdWfQGb98WpcK-QRCAR3x7oB00tRsE=.6721d229-b7e8-45b2-8ba8-98ec7409d2e4@github.com>

On Wed, 18 Feb 2026 10:42:01 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removed the manual file tidyup on the expectation that jtreg will sort that all out.
> Switched to using Utils.createTempFile() while I was there.

test/jdk/tools/jimage/JImageBadFileTest.java line 82:

> 80:             throws IOException {
> 81:         int remaining = maxLen >= 0 ? maxLen : Integer.MAX_VALUE;
> 82:         Path dst = Utils.createTempFile("modules-" + label, "");

Just curious why this is changed.

test/jdk/tools/jimage/JImageBadFileTest.java line 100:

> 98:         } catch (IOException e) {
> 99:             Files.deleteIfExists(dst);
> 100:             throw e;

Good, this allows it to be saved in the event of a test failure too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29783#discussion_r2826103532
PR Review Comment: https://git.openjdk.org/jdk/pull/29783#discussion_r2826106775

From jbhateja at openjdk.org  Thu Feb 19 07:39:14 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 19 Feb 2026 07:39:14 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v13]
In-Reply-To: <-LJNI3YsyPlBX8nxSKLK45z7gSqAfOy3Lv4_HVlMw1c=.4fbdb78e-6255-4bff-81a4-7f17422f2802@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
 <IQb5728TfwOd7fA2DQhyzODXAXKydcj4ktEJjxvfd6w=.2275fd48-834c-4e4c-8617-a6b6b297ff79@github.com>
 <R8bS5yRqOHQ8Gwv_kpI0xZPJM5266X5fMkFrJktOiWE=.1e4138f2-532e-4b1b-b524-166a5bc77665@github.com>
 <-LJNI3YsyPlBX8nxSKLK45z7gSqAfOy3Lv4_HVlMw1c=.4fbdb78e-6255-4bff-81a4-7f17422f2802@github.com>
Message-ID: <k2Fc_I4hsaSqgufPddG0JCLLNP_eB1-h25q-7lQBcIY=.1a024ef5-ed5c-4abc-8017-0ce34ea4ec62@github.com>

On Thu, 19 Feb 2026 06:54:40 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> > Even after we have constant shuffle and constant mask recognizing the slice idiom and recovering origin remains highly non-trivial
> 
> I think you are misunderstanding, when `TypeVect` has constant information, the shuffle indices and the blend mask will constant fold, and there is no `iotaShuffle` subgraph or the compare-with-constant node there to inspect to extract the `origin`.

Given that vector lane itself are variable an application of constant shuffle will not fold rearrange, so a complex pattern match to infer VectorSliceNode (with constant index) probably in blend idealization will still have to deal with a graph pallet consisting of blend with constant mask, two re-arrange nodes with constant shuffles, and some other non-folded nodes.


    /*package-private*/
    final
    @ForceInline
    IntVector sliceTemplate(int origin, Vector<Integer> v1) {
        IntVector that = (IntVector) v1;
        that.check(this);
        Objects.checkIndex(origin, length() + 1);
        IntVector iotaVector = (IntVector) iotaShuffle().toBitsVector();
        IntVector filter = broadcast((int)(length() - origin));
        VectorMask<Integer> blendMask = iotaVector.compare(VectorOperators.LT, filter);
        AbstractShuffle<Integer> iota = iotaShuffle(origin, 1, true);
        return that.rearrange(iota).blend(this.rearrange(iota), blendMask);
    }


I think its reasonable to proceed with the hybrid call generator for **this PR** so we can ship a reliable slice optimization (including for use cases like simdjson) without taking on the full cost and risk of TypeVect constant info and slice-pattern matching right now. In future once constant TypeVect are in production we can replace existing intrinsification approach with patten match and still use the backend implementation as it is.

Let think over it and also seek other's opinion (@sviswa7)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3925170985

From hannesw at openjdk.org  Thu Feb 19 07:59:52 2026
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 19 Feb 2026 07:59:52 GMT
Subject: RFR: 8309748: Improve host selection in `External Specifications`
 page [v3]
In-Reply-To: <VRQeGKu9h86k5u3kjRt83_F3Ig42hAjgx8Es7rQDrR4=.12c9ad24-a8d1-4ce9-9e49-3dcb701007b7@github.com>
References: <VRQeGKu9h86k5u3kjRt83_F3Ig42hAjgx8Es7rQDrR4=.12c9ad24-a8d1-4ce9-9e49-3dcb701007b7@github.com>
Message-ID: <pcpJDGRCtt4jewQ9_YFMBLEOHvWPhn1I2FmbV_B0XV0=.a4d037dc-df25-46f5-b1a8-d65435adbe8d@github.com>

> Please review a change to improve selection by host name in the External Specifications page. After trying a list of checkboxes as used in the API summary pages and finding it not a suitable solution, I found that a select/dropdown menu works best for this page. 
> 
>  - [New external specs page](https://cr.openjdk.org/~hannesw/8309748/api.00/external-specs.html)
>  - [Old external specs page](https://docs.oracle.com/en/java/javase/25/docs/api/external-specs.html) for comparsion
> 
> I also updated `@spec` tags in `java.lang.Character` to point to `www.unicode.org` rather than `unicode.org` to avoid a  `unicode.org` entry in the host list (other `@spec` tags use the `www.unicode.org` host name). The short `unicode.org` URL is still used elsewhere in the `java.lang.Character` class, I can update those links to the canonical host name as well if desired.

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright headers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28863/files
  - new: https://git.openjdk.org/jdk/pull/28863/files/fe88df58..b86db58d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28863&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28863&range=01-02

  Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/28863.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28863/head:pull/28863

PR: https://git.openjdk.org/jdk/pull/28863

From hannesw at openjdk.org  Thu Feb 19 08:02:06 2026
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 19 Feb 2026 08:02:06 GMT
Subject: RFR: 8309748: Improve host selection in `External Specifications`
 page [v2]
In-Reply-To: <FfFVf-qGUWALc-YIUgLGqMYhYw9WkkiHAhn7KPFccPc=.a7fb3f67-9066-4dd1-9857-e5a812b25200@github.com>
References: <VRQeGKu9h86k5u3kjRt83_F3Ig42hAjgx8Es7rQDrR4=.12c9ad24-a8d1-4ce9-9e49-3dcb701007b7@github.com>
 <FfFVf-qGUWALc-YIUgLGqMYhYw9WkkiHAhn7KPFccPc=.a7fb3f67-9066-4dd1-9857-e5a812b25200@github.com>
Message-ID: <Af5vFzLFQnslcE7jpy7t195zuPR4CKhgebRXWrZC4bE=.2b427560-98f1-45b8-b8ad-1ffc1a5dce0c@github.com>

On Wed, 17 Dec 2025 12:24:22 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to improve selection by host name in the External Specifications page. After trying a list of checkboxes as used in the API summary pages and finding it not a suitable solution, I found that a select/dropdown menu works best for this page. 
>> 
>>  - [New external specs page](https://cr.openjdk.org/~hannesw/8309748/api.00/external-specs.html)
>>  - [Old external specs page](https://docs.oracle.com/en/java/javase/25/docs/api/external-specs.html) for comparsion
>> 
>> I also updated `@spec` tags in `java.lang.Character` to point to `www.unicode.org` rather than `unicode.org` to avoid a  `unicode.org` entry in the host list (other `@spec` tags use the `www.unicode.org` host name). The short `unicode.org` URL is still used elsewhere in the `java.lang.Character` class, I can update those links to the canonical host name as well if desired.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove pointless parentheses

Thanks for the review, Nizar. I updated copyright headers on all files.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28863#issuecomment-3925298819

From jbhateja at openjdk.org  Thu Feb 19 08:17:10 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 19 Feb 2026 08:17:10 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v23]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <5bgpSMfLS2QBccwx0zxZr7-yQXhiraTLNkQ7rN8hxNs=.319d076a-d903-4a35-98ce-0fd678a7173a@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - JCheck whitespace fixes
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Test cleanups and re-factoring
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Adding new lane type constants for intrinsic entries, removing basictype extension changes
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Clanups
 - Refactoring vectorIntrinsics
 - Refactoring and cleanups
 - ... and 30 more: https://git.openjdk.org/jdk/compare/759fe588...e1e0a31e

-------------

Changes: https://git.openjdk.org/jdk/pull/28002/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=22
  Stats: 55573 lines in 117 files changed: 50822 ins; 137 del; 4614 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

PR: https://git.openjdk.org/jdk/pull/28002

From ogillespie at openjdk.org  Thu Feb 19 09:35:00 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Thu, 19 Feb 2026 09:35:00 GMT
Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps [v2]
In-Reply-To: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
References: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
Message-ID: <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>

> Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps.
> 
> Two interesting parts:
> 
> 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators.
> 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps.

Oli Gillespie 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 copyright
 - Merge remote-tracking branch 'origin/master' into spliterator-test
 - Switch to Objects.requireNonNull
 - Add tests and fix impl

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29485/files
  - new: https://git.openjdk.org/jdk/pull/29485/files/82be36d8..f376e3c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29485&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29485&range=00-01

  Stats: 89511 lines in 1537 files changed: 44815 ins; 21887 del; 22809 mod
  Patch: https://git.openjdk.org/jdk/pull/29485.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29485/head:pull/29485

PR: https://git.openjdk.org/jdk/pull/29485

From ogillespie at openjdk.org  Thu Feb 19 09:54:47 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Thu, 19 Feb 2026 09:54:47 GMT
Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps [v2]
In-Reply-To: <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
References: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
 <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
Message-ID: <1OAVa9wBd_DaM9WbDP8b-RZ5G3G8JZaY5h2zVxqY9WI=.832903cb-c9a5-460f-bcfc-a0a636de93f0@github.com>

On Thu, 19 Feb 2026 09:35:00 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps.
>> 
>> Two interesting parts:
>> 
>> 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators.
>> 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps.
>
> Oli Gillespie 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 copyright
>  - Merge remote-tracking branch 'origin/master' into spliterator-test
>  - Switch to Objects.requireNonNull
>  - Add tests and fix impl

Thanks. Created release note: https://bugs.openjdk.org/browse/JDK-8378229 and updated copyright.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29485#issuecomment-3926033142

From aartemov at openjdk.org  Thu Feb 19 10:13:07 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 19 Feb 2026 10:13:07 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java
In-Reply-To: <OaeFcWRR3AM6YWoDjDf5IvWdjgbO3UXl07dbTZVlQoI=.58d75532-1852-473e-98ce-94d3794bfc7a@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
 <OaeFcWRR3AM6YWoDjDf5IvWdjgbO3UXl07dbTZVlQoI=.58d75532-1852-473e-98ce-94d3794bfc7a@github.com>
Message-ID: <kKaUTgZdD9Of1sokXvHjagD24LaUK-JWv07hWCxjOzg=.539a9627-b5cf-43f8-ac3a-7df25e798aba@github.com>

On Wed, 18 Feb 2026 11:58:22 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM atanh method.
>
> test/jdk/java/lang/StrictMath/ExhaustingTests.java line 97:
> 
>> 95:             new UnaryTestCase("asinh", FdlibmTranslit::asinh, StrictMath::asinh, DEFAULT_SHIFT),
>> 96:             new UnaryTestCase("acosh", FdlibmTranslit::acosh, StrictMath::acosh, DEFAULT_SHIFT),
>> 97:             new UnaryTestCase("atanh",  FdlibmTranslit::atanh,  StrictMath::atanh,  DEFAULT_SHIFT),
> 
> Doubled?spaces:
> Suggestion:
> 
>             new UnaryTestCase("atanh", FdlibmTranslit::atanh, StrictMath::atanh, DEFAULT_SHIFT),

Addressed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2826803505

From aartemov at openjdk.org  Thu Feb 19 10:13:04 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 19 Feb 2026 10:13:04 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java
In-Reply-To: <Lwtm5OFKuLIowYMl70IddacLjMRAiwb9vUThSD7vVYk=.ef05b6c8-5fd2-46d3-807f-6f4d419b6dbb@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
 <Lwtm5OFKuLIowYMl70IddacLjMRAiwb9vUThSD7vVYk=.ef05b6c8-5fd2-46d3-807f-6f4d419b6dbb@github.com>
Message-ID: <reSM05NJDI2LN40wIbCsKIfw_BCtxxnEJbHr4ebgFaI=.3924f64e-dd53-4ad7-937c-2a8d23d5ebf9@github.com>

On Wed, 18 Feb 2026 20:47:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM atanh method.
>
> src/java.base/share/classes/java/lang/FdLibm.java line 3631:
> 
>> 3629:      */
>> 3630:     static final class Atanh {
>> 3631:         private static final double zero = 0.0;
> 
> Earlier refactorings over Fdlibm.java removed use of "zero" and "one" in favor of having those literals in-line (JDK-8304423, etc). I think that would be a good convention to follow here as support for the new method is introduced.

Sure, addressed.

> src/java.base/share/classes/java/lang/FdLibm.java line 3639:
> 
>> 3637:             int hx,ix;
>> 3638:             /*unsigned*/ int lx;
>> 3639:             hx = __HI(x);                                        /* high word */
> 
> Nit: I'd prefer "//" style comments for the one-liners here.

Addressed.

> src/java.base/share/classes/java/lang/FdLibm.java line 3657:
> 
>> 3655:             } else
>> 3656:                 t = 0.5 * Log1p.compute((x + x)/(one - x));
>> 3657:             if (hx >= 0) {
> 
> Please consider some smaller-vertical space idiom for this, like a use of the ?: construct, etc.

Addressed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2826806044
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2826804023
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2826805218

From kevinw at openjdk.org  Thu Feb 19 10:28:15 2026
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 19 Feb 2026 10:28:15 GMT
Subject: RFR: 8364182: Add jcmd VM.security_properties command [v10]
In-Reply-To: <FvH_Q75DYNEqKwSs2ITG1-VGUJGe0D5HFh13nZ4W_zU=.e5ca3b05-da37-4c38-b596-e1208693a6a4@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <2CAJOB43ZWZnLTLumQsG3F9K2hRqUzpgBzZ11HKHUI8=.abd8949e-aeb5-4cb5-b8ef-c8ff918ecbb3@github.com>
 <FvH_Q75DYNEqKwSs2ITG1-VGUJGe0D5HFh13nZ4W_zU=.e5ca3b05-da37-4c38-b596-e1208693a6a4@github.com>
Message-ID: <DGMAFcDuMY0hlGc95-a9k1QKcrXwgkzRbr7em84hW5Q=.010ceced-66f0-468d-9da3-77f63f470dcb@github.com>

On Wed, 18 Feb 2026 18:43:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   newline
>
> test/hotspot/jtreg/serviceability/dcmd/vm/SecurityPropertiesTest.java line 40:
> 
>> 38:  *          java.management
>> 39:  *          jdk.internal.jvmstat/sun.jvmstat.monitor
>> 40:  * @run testng SecurityPropertiesTest
> 
> Probably best to have this test start out as a JUnit rather than TestNG tests as there is effort to try to have new tests not use TestNG.

The existing dcmd tests are testng so understandable to duplicate that.

@AlanBateman  Alan added some JUnit tests in this area for the virtual thread tests, but is that policy/advice/preference...?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2826896318

From kevinw at openjdk.org  Thu Feb 19 10:28:11 2026
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 19 Feb 2026 10:28:11 GMT
Subject: RFR: 8364182: Add jcmd VM.security_properties command [v9]
In-Reply-To: <YTEipsxEyRJauICJMv9oQN8DxhNe7xmNf-NFLJggWnk=.46f518bd-8dde-4983-a7bc-07a8ce67d19c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <0L27_6Y7inkhN_LTkG2t2HuuvUGyiM9FGVe-J-RmTMY=.c0aebe13-ca63-457e-b7bf-e3efddb1ccc9@github.com>
 <EQhXHwccrqusAehdwRJoBmHnWnhlo-a9b2zZ19Ro7jY=.5e0a9390-f5c7-46b9-984c-5f7356d23c48@github.com>
 <YTEipsxEyRJauICJMv9oQN8DxhNe7xmNf-NFLJggWnk=.46f518bd-8dde-4983-a7bc-07a8ce67d19c@github.com>
Message-ID: <0lqJ8vcrRtKwwEZVL3cmKZTqyEZmcolSXn-F48cS5yA=.66a532cb-fb01-4866-962a-4255eb59025a@github.com>

On Wed, 18 Feb 2026 17:51:14 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/dcmd/vm/SecurityPropertiesTest.java line 33:
>> 
>>> 31: 
>>> 32: /*
>>> 33:  * @test
>> 
>> should a bug tag be added to this test ? Not sure if it's the norm for hotspot tests
>
> I couldnt see it used in any test in this directory, but a few tests in other directories have it so not sure what best practise is here, maybe @kevinjwalls can advise?

Yes the bug tag has to be welcome...
I see it used elsewhere in area, but yes it's not in e.g. SystemPropertiesTest which would have been the obvious reference.  This may have been there since jcmd was introduced.  It's good to have the tag. 8-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2826884357

From duke at openjdk.org  Thu Feb 19 10:53:28 2026
From: duke at openjdk.org (David Beaumont)
Date: Thu, 19 Feb 2026 10:53:28 GMT
Subject: RFR: 8378118: Test tools/jimage/JImageBadFileTest.java failed on
 Windows
In-Reply-To: <6wGpybFCDWVzQtdWfQGb98WpcK-QRCAR3x7oB00tRsE=.6721d229-b7e8-45b2-8ba8-98ec7409d2e4@github.com>
References: <osTab7bHlL02EfiBJGHxrsjqzGcRVxrS8jbWWVz_eFg=.ed9d1730-0cd6-425c-9ccf-ebd7e1e96a79@github.com>
 <6wGpybFCDWVzQtdWfQGb98WpcK-QRCAR3x7oB00tRsE=.6721d229-b7e8-45b2-8ba8-98ec7409d2e4@github.com>
Message-ID: <nySOsz62QW8U0sNf1YH2otpDCWOs_QHGlLaiYoJ2iwI=.3fa62221-53fa-413f-9acd-bc83c26660c5@github.com>

On Thu, 19 Feb 2026 07:33:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Removed the manual file tidyup on the expectation that jtreg will sort that all out.
>> Switched to using Utils.createTempFile() while I was there.
>
> test/jdk/tools/jimage/JImageBadFileTest.java line 82:
> 
>> 80:             throws IOException {
>> 81:         int remaining = maxLen >= 0 ? maxLen : Integer.MAX_VALUE;
>> 82:         Path dst = Utils.createTempFile("modules-" + label, "");
> 
> Just curious why this is changed.

It's just the more idiomatic way to make temp files in tests, since it hides any semantics related to knowing that the current working directory is the correct place for temporary files. Fewer details in the test code itself.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29783#discussion_r2827045289

From kevinw at openjdk.org  Thu Feb 19 11:35:44 2026
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 19 Feb 2026 11:35:44 GMT
Subject: RFR: 8364182: Add jcmd VM.security_properties command [v10]
In-Reply-To: <2CAJOB43ZWZnLTLumQsG3F9K2hRqUzpgBzZ11HKHUI8=.abd8949e-aeb5-4cb5-b8ef-c8ff918ecbb3@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <2CAJOB43ZWZnLTLumQsG3F9K2hRqUzpgBzZ11HKHUI8=.abd8949e-aeb5-4cb5-b8ef-c8ff918ecbb3@github.com>
Message-ID: <PYpvgbbwPgZ2p5uBck22R2Xas2XfEJHYtgCaVe949Po=.f54ff7a2-d871-48ae-8f37-7c7f2ef7cc80@github.com>

On Wed, 18 Feb 2026 17:55:54 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   newline

src/hotspot/share/services/diagnosticCommand.cpp line 344:

> 342:   InstanceKlass* ik = InstanceKlass::cast(k);
> 343:   if (ik->should_be_initialized()) {
> 344:       ik->initialize(THREAD);

These two space indents are hotspot C++style, we can't change them all to 4 space indents.  If you can revert the spaces, it will also make it clearer what the real changes are.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2827284568

From jbhateja at openjdk.org  Thu Feb 19 11:57:56 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 19 Feb 2026 11:57:56 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v24]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <p-tbUvrng5adI82e781GsExiHEga7MQz21qumshXDYk=.0c4f7aaf-99dc-4139-9ca6-eeaf3362fc9d@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  More cleanups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28002/files
  - new: https://git.openjdk.org/jdk/pull/28002/files/e1e0a31e..a714f549

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=22-23

  Stats: 1373 lines in 85 files changed: 74 ins; 894 del; 405 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

PR: https://git.openjdk.org/jdk/pull/28002

From jbhateja at openjdk.org  Thu Feb 19 12:02:27 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 19 Feb 2026 12:02:27 GMT
Subject: RFR: 8377438: [VectorAPI] Add new carrier type to LaneType class
 [v2]
In-Reply-To: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
References: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
Message-ID: <qmSybXnaUH8CxOjqOJwhdINd_GhiWX6OlG8ABL1GScE=.fe7f9703-d35a-475f-9e85-ed9063f3648d@github.com>

> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
> 
> With Float16 we need to differentiate b/w vector lane element type and carrier type. while element type corresponds to exact type of lane i.e. Float16.class, carrier type corresponds to the storage type required to propagate IEEE 754 float16 values to inline expander.
> 
> Patch adds a new carrier type to existing LaneType structure and use it for following purpose.
>  - To compute preferred shape of vector.
>  - To allocate vector backing storage during dummy vector and iota array creation.
>  - Sanity checking to ensure vector lane type is a primitive type in inline expander.
> 
> All existing Vector API jtreg test are passing with the patch.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8377438
 - 8377438: [VectorAPI] Add new carrier type to LaneType class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29629/files
  - new: https://git.openjdk.org/jdk/pull/29629/files/f7d4c531..91889b08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29629&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29629&range=00-01

  Stats: 489709 lines in 750 files changed: 248115 ins; 237236 del; 4358 mod
  Patch: https://git.openjdk.org/jdk/pull/29629.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29629/head:pull/29629

PR: https://git.openjdk.org/jdk/pull/29629

From alanb at openjdk.org  Thu Feb 19 12:47:36 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 19 Feb 2026 12:47:36 GMT
Subject: RFR: 8364182: Add jcmd VM.security_properties command [v10]
In-Reply-To: <DGMAFcDuMY0hlGc95-a9k1QKcrXwgkzRbr7em84hW5Q=.010ceced-66f0-468d-9da3-77f63f470dcb@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <2CAJOB43ZWZnLTLumQsG3F9K2hRqUzpgBzZ11HKHUI8=.abd8949e-aeb5-4cb5-b8ef-c8ff918ecbb3@github.com>
 <FvH_Q75DYNEqKwSs2ITG1-VGUJGe0D5HFh13nZ4W_zU=.e5ca3b05-da37-4c38-b596-e1208693a6a4@github.com>
 <DGMAFcDuMY0hlGc95-a9k1QKcrXwgkzRbr7em84hW5Q=.010ceced-66f0-468d-9da3-77f63f470dcb@github.com>
Message-ID: <X4xEMXMiATMyjJ-CAG96G2iN5KrcUYSSiBbUjAf4MUA=.4cac305e-0e43-4d48-8321-de6bb6902360@github.com>

On Thu, 19 Feb 2026 10:25:57 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> but is that policy/advice/preference...?

There is ongoing effort to migrate the existing TestNG tests to JUnit. So I think the general advice is to try to avoid introducing new TestNG tests if possible, start out with JUnit for tests that need a test framework.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2827661983

From rgiulietti at openjdk.org  Thu Feb 19 12:48:40 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 19 Feb 2026 12:48:40 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java
In-Reply-To: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
Message-ID: <-IYdIUoWqZJ_SVIFHVdMrCZCGw0ASylmyG5dq9czZk4=.694710b7-21c7-4aa6-b87b-83696a37249d@github.com>

On Wed, 18 Feb 2026 10:10:31 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM atanh method.

src/java.base/share/classes/java/lang/FdLibm.java line 3623:

> 3621:      *                   := 0.5 * log1p(2x + 2x * x/(1 - x)), if |x| < 0.5.
> 3622:      *
> 3623:      *

Not sure how useful this is in the context here.

src/java.base/share/classes/java/lang/FdLibm.java line 3638:

> 3636:             double t;
> 3637:             int hx,ix;
> 3638:             /*unsigned*/ int lx;

Suggestion:

            int lx;  // unsigned

src/java.base/share/classes/java/lang/FdLibm.java line 3642:

> 3640:             lx = __LO(x);                                        /* low word */
> 3641:             ix = hx & 0x7fff_ffff;
> 3642:             if ((ix | ((lx | (-lx)) >> 31)) > 0x3ff0_0000) {     /* |x| > 1 */

Hmm, since `lx` is unsigned this should really be
Suggestion:

            if ((ix | ((lx | (-lx)) >>> 31)) > 0x3ff0_0000) {     /* |x| > 1 */

The tests didn't reveal this bug, so I suggest adding some test cases for this, if feasible.

src/java.base/share/classes/java/lang/FdLibm.java line 3654:

> 3652:             if (ix < 0x3fe0_0000) {                              /* x < 0.5 */
> 3653:                 t = x + x;
> 3654:                 t = 0.5 * Log1p.compute(t + t*x/(one - x));

Suggestion:

                t = 0.5 * Log1p.compute(t + t * x / (one - x));

src/java.base/share/classes/java/lang/FdLibm.java line 3656:

> 3654:                 t = 0.5 * Log1p.compute(t + t*x/(one - x));
> 3655:             } else
> 3656:                 t = 0.5 * Log1p.compute((x + x)/(one - x));

Suggestion:

                t = 0.5 * Log1p.compute((x + x) / (one - x));

test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 2880:

> 2878:             lx = __LO(x);       /* low word */
> 2879:             ix = hx&0x7fffffff;
> 2880:             if ((ix|((lx|(-lx))>>31))>0x3ff00000) /* |x|>1 */

As above,
Suggestion:

            if ((ix|((lx|(-lx))>>>31))>0x3ff00000) /* |x|>1 */

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2827658243
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2827658821
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2827659802
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2827660221
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2827660365
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2827665306

From rgiulietti at openjdk.org  Thu Feb 19 12:48:44 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 19 Feb 2026 12:48:44 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java
In-Reply-To: <reSM05NJDI2LN40wIbCsKIfw_BCtxxnEJbHr4ebgFaI=.3924f64e-dd53-4ad7-937c-2a8d23d5ebf9@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
 <Lwtm5OFKuLIowYMl70IddacLjMRAiwb9vUThSD7vVYk=.ef05b6c8-5fd2-46d3-807f-6f4d419b6dbb@github.com>
 <reSM05NJDI2LN40wIbCsKIfw_BCtxxnEJbHr4ebgFaI=.3924f64e-dd53-4ad7-937c-2a8d23d5ebf9@github.com>
Message-ID: <jKgsRxjTuEu86prJVcE5E73s5EWyzaCFeC9GXaf4bTg=.bd76fc99-32b7-4ce3-bd3d-34a83fa7c280@github.com>

On Thu, 19 Feb 2026 10:10:43 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/FdLibm.java line 3631:
>> 
>>> 3629:      */
>>> 3630:     static final class Atanh {
>>> 3631:         private static final double zero = 0.0;
>> 
>> Earlier refactorings over Fdlibm.java removed use of "zero" and "one" in favor of having those literals in-line (JDK-8304423, etc). I think that would be a good convention to follow here as support for the new method is introduced.
>
> Sure, addressed.

I think what Joe means here is "inlining" these value in the code.

>> src/java.base/share/classes/java/lang/FdLibm.java line 3639:
>> 
>>> 3637:             int hx,ix;
>>> 3638:             /*unsigned*/ int lx;
>>> 3639:             hx = __HI(x);                                        /* high word */
>> 
>> Nit: I'd prefer "//" style comments for the one-liners here.
>
> Addressed.

Suggestion:

            hx = __HI(x);                                        // high word

etc.

>> src/java.base/share/classes/java/lang/FdLibm.java line 3657:
>> 
>>> 3655:             } else
>>> 3656:                 t = 0.5 * Log1p.compute((x + x)/(one - x));
>>> 3657:             if (hx >= 0) {
>> 
>> Please consider some smaller-vertical space idiom for this, like a use of the ?: construct, etc.
>
> Addressed.

??? It's still an `if`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2827658510
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2827659415
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2827660928

From aartemov at openjdk.org  Thu Feb 19 13:06:30 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 19 Feb 2026 13:06:30 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java
In-Reply-To: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
Message-ID: <OVc81ixusPrhdBmbW2sA6o4v9IqD9B2Wm9p_MYD8tbk=.2d7b324b-01ca-40bb-95eb-a7ddb99d5322@github.com>

On Wed, 18 Feb 2026 10:10:31 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM atanh method.

There is apparently a github bug, the PR does not see updates on the  branch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29782#issuecomment-3927166636

From aartemov at openjdk.org  Thu Feb 19 13:26:19 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 19 Feb 2026 13:26:19 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java [v2]
In-Reply-To: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
Message-ID: <t9LvwxE6KkR_NnyxWKhHVnCzp4fYWIOGEiMkUvtfRgs=.41bdec4a-26bf-468e-b7d8-a98794bb6963@github.com>

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM atanh method.

Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:

 - Empty commit.
 - 8377223: Addressed reviewers' comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29782/files
  - new: https://git.openjdk.org/jdk/pull/29782/files/b7183e72..6fea8fad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29782&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29782&range=00-01

  Stats: 20 lines in 2 files changed: 1 ins; 7 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/29782.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29782/head:pull/29782

PR: https://git.openjdk.org/jdk/pull/29782

From aartemov at openjdk.org  Thu Feb 19 13:58:22 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 19 Feb 2026 13:58:22 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java [v3]
In-Reply-To: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
Message-ID: <RSh5OV5y79TfwrMAXCqt-rjJmSwlb7XT_NZ2VKaNxpk=.3700af5a-7e4e-4199-82bc-29f3db441075@github.com>

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM atanh method.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8377223: Addressed reviewer's comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29782/files
  - new: https://git.openjdk.org/jdk/pull/29782/files/6fea8fad..0d480b96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29782&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29782&range=01-02

  Stats: 7 lines in 4 files changed: 2 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/29782.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29782/head:pull/29782

PR: https://git.openjdk.org/jdk/pull/29782

From aartemov at openjdk.org  Thu Feb 19 13:58:28 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 19 Feb 2026 13:58:28 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java [v3]
In-Reply-To: <jKgsRxjTuEu86prJVcE5E73s5EWyzaCFeC9GXaf4bTg=.bd76fc99-32b7-4ce3-bd3d-34a83fa7c280@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
 <Lwtm5OFKuLIowYMl70IddacLjMRAiwb9vUThSD7vVYk=.ef05b6c8-5fd2-46d3-807f-6f4d419b6dbb@github.com>
 <reSM05NJDI2LN40wIbCsKIfw_BCtxxnEJbHr4ebgFaI=.3924f64e-dd53-4ad7-937c-2a8d23d5ebf9@github.com>
 <jKgsRxjTuEu86prJVcE5E73s5EWyzaCFeC9GXaf4bTg=.bd76fc99-32b7-4ce3-bd3d-34a83fa7c280@github.com>
Message-ID: <bPwQyx8cY7LeK6xWjL9X341ylQuH9XqLijDqJb5ATeg=.a3d75806-e8d7-4bb6-8f4b-a7027b8db43a@github.com>

On Thu, 19 Feb 2026 12:43:50 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Sure, addressed.
>
> I think what Joe means here is "inlining" these value in the code.

I did the inlining, that commit did not show up on the PR due to some GH bug.

>> Addressed.
>
> Suggestion:
> 
>             hx = __HI(x);                                        // high word
> 
> etc.

Done.

>> Addressed.
>
> ??? It's still an `if`

A GH bug did not show the latest commit in the PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2828035947
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2828035095
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2828032845

From aartemov at openjdk.org  Thu Feb 19 13:58:27 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 19 Feb 2026 13:58:27 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java [v3]
In-Reply-To: <-IYdIUoWqZJ_SVIFHVdMrCZCGw0ASylmyG5dq9czZk4=.694710b7-21c7-4aa6-b87b-83696a37249d@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
 <-IYdIUoWqZJ_SVIFHVdMrCZCGw0ASylmyG5dq9czZk4=.694710b7-21c7-4aa6-b87b-83696a37249d@github.com>
Message-ID: <J558vyRx21rBcOld6p8ukj0VJOfWs9Ml5doQ9XqNFtY=.d5024a85-21af-4c7a-8c32-91fa4cc25e57@github.com>

On Thu, 19 Feb 2026 12:43:47 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8377223: Addressed reviewer's comments.
>
> src/java.base/share/classes/java/lang/FdLibm.java line 3623:
> 
>> 3621:      *                   := 0.5 * log1p(2x + 2x * x/(1 - x)), if |x| < 0.5.
>> 3622:      *
>> 3623:      *
> 
> Not sure how useful this is in the context here.

Are you concerned about wasted space or anything else?

> src/java.base/share/classes/java/lang/FdLibm.java line 3638:
> 
>> 3636:             double t;
>> 3637:             int hx,ix;
>> 3638:             /*unsigned*/ int lx;
> 
> Suggestion:
> 
>             int lx;  // unsigned

Done.

> src/java.base/share/classes/java/lang/FdLibm.java line 3642:
> 
>> 3640:             lx = __LO(x);                                        /* low word */
>> 3641:             ix = hx & 0x7fff_ffff;
>> 3642:             if ((ix | ((lx | (-lx)) >> 31)) > 0x3ff0_0000) {     /* |x| > 1 */
> 
> Hmm, since `lx` is unsigned this should really be
> Suggestion:
> 
>             if ((ix | ((lx | (-lx)) >>> 31)) > 0x3ff0_0000) {     /* |x| > 1 */
> 
> The tests didn't reveal this bug, so I suggest adding some test cases for this, if feasible.

Addressed. Added two test cases to handle value larger than 1 in abs value.

> src/java.base/share/classes/java/lang/FdLibm.java line 3654:
> 
>> 3652:             if (ix < 0x3fe0_0000) {                              /* x < 0.5 */
>> 3653:                 t = x + x;
>> 3654:                 t = 0.5 * Log1p.compute(t + t*x/(one - x));
> 
> Suggestion:
> 
>                 t = 0.5 * Log1p.compute(t + t * x / (one - x));

Addressed.

> src/java.base/share/classes/java/lang/FdLibm.java line 3656:
> 
>> 3654:                 t = 0.5 * Log1p.compute(t + t*x/(one - x));
>> 3655:             } else
>> 3656:                 t = 0.5 * Log1p.compute((x + x)/(one - x));
> 
> Suggestion:
> 
>                 t = 0.5 * Log1p.compute((x + x) / (one - x));

Addressed.

> test/jdk/java/lang/StrictMath/FdlibmTranslit.java line 2880:
> 
>> 2878:             lx = __LO(x);       /* low word */
>> 2879:             ix = hx&0x7fffffff;
>> 2880:             if ((ix|((lx|(-lx))>>31))>0x3ff00000) /* |x|>1 */
> 
> As above,
> Suggestion:
> 
>             if ((ix|((lx|(-lx))>>>31))>0x3ff00000) /* |x|>1 */

Addressed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2828038536
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2828035514
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2828034651
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2828034096
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2828033519
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2828032140

From rgiulietti at openjdk.org  Thu Feb 19 14:12:30 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 19 Feb 2026 14:12:30 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java [v3]
In-Reply-To: <J558vyRx21rBcOld6p8ukj0VJOfWs9Ml5doQ9XqNFtY=.d5024a85-21af-4c7a-8c32-91fa4cc25e57@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
 <-IYdIUoWqZJ_SVIFHVdMrCZCGw0ASylmyG5dq9czZk4=.694710b7-21c7-4aa6-b87b-83696a37249d@github.com>
 <J558vyRx21rBcOld6p8ukj0VJOfWs9Ml5doQ9XqNFtY=.d5024a85-21af-4c7a-8c32-91fa4cc25e57@github.com>
Message-ID: <tnrUi3rDhZ8ZE_CfP2h-j_AiL253bc-n3UkGOJPYN-0=.efb9d0e2-e569-4fc5-af03-11b8be153f00@github.com>

On Thu, 19 Feb 2026 13:54:55 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/FdLibm.java line 3623:
>> 
>>> 3621:      *                   := 0.5 * log1p(2x + 2x * x/(1 - x)), if |x| < 0.5.
>>> 3622:      *
>>> 3623:      *
>> 
>> Not sure how useful this is in the context here.
>
> Are you concerned about wasted space or anything else?

I had the impression that the comment was unrelated to the code, but on closer look I see it is relevant.
Never mind.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2828100960

From kevinw at openjdk.org  Thu Feb 19 14:21:37 2026
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 19 Feb 2026 14:21:37 GMT
Subject: RFR: 8364182: Add jcmd VM.security_properties command [v10]
In-Reply-To: <X4xEMXMiATMyjJ-CAG96G2iN5KrcUYSSiBbUjAf4MUA=.4cac305e-0e43-4d48-8321-de6bb6902360@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <2CAJOB43ZWZnLTLumQsG3F9K2hRqUzpgBzZ11HKHUI8=.abd8949e-aeb5-4cb5-b8ef-c8ff918ecbb3@github.com>
 <FvH_Q75DYNEqKwSs2ITG1-VGUJGe0D5HFh13nZ4W_zU=.e5ca3b05-da37-4c38-b596-e1208693a6a4@github.com>
 <DGMAFcDuMY0hlGc95-a9k1QKcrXwgkzRbr7em84hW5Q=.010ceced-66f0-468d-9da3-77f63f470dcb@github.com>
 <X4xEMXMiATMyjJ-CAG96G2iN5KrcUYSSiBbUjAf4MUA=.4cac305e-0e43-4d48-8321-de6bb6902360@github.com>
Message-ID: <2AtdYHY6Vj16M5bes-bk8hm19j89ULy3GBfJeSz-Ylk=.a540c24c-3e5f-4cc9-b229-740a6aadcdb8@github.com>

On Thu, 19 Feb 2026 12:44:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The existing dcmd tests are testng so understandable to duplicate that.
>> 
>> @AlanBateman  Alan added some JUnit tests in this area for the virtual thread tests, but is that policy/advice/preference...?
>
>> but is that policy/advice/preference...?
> 
> There is ongoing effort to migrate the existing TestNG tests to JUnit. So I think the general advice is to try to avoid introducing new TestNG tests if possible, start out with JUnit for tests that need a test framework.

Thanks -- I think this is a libs/hotspot crossover area where that migration is not well known.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2828160122

From liach at openjdk.org  Thu Feb 19 14:23:57 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Feb 2026 14:23:57 GMT
Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps [v2]
In-Reply-To: <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
References: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
 <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
Message-ID: <rnT0nL2ejOyUj3OloHa93O3-f9S0mQBYdPyJu_7LdrQ=.4fd44501-38a9-40f5-9ece-089586e017fc@github.com>

On Thu, 19 Feb 2026 09:35:00 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps.
>> 
>> Two interesting parts:
>> 
>> 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators.
>> 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps.
>
> Oli Gillespie 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 copyright
>  - Merge remote-tracking branch 'origin/master' into spliterator-test
>  - Switch to Objects.requireNonNull
>  - Add tests and fix impl

Thanks for the update. For the release note, I recommend emulating https://bugs.openjdk.org/browse/JDK-8371963: you should describe the specified behavior of NPE for Spliterator and Stream: https://github.com/openjdk/jdk/blob/bea48b54e2f423693e1e472129a86b030baf9eee/src/java.base/share/classes/java/util/stream/Stream.java#L123-L127

and describe the behaviors before (returns false; completes normally) and after the fix (NPE)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29485#issuecomment-3927600171

From rgiulietti at openjdk.org  Thu Feb 19 14:34:03 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 19 Feb 2026 14:34:03 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java [v3]
In-Reply-To: <RSh5OV5y79TfwrMAXCqt-rjJmSwlb7XT_NZ2VKaNxpk=.3700af5a-7e4e-4199-82bc-29f3db441075@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
 <RSh5OV5y79TfwrMAXCqt-rjJmSwlb7XT_NZ2VKaNxpk=.3700af5a-7e4e-4199-82bc-29f3db441075@github.com>
Message-ID: <yruKKBpHoxw7s6GgCDD7MI79oqQvHPsrwgPdALaru8I=.da846824-ba9a-40ab-8a55-5b9cecd18126@github.com>

On Thu, 19 Feb 2026 13:58:22 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM atanh method.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8377223: Addressed reviewer's comments.

test/jdk/java/lang/Math/HyperbolicTests.java line 2193:

> 2191:         };
> 2192: 
> 2193:         for(int i = 0; i < testCases.length; i++) {

Please make use of "enhanced for loops" whenever possible.

test/jdk/java/lang/Math/HyperbolicTests.java line 2213:

> 2211:         };
> 2212: 
> 2213:         for(int i = 0; i < specialTestCases.length; i++) {

Same here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2828218974
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2828219362

From ogillespie at openjdk.org  Thu Feb 19 14:36:19 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Thu, 19 Feb 2026 14:36:19 GMT
Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps [v2]
In-Reply-To: <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
References: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
 <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
Message-ID: <S23RQ6G140hbGzWwxd9-NktoKTNSFB7YSwSNTxpZ3bs=.88dd0bd9-564a-4832-9899-5f61aa4e6ec7@github.com>

On Thu, 19 Feb 2026 09:35:00 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps.
>> 
>> Two interesting parts:
>> 
>> 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators.
>> 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps.
>
> Oli Gillespie 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 copyright
>  - Merge remote-tracking branch 'origin/master' into spliterator-test
>  - Switch to Objects.requireNonNull
>  - Add tests and fix impl

Thanks. Updated release note to:

> `Stream.forEach(Consumer<? super T> action)`, `Spliterator.forEachRemaining(Consumer<? super T> action)` and `Spliterator.tryAdvance(Consumer<? super T> action)` specify they throw `NullPointerException` if their argument is `null`. In prior releases, implementations of `Spliterator` and `Stream` for subsets of `TreeMap` and `TreeSet` did not throw `NullPointerException` when passed a null action if the subset was empty. These methods now throw `NullPointerException` when passed a null action for an empty subset instead of returning `false` or completing normally. 

What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29485#issuecomment-3927673153

From liach at openjdk.org  Thu Feb 19 14:44:38 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Feb 2026 14:44:38 GMT
Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps [v2]
In-Reply-To: <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
References: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
 <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
Message-ID: <b6UDbvZhg0YkCtrIy9IkCzmqcslfcj57UGMGpzp8z6w=.9869bc67-5808-417a-b142-c345a0055a02@github.com>

On Thu, 19 Feb 2026 09:35:00 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps.
>> 
>> Two interesting parts:
>> 
>> 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators.
>> 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps.
>
> Oli Gillespie 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 copyright
>  - Merge remote-tracking branch 'origin/master' into spliterator-test
>  - Switch to Objects.requireNonNull
>  - Add tests and fix impl

The copyright year update and release note update look good to me.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29485#pullrequestreview-3826335209

From aartemov at openjdk.org  Thu Feb 19 15:13:25 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 19 Feb 2026 15:13:25 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java [v4]
In-Reply-To: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
Message-ID: <eWcxFW9oX7zEwy1iLiXCyfES6ElNOfyCo81ptNpORWQ=.94bb1358-1484-472d-8009-707b64a00e54@github.com>

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM atanh method.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8377223: Addressed reviewer's comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29782/files
  - new: https://git.openjdk.org/jdk/pull/29782/files/0d480b96..e3cfea68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29782&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29782&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/29782.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29782/head:pull/29782

PR: https://git.openjdk.org/jdk/pull/29782

From aartemov at openjdk.org  Thu Feb 19 15:13:29 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 19 Feb 2026 15:13:29 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java [v3]
In-Reply-To: <yruKKBpHoxw7s6GgCDD7MI79oqQvHPsrwgPdALaru8I=.da846824-ba9a-40ab-8a55-5b9cecd18126@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
 <RSh5OV5y79TfwrMAXCqt-rjJmSwlb7XT_NZ2VKaNxpk=.3700af5a-7e4e-4199-82bc-29f3db441075@github.com>
 <yruKKBpHoxw7s6GgCDD7MI79oqQvHPsrwgPdALaru8I=.da846824-ba9a-40ab-8a55-5b9cecd18126@github.com>
Message-ID: <ub0Hmb83Rm8tpFE_MLtPqIgE050wppLNPC175kjIbfs=.8a7df9f5-c85b-4bd5-a36b-e4684371810b@github.com>

On Thu, 19 Feb 2026 14:30:08 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8377223: Addressed reviewer's comments.
>
> test/jdk/java/lang/Math/HyperbolicTests.java line 2193:
> 
>> 2191:         };
>> 2192: 
>> 2193:         for(int i = 0; i < testCases.length; i++) {
> 
> Please make use of "enhanced for loops" whenever possible.

Noted!

> test/jdk/java/lang/Math/HyperbolicTests.java line 2213:
> 
>> 2211:         };
>> 2212: 
>> 2213:         for(int i = 0; i < specialTestCases.length; i++) {
> 
> Same here.

Noted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2828429213
PR Review Comment: https://git.openjdk.org/jdk/pull/29782#discussion_r2828429447

From rgiulietti at openjdk.org  Thu Feb 19 15:22:28 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 19 Feb 2026 15:22:28 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java [v4]
In-Reply-To: <eWcxFW9oX7zEwy1iLiXCyfES6ElNOfyCo81ptNpORWQ=.94bb1358-1484-472d-8009-707b64a00e54@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
 <eWcxFW9oX7zEwy1iLiXCyfES6ElNOfyCo81ptNpORWQ=.94bb1358-1484-472d-8009-707b64a00e54@github.com>
Message-ID: <UW-JQzt91OZBhv4J0zm6opo_jcARanspdcXeBQ3fczk=.36fe1b5d-2495-4310-85c4-89ec632ab1d0@github.com>

On Thu, 19 Feb 2026 15:13:25 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM atanh method.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8377223: Addressed reviewer's comments.

Looks good to me, except for my comment in the [CSR](https://bugs.openjdk.org/browse/JDK-8378161).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29782#issuecomment-3927940028

From aartemov at openjdk.org  Thu Feb 19 15:37:37 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 19 Feb 2026 15:37:37 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java [v5]
In-Reply-To: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
Message-ID: <RhMYZu_Qi3DE0CPcAzg5r-4JFSOcwSBuI8kLlbIn_SQ=.cc3532fa-7e4c-4a45-a90f-57d707e93c54@github.com>

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM atanh method.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8377223: Added case |x| > to docs.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29782/files
  - new: https://git.openjdk.org/jdk/pull/29782/files/e3cfea68..815ce7d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29782&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29782&range=03-04

  Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29782.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29782/head:pull/29782

PR: https://git.openjdk.org/jdk/pull/29782

From aartemov at openjdk.org  Thu Feb 19 15:37:38 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 19 Feb 2026 15:37:38 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java [v4]
In-Reply-To: <UW-JQzt91OZBhv4J0zm6opo_jcARanspdcXeBQ3fczk=.36fe1b5d-2495-4310-85c4-89ec632ab1d0@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
 <eWcxFW9oX7zEwy1iLiXCyfES6ElNOfyCo81ptNpORWQ=.94bb1358-1484-472d-8009-707b64a00e54@github.com>
 <UW-JQzt91OZBhv4J0zm6opo_jcARanspdcXeBQ3fczk=.36fe1b5d-2495-4310-85c4-89ec632ab1d0@github.com>
Message-ID: <0vjqIJ0h5vl85tDPArpd6IcnT7jVGAmhZD1cfGlsMcg=.6e73f0df-6c17-4b5b-9c5a-b643b2535954@github.com>

On Thu, 19 Feb 2026 15:19:27 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Looks good to me, except for my comment in the [CSR](https://bugs.openjdk.org/browse/JDK-8378161).

Thanks, I added the missing case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29782#issuecomment-3928027911

From rgiulietti at openjdk.org  Thu Feb 19 15:45:05 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 19 Feb 2026 15:45:05 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java [v5]
In-Reply-To: <RhMYZu_Qi3DE0CPcAzg5r-4JFSOcwSBuI8kLlbIn_SQ=.cc3532fa-7e4c-4a45-a90f-57d707e93c54@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
 <RhMYZu_Qi3DE0CPcAzg5r-4JFSOcwSBuI8kLlbIn_SQ=.cc3532fa-7e4c-4a45-a90f-57d707e93c54@github.com>
Message-ID: <tk03mqVkMlvV3ORcctqXte5fqxcAQtmjmrYZoU1lny0=.39b6a137-33a0-48ee-a2ac-ce789ab537e6@github.com>

On Thu, 19 Feb 2026 15:37:37 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM atanh method.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8377223: Added case |x| > to docs.

Good.
I'll approve once the CSR is approved as well.
Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29782#issuecomment-3928091699

From sspitsyn at openjdk.org  Thu Feb 19 15:52:51 2026
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Feb 2026 15:52:51 GMT
Subject: RFR: 8377729: Running jtreg tests with -agent... option causes
 some tests to fail due to duplicate -agent options provided to a subprocess
 [v2]
In-Reply-To: <VfYMw1R5GJvQB43PPP-mQbBwQFAbRugPcsrAZEVYFik=.5c67dd1c-0523-4ba4-98c7-5986eaff2123@github.com>
References: <Xx7VPlNQy-Svo7fkKo71gYLrSJ4nTxyyGnwEpXyfeyQ=.4cdbed9d-b09c-4c74-8a0e-1c27e620a825@github.com>
 <VfYMw1R5GJvQB43PPP-mQbBwQFAbRugPcsrAZEVYFik=.5c67dd1c-0523-4ba4-98c7-5986eaff2123@github.com>
Message-ID: <kz27eHh9aXLtLogZh2yBfIO4hv6-HrNwHyhIagijLjo=.b41934ee-af7c-4c38-9b52-10726295207f@github.com>

On Sat, 14 Feb 2026 02:37:25 GMT, Kirill Shirokov <kshiroko at openjdk.org> wrote:

>> The fix removes duplicate `-agent...` and `-javaagent:...` options from test subprocess command line, thus allowing to run jtreg tests with agents that should be specified only once.
>> 
>> The fix tested manually:
>> 
>> 
>> $ make test JTREG="VERBOSE=summary,fail,error" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>>    jtreg:test/jdk/sun/tools/jstack/DeadlockDetectionTest.java
>>                                                          1     1     0     0     0
>>    jtreg:test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java
>>                                                          1     1     0     0     0
>>    jtreg:test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java
>>                                                          1     1     0     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> $ make test JTREG="VERBOSE=summary,fail,error;JAVA_OPTIONS=-agentpath.../async-profiler-binaries/lib/libasyncProfiler.dylib=start,event=cpu,cstack=vm,loglevel=none,flat,file=/dev/null" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>>    jtreg:test/jdk/sun/tools/jstack/DeadlockDetectionTest.java
>>>>                                                       1     0     1     0     0 <<
>>    jtreg:test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java
>>>>                                                       1     0     1     0     0 <<
>>    jtreg:test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java
>>>>                                                       1     0     1     0     0 <<
>> ==============================
>> TEST FAILURE
>> 
>> $ make test JTREG="VERBOSE=summary,fail,error;VM_OPTIONS=-agentpath:.../async-profiler-binaries/lib/libasyncProfiler.dylib=start,event=cpu,cstack=vm,loglevel=none,flat,file=/dev/null" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/...
>
> Kirill Shirokov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailing whitespace
>  - Removed duplicate VM options from test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java, test/jdk/sun/tools/jstack/DeadlockDetectionTest.java, test/lib/jdk/test/lib/apps/LingeredApp.java, test/lib/jdk/test/lib/cli/CommandLineOptionTest.java. Added duplicate agent options warning to ProcessTools-spawned subprocesses and LingeredApp

Looks good.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29684#pullrequestreview-3826760812

From lancea at openjdk.org  Thu Feb 19 16:07:19 2026
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 19 Feb 2026 16:07:19 GMT
Subject: RFR: 8377992: (zipfs) Align ZipFileSystem END header validation
 with the ZipFile implementation
In-Reply-To: <1tONCY1QoXxaeUtr3LE4YoZk0UitQ5NqadNJOPFjREQ=.9b237170-fb07-4713-82fb-26b968b268de@github.com>
References: <1tONCY1QoXxaeUtr3LE4YoZk0UitQ5NqadNJOPFjREQ=.9b237170-fb07-4713-82fb-26b968b268de@github.com>
Message-ID: <D0ElCO-GqVznv349iKhD2RAXsl8VTlRW5bW6pL_LvR8=.a1cad3bf-f675-4ec6-8f4d-ff251e5ffd91@github.com>

On Mon, 16 Feb 2026 15:15:28 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`.
> 
> This brings two validation checks over to `ZipFileSystem`:
> 
> * Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746)
> * Rejection of END headers with a total entry count which cannot fit within the CEN byte array  (JDK-8341625)
> 
> The test `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is updated to to verify that ZIP files  rejected by the `ZipFile` constructor are now also rejected by `ZipFileSystem.newFileSystem`.
> 
> Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries.  Similar adjustments to `ZipFile` was done in JDK-8341625.
> 
> `ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`.

Hi Eirik,

Thank you for your efforts here and overall the changes to ZipFile and ZipFS are fine.

WRT the test, it is preferable that the ZipFS tests are added to open/test/jdk/jdk/nio/zipfs for now so that we have the specific tests co-located.

At some point we may want to revisit our structure for zip and zipfs tests bu that would be separate from this PR

-------------

PR Review: https://git.openjdk.org/jdk/pull/29747#pullrequestreview-3826848135

From lancea at openjdk.org  Thu Feb 19 16:11:56 2026
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 19 Feb 2026 16:11:56 GMT
Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile
 [v3]
In-Reply-To: <FNI7hOi3rFtcJBqAq-YmTmue8fJA7Qfm58btrfAUfAg=.4cd59c00-404a-45e7-9ee4-886d372bd8f4@github.com>
References: <QDvNIqpJBwz2AByfzrrgSs8tKMYI2JpTTkP6M_qoAyc=.9ac31c22-9c76-4bf8-8664-d075caf70ae0@github.com>
 <FNI7hOi3rFtcJBqAq-YmTmue8fJA7Qfm58btrfAUfAg=.4cd59c00-404a-45e7-9ee4-886d372bd8f4@github.com>
Message-ID: <sJbrr9I1a8hyPkYEKE9wSQxIbNwZk30yDVPc-IJm0QA=.cc39d52c-c01f-49aa-be18-052361f5e504@github.com>

On Tue, 27 Jan 2026 09:30:19 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Hot on the heals of #29288, this PR replaces `ArrayDeque` with `ArrayList` for the Inflater cache implementation in `ZipFile.CleanableResource`.
>> 
>> With this PR, we change the order of the cache from a LIFO queue to a FIFO stack backed by ArrayList. The order seems unimportant, and has indeed been FIFO in the past when using `java.util.Vector`. Intuitively, it should be better to return the most recently used Inflater.
>> 
>> No tests updated, strict refactoring, `noreg-cleanup`.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove null check of final field istreams which is never null

I think this looks OK, thank you for the clean up Eirik

Please wait for a review from Jai or Alan before integrating

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29430#pullrequestreview-3826880742

From eirbjo at openjdk.org  Thu Feb 19 16:37:47 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 19 Feb 2026 16:37:47 GMT
Subject: RFR: 8377992: (zipfs) Align ZipFileSystem END header validation
 with the ZipFile implementation
In-Reply-To: <D0ElCO-GqVznv349iKhD2RAXsl8VTlRW5bW6pL_LvR8=.a1cad3bf-f675-4ec6-8f4d-ff251e5ffd91@github.com>
References: <1tONCY1QoXxaeUtr3LE4YoZk0UitQ5NqadNJOPFjREQ=.9b237170-fb07-4713-82fb-26b968b268de@github.com>
 <D0ElCO-GqVznv349iKhD2RAXsl8VTlRW5bW6pL_LvR8=.a1cad3bf-f675-4ec6-8f4d-ff251e5ffd91@github.com>
Message-ID: <Q7dGeA8XjfuzoIV4liyP7y_f-8iUhKvNA_UycWkdNLI=.d054a742-c99c-4427-b7e2-7ad97eeae244@github.com>

On Thu, 19 Feb 2026 16:04:34 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> WRT the test, it is preferable that the ZipFS tests are added to open/test/jdk/jdk/nio/zipfs for now so that we have the specific tests co-located.

The existing `EndOfCenValidation` test goes through  some heroic efforts to create ZIP/ZIP64 files under reasonable size and efficiency constraints that provokes these edge-cases being tested. 

The reason I opted to expand the existing test with support for verifying `ZipFileSystem` was based on the following observations:

* We want to ensure that validation for these cases is equivalent across APIs
* Co-locating them avoids duplication of good amounts of intricate setup of test vectors

Did you mean that we should copy this tests and maintain the copy separately in the `zipfs` area?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29747#issuecomment-3928397967

From kshiroko at openjdk.org  Thu Feb 19 16:39:12 2026
From: kshiroko at openjdk.org (Kirill Shirokov)
Date: Thu, 19 Feb 2026 16:39:12 GMT
Subject: Integrated: 8377729: Running jtreg tests with -agent... option causes
 some tests to fail due to duplicate -agent options provided to a
 subprocess
In-Reply-To: <Xx7VPlNQy-Svo7fkKo71gYLrSJ4nTxyyGnwEpXyfeyQ=.4cdbed9d-b09c-4c74-8a0e-1c27e620a825@github.com>
References: <Xx7VPlNQy-Svo7fkKo71gYLrSJ4nTxyyGnwEpXyfeyQ=.4cdbed9d-b09c-4c74-8a0e-1c27e620a825@github.com>
Message-ID: <ais0zpeMYyUfUQ-ttxsrs2Exad-k8VReiEJU7CP1VaU=.174e3846-6769-44a8-8bd1-41126b400f97@github.com>

On Thu, 12 Feb 2026 03:22:57 GMT, Kirill Shirokov <kshiroko at openjdk.org> wrote:

> The fix removes duplicate `-agent...` and `-javaagent:...` options from test subprocess command line, thus allowing to run jtreg tests with agents that should be specified only once.
> 
> The fix tested manually:
> 
> 
> $ make test JTREG="VERBOSE=summary,fail,error" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>    jtreg:test/jdk/sun/tools/jstack/DeadlockDetectionTest.java
>                                                          1     1     0     0     0
>    jtreg:test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java
>                                                          1     1     0     0     0
>    jtreg:test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java
>                                                          1     1     0     0     0
> ==============================
> TEST SUCCESS
> 
> $ make test JTREG="VERBOSE=summary,fail,error;JAVA_OPTIONS=-agentpath.../async-profiler-binaries/lib/libasyncProfiler.dylib=start,event=cpu,cstack=vm,loglevel=none,flat,file=/dev/null" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>    jtreg:test/jdk/sun/tools/jstack/DeadlockDetectionTest.java
>>>                                                       1     0     1     0     0 <<
>    jtreg:test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java
>>>                                                       1     0     1     0     0 <<
>    jtreg:test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java
>>>                                                       1     0     1     0     0 <<
> ==============================
> TEST FAILURE
> 
> $ make test JTREG="VERBOSE=summary,fail,error;VM_OPTIONS=-agentpath:.../async-profiler-binaries/lib/libasyncProfiler.dylib=start,event=cpu,cstack=vm,loglevel=none,flat,file=/dev/null" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java"
> 
> (same errors)
> 
> With th...

This pull request has now been integrated.

Changeset: f02d1900
Author:    Kirill Shirokov <kshiroko at openjdk.org>
Committer: Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f02d1900958ee705c4e86bc94b92f7c2cde39c0d
Stats:     40 lines in 5 files changed: 30 ins; 4 del; 6 mod

8377729: Running jtreg tests with -agent... option causes some tests to fail due to duplicate -agent options provided to a subprocess

Reviewed-by: lmesnik, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/29684

From lancea at openjdk.org  Thu Feb 19 17:14:42 2026
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 19 Feb 2026 17:14:42 GMT
Subject: RFR: 8377992: (zipfs) Align ZipFileSystem END header validation
 with the ZipFile implementation
In-Reply-To: <Q7dGeA8XjfuzoIV4liyP7y_f-8iUhKvNA_UycWkdNLI=.d054a742-c99c-4427-b7e2-7ad97eeae244@github.com>
References: <1tONCY1QoXxaeUtr3LE4YoZk0UitQ5NqadNJOPFjREQ=.9b237170-fb07-4713-82fb-26b968b268de@github.com>
 <D0ElCO-GqVznv349iKhD2RAXsl8VTlRW5bW6pL_LvR8=.a1cad3bf-f675-4ec6-8f4d-ff251e5ffd91@github.com>
 <Q7dGeA8XjfuzoIV4liyP7y_f-8iUhKvNA_UycWkdNLI=.d054a742-c99c-4427-b7e2-7ad97eeae244@github.com>
Message-ID: <e8XEz87ZcbP9-9t95Xn-zeuT3GvwmQvIM12hB3ZqOv0=.319e8408-3a4b-441b-b7c5-a0b2718c0fc5@github.com>

On Thu, 19 Feb 2026 16:34:55 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> > WRT the test, it is preferable that the ZipFS tests are added to open/test/jdk/jdk/nio/zipfs for now so that we have the specific tests co-located.
> 
> The existing `EndOfCenValidation` test goes through some heroic efforts to create ZIP/ZIP64 files under reasonable size and efficiency constraints that provokes these edge-cases being tested.
> 
> The reason I opted to expand the existing test with support for verifying `ZipFileSystem` was based on the following observations:
> 
> * We want to ensure that validation for these cases is equivalent across APIs
> * Co-locating them avoids duplication of good amounts of intricate setup of test vectors
> 
> Did you mean that we should copy this tests and maintain the copy separately in the `zipfs` area?

Understand WRT the zip creation logic.  It can be easy to miss specific tests if they are not included in the primary test directory as there are times for example that you might only to need to run  zipfs specific tests

So you could create a utility class which is shared by the ZipFile or ZipFs test or take the easier route of having a copy of the code in each directory.

I would probably error on the side of creating a utils directory and placing the specific shared code in a class there that is imported or extended...

I will defer to you on your preference though ;-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29747#issuecomment-3928618386

From darcy at openjdk.org  Thu Feb 19 17:21:27 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 19 Feb 2026 17:21:27 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java [v5]
In-Reply-To: <RhMYZu_Qi3DE0CPcAzg5r-4JFSOcwSBuI8kLlbIn_SQ=.cc3532fa-7e4c-4a45-a90f-57d707e93c54@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
 <RhMYZu_Qi3DE0CPcAzg5r-4JFSOcwSBuI8kLlbIn_SQ=.cc3532fa-7e4c-4a45-a90f-57d707e93c54@github.com>
Message-ID: <RqAkX1q8YcOpZkC949buYlZLEFraHcIZcP9c7CaS8E0=.3e490b39-5ba6-4c6e-9469-40f877546817@github.com>

On Thu, 19 Feb 2026 15:37:37 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM atanh method.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8377223: Added case |x| > to docs.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29782#pullrequestreview-3827288883

From rgiulietti at openjdk.org  Thu Feb 19 17:28:17 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 19 Feb 2026 17:28:17 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java [v5]
In-Reply-To: <RhMYZu_Qi3DE0CPcAzg5r-4JFSOcwSBuI8kLlbIn_SQ=.cc3532fa-7e4c-4a45-a90f-57d707e93c54@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
 <RhMYZu_Qi3DE0CPcAzg5r-4JFSOcwSBuI8kLlbIn_SQ=.cc3532fa-7e4c-4a45-a90f-57d707e93c54@github.com>
Message-ID: <XFZSR6NPnjQjgeZUZCRrwy_PIpZ_4uZeYjHghBLaYQw=.264c1a9b-d2a0-4051-8546-5a87f95e70e9@github.com>

On Thu, 19 Feb 2026 15:37:37 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM atanh method.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8377223: Added case |x| > to docs.

Marked as reviewed by rgiulietti (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29782#pullrequestreview-3827336254

From mullan at openjdk.org  Thu Feb 19 18:19:40 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 19 Feb 2026 18:19:40 GMT
Subject: RFR: 8377506: Implementation of PEM Encodings of Cryptographic
 Objects
In-Reply-To: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>
References: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>
Message-ID: <8NwtOTANsXitdebfCGr-aqv1C19aCBmHOAos8qdOhjM=.c2f5dc4b-d655-4a79-b872-3a66460fbd43@github.com>

On Mon, 9 Feb 2026 21:04:34 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524), include:
> 
> - `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied.
> - `DEREncodable` is renamed to `BinaryEncodable` to more accurately reflect the binary data stored in PEM text.
> - In `EncryptedPrivateKeyInfo`, the `encrypt` methods now accept `BinaryEncodable`, and the `getKey()` and `getKeyPair()` methods no longer include a `Provider` parameter.
> - A new `CryptoException` indicates failures during cryptographic processing at runtime.
> 
> thanks

src/java.base/share/classes/java/security/BinaryEncodable.java line 1:

> 1: /*

Is `import jdk.internal.javac.PreviewFeature` still needed on line 28?

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 1:

> 1: /*

update copyright date

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2829412160
PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2829160926

From eirbjo at openjdk.org  Thu Feb 19 18:37:21 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 19 Feb 2026 18:37:21 GMT
Subject: RFR: 8377992: (zipfs) Align ZipFileSystem END header validation
 with the ZipFile implementation
In-Reply-To: <e8XEz87ZcbP9-9t95Xn-zeuT3GvwmQvIM12hB3ZqOv0=.319e8408-3a4b-441b-b7c5-a0b2718c0fc5@github.com>
References: <1tONCY1QoXxaeUtr3LE4YoZk0UitQ5NqadNJOPFjREQ=.9b237170-fb07-4713-82fb-26b968b268de@github.com>
 <D0ElCO-GqVznv349iKhD2RAXsl8VTlRW5bW6pL_LvR8=.a1cad3bf-f675-4ec6-8f4d-ff251e5ffd91@github.com>
 <Q7dGeA8XjfuzoIV4liyP7y_f-8iUhKvNA_UycWkdNLI=.d054a742-c99c-4427-b7e2-7ad97eeae244@github.com>
 <e8XEz87ZcbP9-9t95Xn-zeuT3GvwmQvIM12hB3ZqOv0=.319e8408-3a4b-441b-b7c5-a0b2718c0fc5@github.com>
Message-ID: <0a3kHTQi3o-Pbc-YVWE2et8re4CmVKJ7BXrg2_v-SS8=.b52745f6-7527-4c71-963a-113f937fd666@github.com>

On Thu, 19 Feb 2026 17:12:23 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> So you could create a utility class which is shared by the ZipFile or ZipFs test or take the easier route of having a copy of the code in each directory.

I opted to extract the test vector setup and some shared constants into `jdk.test.lib.util.ZipUtils`. I retained a copyright year of 2023, 2026 for this one.

I then copied `EndOfCenValidation` to ZipFS. Some cleanups applied first, such as extracting the method `verifyRejection` to handle the repeated `assertThrows`, `assertEquals` checks.

While this does not eliminate duplication, it avoids it in the test vector setup which is were it would hurt the most.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29747#issuecomment-3929116938

From eirbjo at openjdk.org  Thu Feb 19 18:44:32 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 19 Feb 2026 18:44:32 GMT
Subject: RFR: 8377992: (zipfs) Align ZipFileSystem END header validation
 with the ZipFile implementation [v2]
In-Reply-To: <1tONCY1QoXxaeUtr3LE4YoZk0UitQ5NqadNJOPFjREQ=.9b237170-fb07-4713-82fb-26b968b268de@github.com>
References: <1tONCY1QoXxaeUtr3LE4YoZk0UitQ5NqadNJOPFjREQ=.9b237170-fb07-4713-82fb-26b968b268de@github.com>
Message-ID: <jbBil_B07PotomaIOfzb5ecf9BSBRGvN88-2I0NbIfk=.47162c2c-23df-4559-b12c-59f8b23846b1@github.com>

> Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`.
> 
> This brings two validation checks over to `ZipFileSystem`:
> 
> * Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746)
> * Rejection of END headers with a total entry count which cannot fit within the CEN byte array  (JDK-8341625)
> 
> The test `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is updated to to verify that ZIP files  rejected by the `ZipFile` constructor are now also rejected by `ZipFileSystem.newFileSystem`.
> 
> Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries.  Similar adjustments to `ZipFile` was done in JDK-8341625.
> 
> `ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`.

Eirik Bj?rsn?s has updated the pull request incrementally with three additional commits since the last revision:

 - Replace ZipFile reference in clas comment with ZipFileSystem
 - Remove spurious '*'
 - Extract test vector setup into ZipUtils class reusable across ZipFile/ZipFileSystem tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29747/files
  - new: https://git.openjdk.org/jdk/pull/29747/files/17b8a72c..d6fc0aee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29747&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29747&range=00-01

  Stats: 656 lines in 3 files changed: 417 ins; 221 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/29747.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29747/head:pull/29747

PR: https://git.openjdk.org/jdk/pull/29747

From mullan at openjdk.org  Thu Feb 19 20:03:41 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 19 Feb 2026 20:03:41 GMT
Subject: RFR: 8377506: Implementation of PEM Encodings of Cryptographic
 Objects
In-Reply-To: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>
References: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>
Message-ID: <_tWEasBTj3VrWyMFQRQufjYP4Taab22UesnMqKBiZPQ=.c69c723e-0e07-422c-ade4-0689524734d6@github.com>

On Mon, 9 Feb 2026 21:04:34 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524), include:
> 
> - `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied.
> - `DEREncodable` is renamed to `BinaryEncodable` to more accurately reflect the binary data stored in PEM text.
> - In `EncryptedPrivateKeyInfo`, the `encrypt` methods now accept `BinaryEncodable`, and the `getKey()` and `getKeyPair()` methods no longer include a `Provider` parameter.
> - A new `CryptoException` indicates failures during cryptographic processing at runtime.
> 
> thanks

src/java.base/share/classes/java/security/PEMEncoder.java line 163:

> 161:      * string.
> 162:      *
> 163:      * @param de the {@code BinaryEncodable} to encode

Change variable name to `be`.

src/java.base/share/classes/java/security/PEMEncoder.java line 260:

> 258:      * byte array.
> 259:      *
> 260:      * @param de the {@code BinaryEncodable} to be encoded

Change variable name to `be`.

src/java.base/share/classes/java/security/PEMEncoder.java line 279:

> 277:      * {@code PKCS8EncodedKeySpec} objects can be encoded with this newly
> 278:      * configured instance.  Encoding other {@code BinaryEncodable} objects will
> 279:      * throw an {@code PEMException}.

s/an/a/

src/java.base/share/classes/java/security/PEMEncoder.java line 327:

> 325: 
> 326:         if (key != null && privateEncoding == null) {
> 327:             throw new IllegalArgumentException("This BinaryEncodable cannot " +

Some exception messages end with a period, others don't. Probably should be consistent. I don't think it common to end exception messages with a period.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2829846441
PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2829865682
PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2829869191
PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2829881214

From jlu at openjdk.org  Thu Feb 19 20:27:17 2026
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Feb 2026 20:27:17 GMT
Subject: RFR: 8378111: Migrate java/util/jar tests to JUnit
Message-ID: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>

This PR migrates the java/util/jar tests to use _JUnit_.

https://github.com/openjdk/jdk/commit/afe0aeee746bccbbe4bc6c9a8cd2302228ecc2f6 includes changes for _testNG_ based tests.
https://github.com/openjdk/jdk/commit/c5a7f75840f96fa77ec3ed7faa713990adb84de6 includes changes for `main` based tests.

Before: Framework-based tests: 125 = 125 TestNG + 0 JUnit.
After: Framework-based tests: 174 = 0 TestNG + 174 JUnit

-------------

Commit messages:
 - main -> JUnit
 - TestNG -> JUnit

Changes: https://git.openjdk.org/jdk/pull/29828/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29828&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378111
  Stats: 917 lines in 33 files changed: 283 ins; 169 del; 465 mod
  Patch: https://git.openjdk.org/jdk/pull/29828.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29828/head:pull/29828

PR: https://git.openjdk.org/jdk/pull/29828

From aturbanov at openjdk.org  Thu Feb 19 20:52:03 2026
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 19 Feb 2026 20:52:03 GMT
Subject: RFR: 8378111: Migrate java/util/jar tests to JUnit
In-Reply-To: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
References: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
Message-ID: <rX5UUgHGLSJjJtWh-Zyz4AVIu7Jamdyma1OB-fMzS6A=.b3f2beef-6eac-48df-af67-143f40cf0dc1@github.com>

On Thu, 19 Feb 2026 20:18:17 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR migrates the java/util/jar tests to use _JUnit_.
> 
> https://github.com/openjdk/jdk/commit/afe0aeee746bccbbe4bc6c9a8cd2302228ecc2f6 includes changes for _testNG_ based tests.
> https://github.com/openjdk/jdk/commit/c5a7f75840f96fa77ec3ed7faa713990adb84de6 includes changes for `main` based tests.
> 
> Before: Framework-based tests: 125 = 125 TestNG + 0 JUnit.
> After: Framework-based tests: 174 = 0 TestNG + 174 JUnit

test/jdk/java/util/jar/JarFile/JarNoManifest.java line 42:

> 40:     @Test
> 41:     void absentManifestTest() throws IOException {
> 42:         File f = new File(System.getProperty("test.src","."), "no-manifest.jar");

Suggestion:

        File f = new File(System.getProperty("test.src", "."), "no-manifest.jar");

test/jdk/java/util/jar/JarFile/SorryClosed.java line 41:

> 39: public class SorryClosed {
> 40: 
> 41:     private static final File file = new File(System.getProperty("test.src","."), "test.jar");

Suggestion:

    private static final File file = new File(System.getProperty("test.src", "."), "test.jar");

test/jdk/java/util/jar/JarFile/TurkCert.java line 50:

> 48:     @Test
> 49:     void turkishLocaleTest() throws IOException {
> 50:         File f = new File(System.getProperty("test.src","."), "test.jar");

Suggestion:

        File f = new File(System.getProperty("test.src", "."), "test.jar");

test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java line 66:

> 64:     private static final Random RANDOM = RandomFactory.getRandom();
> 65: 
> 66:     private static final String userdir = System.getProperty("user.dir",".");

Suggestion:

    private static final String userdir = System.getProperty("user.dir", ".");

test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java line 67:

> 65: 
> 66:     private static final String userdir = System.getProperty("user.dir",".");
> 67:     private static final CreateMultiReleaseTestJars creator =  new CreateMultiReleaseTestJars();

Suggestion:

    private static final CreateMultiReleaseTestJars creator = new CreateMultiReleaseTestJars();

test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarSecurity.java line 56:

> 54:     static final int MAJOR_VERSION = Runtime.version().major();
> 55: 
> 56:     private static final String userdir = System.getProperty("user.dir",".");

Suggestion:

    private static final String userdir = System.getProperty("user.dir", ".");

test/jdk/java/util/jar/JarInputStream/TestIndexedJarWithBadSignature.java line 51:

> 49:             assertThrows(SecurityException.class, () -> {
> 50:                 JarEntry je1;
> 51:                 while((je1 = jis.getNextJarEntry()) != null) {

Suggestion:

                while ((je1 = jis.getNextJarEntry()) != null) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2830086526
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2830094967
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2830079233
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2830081400
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2830082170
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2830084626
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2830083314

From mullan at openjdk.org  Thu Feb 19 21:54:40 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 19 Feb 2026 21:54:40 GMT
Subject: RFR: 8377506: Implementation of PEM Encodings of Cryptographic
 Objects
In-Reply-To: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>
References: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>
Message-ID: <pOopbz03Z6IdtEJIgjh3xluNgUNNvowEwK47ag3Iozo=.1e552a5d-34c7-45f3-aa25-c4cf5eccedfa@github.com>

On Mon, 9 Feb 2026 21:04:34 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524), include:
> 
> - `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied.
> - `DEREncodable` is renamed to `BinaryEncodable` to more accurately reflect the binary data stored in PEM text.
> - In `EncryptedPrivateKeyInfo`, the `encrypt` methods now accept `BinaryEncodable`, and the `getKey()` and `getKeyPair()` methods no longer include a `Provider` parameter.
> - A new `CryptoException` indicates failures during cryptographic processing at runtime.
> 
> thanks

src/java.base/share/classes/java/security/CryptoException.java line 26:

> 24:  */
> 25: 
> 26: package java.security;

Suggest moving this to the `javax.crypto` package because of its name and it is more for crypto related errors.

src/java.base/share/classes/java/security/CryptoException.java line 38:

> 36:  * <p>This exception is not intended to represent internal
> 37:  * provider errors, which should be reported using {@link ProviderException}.
> 38:  */

Need an `@since`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2830317164
PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2830332106

From naoto at openjdk.org  Thu Feb 19 22:25:57 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 19 Feb 2026 22:25:57 GMT
Subject: RFR: 8378111: Migrate java/util/jar tests to JUnit
In-Reply-To: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
References: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
Message-ID: <udBJQG4kJxcZX2NFAe28ogOh4gi57gFo5Dmqpdug7HQ=.9dd9728b-160c-4c79-9043-bb81a9404c48@github.com>

On Thu, 19 Feb 2026 20:18:17 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR migrates the java/util/jar tests to use _JUnit_.
> 
> https://github.com/openjdk/jdk/commit/afe0aeee746bccbbe4bc6c9a8cd2302228ecc2f6 includes changes for _testNG_ based tests.
> https://github.com/openjdk/jdk/commit/c5a7f75840f96fa77ec3ed7faa713990adb84de6 includes changes for `main` based tests.
> 
> Before: Framework-based tests: 125 = 125 TestNG + 0 JUnit.
> After: Framework-based tests: 174 = 0 TestNG + 174 JUnit

test/jdk/java/util/jar/JarFile/TurkCert.java line 46:

> 44:     static void setLocale() {
> 45:         Locale.setDefault(Locale.of("tr", "TR"));
> 46:     }

Just a drive-by comment. Since the test is now running in othervm mode, we can eliminate this by running the vm with `-Duser.language=tr -Duser.country=TR`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2830450286

From duke at openjdk.org  Thu Feb 19 22:53:41 2026
From: duke at openjdk.org (Shawn M Emery)
Date: Thu, 19 Feb 2026 22:53:41 GMT
Subject: RFR: 8368841: X25519 implementation differs from the specification
 in RFC 7748 [v3]
In-Reply-To: <WcR-ShFFnhzlo9uJ0w8MVM0p67ipMeMdTcOLF4WbzWw=.951c61e5-3b19-4c4e-8c91-77a5c450dc15@github.com>
References: <c_dJLNLDU_f3_R5l-IX8FccJW6lAy6-TdzFlM_oEIJ0=.da3b9092-e3e7-4e34-84dd-178c94833a71@github.com>
 <WcR-ShFFnhzlo9uJ0w8MVM0p67ipMeMdTcOLF4WbzWw=.951c61e5-3b19-4c4e-8c91-77a5c450dc15@github.com>
Message-ID: <XC7NUp_P329cRIdMtk_aU95kWHIxUnw4K07LDtcEsxY=.7053dd5c-0929-4dca-bd70-dde61abdd68f@github.com>

On Thu, 19 Feb 2026 20:03:25 GMT, Ben Perez <bperez at openjdk.org> wrote:

>> Our implementation of X25519 does not zero the MSB of the `u` coordinate as required by RFC 7748. Currently the test `jdk/sun/security/ec/xec/TestXDH.java` zeroes the bit manually while parsing test vectors, which is likely why this went uncaught.
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed parsing functionality in TestXDH that manually clears MSB

Thank you for the changes.

-------------

Marked as reviewed by smemery at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/29750#pullrequestreview-3828946573

From almatvee at openjdk.org  Thu Feb 19 23:17:49 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 19 Feb 2026 23:17:49 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v13]
In-Reply-To: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
Message-ID: <xGG6Bc_JGEQeuw5WCsgsQ0fcPA5LZZP84FQGBcvYH0Y=.f8291725-5179-43f5-a8f9-0570c1107885@github.com>

> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
> - Added test to cover added functionality.
> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v11]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29260/files
  - new: https://git.openjdk.org/jdk/pull/29260/files/a7d5c14e..782d6864

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=11-12

  Stats: 55 lines in 9 files changed: 2 ins; 48 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/29260.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29260/head:pull/29260

PR: https://git.openjdk.org/jdk/pull/29260

From almatvee at openjdk.org  Thu Feb 19 23:17:50 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 19 Feb 2026 23:17:50 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v12]
In-Reply-To: <RbGqJfJv4v1UiNQnzQJPFXUoI2viH2-rrOQ8yX5T3OI=.be609e13-29f6-4ebe-84f4-84e6a559952a@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <RbGqJfJv4v1UiNQnzQJPFXUoI2viH2-rrOQ8yX5T3OI=.be609e13-29f6-4ebe-84f4-84e6a559952a@github.com>
Message-ID: <4sekHCkp41EefHsi5ZXiA0Y-WROkcBLvnbR_HoK4hjo=.a595660e-603a-40d2-8892-17cc446a99e1@github.com>

On Fri, 13 Feb 2026 03:32:17 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
>> - Added test to cover added functionality.
>> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v10]

8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v11]
- Fixed latest review comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29260#issuecomment-3930666125

From almatvee at openjdk.org  Thu Feb 19 23:25:41 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 19 Feb 2026 23:25:41 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v14]
In-Reply-To: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
Message-ID: <nZz-9QE2qMkqmhVA1WNHjiAM7bQdwiAHb0gKchsYtQU=.7fcce853-137f-4a2b-9840-f38dae2e5b63@github.com>

> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
> - Added test to cover added functionality.
> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.

Alexander Matveev 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 remote-tracking branch 'upstream/master' into JDK-8357404
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v11]
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v10]
 - Merge remote-tracking branch 'upstream/master' into JDK-8357404
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v9]
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v8]
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v7]
 - Merge remote-tracking branch 'upstream/master' into JDK-8357404
 - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]
 - merge with upstream
 - ... and 5 more: https://git.openjdk.org/jdk/compare/ff1c42f1...1bca2865

-------------

Changes: https://git.openjdk.org/jdk/pull/29260/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=13
  Stats: 747 lines in 19 files changed: 665 ins; 20 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/29260.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29260/head:pull/29260

PR: https://git.openjdk.org/jdk/pull/29260

From dl at openjdk.org  Fri Feb 20 00:49:45 2026
From: dl at openjdk.org (Doug Lea)
Date: Fri, 20 Feb 2026 00:49:45 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v40]
In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
Message-ID: <l9HNYBx9fke6-OrGzPPmMm3ZZDafMfwA00G1zWx4P1A=.61d8bc8d-73d5-4809-8b53-e40685d568e2@github.com>

> Changes signal filtering to avoid possible starvation

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  for testing different deactivation mechanics

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28797/files
  - new: https://git.openjdk.org/jdk/pull/28797/files/872fd0b5..067aaee9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=39
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=38-39

  Stats: 154 lines in 1 file changed: 44 ins; 46 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/28797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28797/head:pull/28797

PR: https://git.openjdk.org/jdk/pull/28797

From ascarpino at openjdk.org  Fri Feb 20 01:32:39 2026
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 20 Feb 2026 01:32:39 GMT
Subject: RFR: 8377506: Implementation of PEM Encodings of Cryptographic
 Objects [v2]
In-Reply-To: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>
References: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>
Message-ID: <YzPtaVvEe6dWIN5V4Nz-gdsUqza5_limqiYlggATDTE=.f46bd178-c664-48d6-99f8-7b0ae28d9617@github.com>

> Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524), include:
> 
> - `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied.
> - `DEREncodable` is renamed to `BinaryEncodable` to more accurately reflect the binary data stored in PEM text.
> - In `EncryptedPrivateKeyInfo`, the `encrypt` methods now accept `BinaryEncodable`, and the `getKey()` and `getKeyPair()` methods no longer include a `Provider` parameter.
> - A new `CryptoException` indicates failures during cryptographic processing at runtime.
> 
> thanks

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29640/files
  - new: https://git.openjdk.org/jdk/pull/29640/files/aba9622c..9697afd7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29640&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29640&range=00-01

  Stats: 45 lines in 6 files changed: 5 ins; 2 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/29640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29640/head:pull/29640

PR: https://git.openjdk.org/jdk/pull/29640

From dholmes at openjdk.org  Fri Feb 20 02:25:08 2026
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 20 Feb 2026 02:25:08 GMT
Subject: RFR: 8364182: Add jcmd VM.security_properties command [v10]
In-Reply-To: <2CAJOB43ZWZnLTLumQsG3F9K2hRqUzpgBzZ11HKHUI8=.abd8949e-aeb5-4cb5-b8ef-c8ff918ecbb3@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <2CAJOB43ZWZnLTLumQsG3F9K2hRqUzpgBzZ11HKHUI8=.abd8949e-aeb5-4cb5-b8ef-c8ff918ecbb3@github.com>
Message-ID: <XbOBerg-XPTnBj6bZ5Zt-A_HWdLFr2zC3Dev_iedjvw=.5553c9b3-55dd-44a9-b679-06ea47402b72@github.com>

On Wed, 18 Feb 2026 17:55:54 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   newline

src/hotspot/share/services/diagnosticCommand.hpp line 99:

> 97: class PrintSecurityPropertiesDCmd : public DCmd {
> 98: public:
> 99:     PrintSecurityPropertiesDCmd(outputStream* output, bool heap) : DCmd(output, heap) { }

Indent should be two on all lines.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2831044233

From ysuenaga at openjdk.org  Fri Feb 20 07:46:40 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 20 Feb 2026 07:46:40 GMT
Subject: RFR: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to
 intrinsify
Message-ID: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>

I ran following code with `-Djdk.incubator.vector.DEBUG=true`, however it was not intrinsified.


  public static void cos(){
    var rand = new Random();
    for(int i = 0; i < 1_000_000; i++){
      var vec = DoubleVector.fromArray(DoubleVector.SPECIES_256, rand.doubles().limit(4).toArray(), 0);

      vec.lanewise(VectorOperators.COS);
    }
  }


I knew `__jsvml_cos4_ha_l9()` in libjsvml.so should be called in this case (via vector debug log), but it was not hitted even though I set breakpoint in it.

`LaneType` has been introduced in [JDK-8376187](https://bugs.openjdk.org/browse/JDK-8376187), and `LibraryCallKit::inline_vector_call()` was updated to handle lane type rather than class of element type. However `VectorMathLibrary` wasn't modified.

I confirmed `__jsvml_cos4_ha_l9()` is called with this fix, and also all jdk/jdk/incubator/vector jtreg tests passed on Linux AMD64.

-------------

Commit messages:
 - 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to intrinsify

Changes: https://git.openjdk.org/jdk/pull/29835/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29835&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378312
  Stats: 9 lines in 3 files changed: 2 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/29835.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29835/head:pull/29835

PR: https://git.openjdk.org/jdk/pull/29835

From aartemov at openjdk.org  Fri Feb 20 08:34:16 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 20 Feb 2026 08:34:16 GMT
Subject: RFR: 8377223: Port fdlibm atanh to Java [v5]
In-Reply-To: <RhMYZu_Qi3DE0CPcAzg5r-4JFSOcwSBuI8kLlbIn_SQ=.cc3532fa-7e4c-4a45-a90f-57d707e93c54@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
 <RhMYZu_Qi3DE0CPcAzg5r-4JFSOcwSBuI8kLlbIn_SQ=.cc3532fa-7e4c-4a45-a90f-57d707e93c54@github.com>
Message-ID: <yv0vfM9oU-Y4YjFtQbGLqRzXrbyMEw-VbhnBzOzZvTE=.16eace4d-e862-4878-8965-bee8da8e4b9c@github.com>

On Thu, 19 Feb 2026 15:37:37 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> This is a port of FDLIBM atanh method.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8377223: Added case |x| > to docs.

Thanks for reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29782#issuecomment-3932400575

From aartemov at openjdk.org  Fri Feb 20 08:34:18 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 20 Feb 2026 08:34:18 GMT
Subject: Integrated: 8377223: Port fdlibm atanh to Java
In-Reply-To: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
References: <9HDT9ANrqxaClCcCoDcGnjKbuyACaIZ2U5WEtBT9ZiE=.c1510cf1-9306-4373-9994-a2ba97ea49c2@github.com>
Message-ID: <ajZjufHlWl5v2EjCqP1C30I1GnoKrVE4hu7_QaLY0UE=.e05d112e-e641-4792-aebb-b51a171ec095@github.com>

On Wed, 18 Feb 2026 10:10:31 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> This is a port of FDLIBM atanh method.

This pull request has now been integrated.

Changeset: fa2f4d82
Author:    Anton Artemov <aartemov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fa2f4d82f5337afab2291e4757387e4bc328265d
Stats:     651 lines in 7 files changed: 645 ins; 0 del; 6 mod

8377223: Port fdlibm atanh to Java

Reviewed-by: darcy, rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/29782

From eirbjo at openjdk.org  Fri Feb 20 08:53:18 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 20 Feb 2026 08:53:18 GMT
Subject: RFR: 8378111: Migrate java/util/jar tests to JUnit
In-Reply-To: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
References: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
Message-ID: <3Dj74Ia5qhHUFkKw4DaZAU96ka6BA1krEaZjukcmY54=.ba525041-8821-4ad1-97ed-b1d8b4c36f81@github.com>

On Thu, 19 Feb 2026 20:18:17 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR migrates the java/util/jar tests to use _JUnit_.
> 
> https://github.com/openjdk/jdk/commit/afe0aeee746bccbbe4bc6c9a8cd2302228ecc2f6 includes changes for _testNG_ based tests.
> https://github.com/openjdk/jdk/commit/c5a7f75840f96fa77ec3ed7faa713990adb84de6 includes changes for `main` based tests.
> 
> Before: Framework-based tests: 125 = 125 TestNG + 0 JUnit.
> After: Framework-based tests: 174 = 0 TestNG + 174 JUnit

Left some comments here and there :-)

test/jdk/java/util/jar/JarEntry/GetMethodsReturnClones.java line 73:

> 71:         for (JarEntry je : jarEntries) {
> 72:             Certificate[] certs = je.getCertificates();
> 73:             if (certs != null) {

% jarsigner -verify test/jdk/java/util/jar/JarEntry/test.jar  

The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled.


This test effectively does nothing.

Filed https://bugs.openjdk.org/browse/JDK-8378291 to track this.

test/jdk/java/util/jar/JarFile/SignedJarPendingBlock.java line 75:

> 73:     }
> 74: 
> 75:     @ParameterizedTest

There are two positive and a single negative test here. I don't think using `@ParameterizedTest` carries its weight in terms of the indirection cost. 

I think just three regular `@Test` methods would make this test easier to read.

test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarSecurity.java line 56:

> 54:     static final int MAJOR_VERSION = Runtime.version().major();
> 55: 
> 56:     private static final String userdir = System.getProperty("user.dir",".");

Debatable whether `private` adds value for a test class like this or just adds clutter.

test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarSecurity.java line 79:

> 77:             CertsAndSigners vcas = new CertsAndSigners(jf, jf.getJarEntry("version/Version.class"));
> 78:             CertsAndSigners rcas = new CertsAndSigners(jf, jf.getJarEntry("META-INF/versions/" + MAJOR_VERSION + "/version/Version.class"));
> 79:             assertTrue(Arrays.equals(rcas.getCertificates(), vcas.getCertificates()));

Could `assertArrayEquals` be used here and below?

test/jdk/java/util/jar/JarFile/mrjar/TestVersionedStream.java line 127:

> 125:     }
> 126: 
> 127:     public static Stream<Runtime.Version> data() {

I would rename this `arguments()`, `versions()` or something. `data()` seems a `@DataProvider` remnant.

test/jdk/java/util/jar/JarFile/mrjar/TestVersionedStream.java line 173:

> 171:             if (!match) {
> 172:                 fail("versioned entries not in same order as unversioned entries");
> 173:             }

Tempting to use `assertIterableEquals` here:


            // also keep the names
            List<String> versionedNames = versionedEntries.stream()
                    .map(JarEntry::getName)
                    .collect(Collectors.toList());

            // verify the correct order while building enames
            List<String> unversionedOrder = new ArrayList<>(unversionedEntryNames);
            unversionedOrder.retainAll(versionedNames);

            assertIterableEquals(unversionedOrder, versionedNames,
                    "versioned entries not in same order as unversioned entries");

test/jdk/java/util/jar/Manifest/IncludeInExceptionsTest.java line 47:

> 45:  * @run junit/othervm -Djdk.includeInExceptions=jar IncludeInExceptionsTest
> 46:  * @run junit/othervm IncludeInExceptionsTest
> 47:  * @summary Verify that the property jdk.net.includeInExceptions works as expected

`jdk.net.includeInExceptions` is not the property being tested here, should be `jdk.includeInExceptions` ?

test/jdk/java/util/jar/Manifest/IncludeInExceptionsTest.java line 80:

> 78:     @ParameterizedTest
> 79:     @MethodSource("manifests")
> 80:     void testInvalidManifest(Callable<?> attempt, boolean includeInExceptions) {

`includeInExceptions` is a static final, passing it around as a parameter seems unneccesary. 

If we use `includeInExceptions` directly, could `manifests()` return simply `Stream<Callable<?>` ?

test/jdk/java/util/jar/Manifest/WriteBinaryStructure.java line 53:

> 51:                 "Manifest-Version: 1.0\r\n" +
> 52:                 "Key: Value\r\n" +
> 53:                 "\r\n").getBytes(UTF_8), buf.toByteArray());

Consider putting the actual on a separate line here and below.

test/jdk/java/util/jar/TestExtra.java line 78:

> 76:     @Test
> 77:     void extraHeaderPlusDataTest() throws IOException {
> 78:         new TestExtra().testHeaderPlusData();

Consider letting JUnit handle the instance state management  to avoid these wrapper test methods.

-------------

PR Review: https://git.openjdk.org/jdk/pull/29828#pullrequestreview-3828563009
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2830276442
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2831635421
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2830302554
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2830306594
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2830316302
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2830426138
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2830193164
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2832074614
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2832080235
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2832092148

From kfarrell at openjdk.org  Fri Feb 20 09:45:38 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Fri, 20 Feb 2026 09:45:38 GMT
Subject: RFR: 8364182: Add jcmd VM.security_properties command [v11]
In-Reply-To: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <4GXiTaYe3ufPOybnnhtBErH1ClWe5HbUX6aH5O_027k=.be735264-0d9e-4ccd-944c-f0218fc7c820@github.com>

> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
> 
> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:

  update test to jtreg, indent changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29124/files
  - new: https://git.openjdk.org/jdk/pull/29124/files/332ef7df..9a449846

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=09-10

  Stats: 26 lines in 3 files changed: 4 ins; 3 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/29124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124

PR: https://git.openjdk.org/jdk/pull/29124

From ogillespie at openjdk.org  Fri Feb 20 10:00:53 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Fri, 20 Feb 2026 10:00:53 GMT
Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps [v2]
In-Reply-To: <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
References: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
 <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
Message-ID: <b3Xb6UhmLDZaA-f67uSiAdIIpglePoN8BNNcR9iN1os=.f02310a5-80ae-435c-9daf-65050acaa8da@github.com>

On Thu, 19 Feb 2026 09:35:00 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps.
>> 
>> Two interesting parts:
>> 
>> 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators.
>> 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps.
>
> Oli Gillespie 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 copyright
>  - Merge remote-tracking branch 'origin/master' into spliterator-test
>  - Switch to Objects.requireNonNull
>  - Add tests and fix impl

Thanks! @RogerRiggs would you mind taking a look too?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29485#issuecomment-3932778069

From coffeys at openjdk.org  Fri Feb 20 11:08:46 2026
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 20 Feb 2026 11:08:46 GMT
Subject: RFR: 8364182: Add jcmd VM.security_properties command [v11]
In-Reply-To: <4GXiTaYe3ufPOybnnhtBErH1ClWe5HbUX6aH5O_027k=.be735264-0d9e-4ccd-944c-f0218fc7c820@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <4GXiTaYe3ufPOybnnhtBErH1ClWe5HbUX6aH5O_027k=.be735264-0d9e-4ccd-944c-f0218fc7c820@github.com>
Message-ID: <Erh3BDzUuXFtIZV1wfFBx01GOJ-nb4wQNPqcC1W0dn0=.e306566b-51f0-41bb-898d-d65a7e8ceea4@github.com>

On Fri, 20 Feb 2026 09:45:38 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update test to jtreg, indent changes

test/hotspot/jtreg/serviceability/dcmd/vm/SecurityPropertiesTest.java line 34:

> 32: /*
> 33:  * @test
> 34:  * @bug 8376134

should be 8364182

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2832664575

From kfarrell at openjdk.org  Fri Feb 20 11:13:27 2026
From: kfarrell at openjdk.org (Kieran Farrell)
Date: Fri, 20 Feb 2026 11:13:27 GMT
Subject: RFR: 8364182: Add jcmd VM.security_properties command [v12]
In-Reply-To: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
Message-ID: <AT2ERqnvfTQ0vrwUNr0Csuz9DkT1VcfwTJHlJOvHtOY=.ab98e8f9-ed77-466a-b0a6-b7029d8d648b@github.com>

> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
> 
> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.

Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:

  update bugid

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29124/files
  - new: https://git.openjdk.org/jdk/pull/29124/files/9a449846..b91ce75a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=10-11

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124

PR: https://git.openjdk.org/jdk/pull/29124

From coffeys at openjdk.org  Fri Feb 20 11:18:04 2026
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 20 Feb 2026 11:18:04 GMT
Subject: RFR: 8364182: Add jcmd VM.security_properties command [v12]
In-Reply-To: <AT2ERqnvfTQ0vrwUNr0Csuz9DkT1VcfwTJHlJOvHtOY=.ab98e8f9-ed77-466a-b0a6-b7029d8d648b@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <AT2ERqnvfTQ0vrwUNr0Csuz9DkT1VcfwTJHlJOvHtOY=.ab98e8f9-ed77-466a-b0a6-b7029d8d648b@github.com>
Message-ID: <BnVM8xCJjyxW_R-8qx3qa620rNPw63CBm6xHtphbxP4=.80aff2ea-8a45-4fe7-976a-87f65ead42ab@github.com>

On Fri, 20 Feb 2026 11:13:27 GMT, Kieran Farrell <kfarrell at openjdk.org> wrote:

>> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. 
>> 
>> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication.
>
> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update bugid

LGTM. Thanks for pushing ahead with this.

-------------

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29124#pullrequestreview-3831511617

From duke at openjdk.org  Fri Feb 20 12:05:00 2026
From: duke at openjdk.org (Markus KARG)
Date: Fri, 20 Feb 2026 12:05:00 GMT
Subject: RFR: 8377388: Replacing "new StringReader(String)" by
 "Reader.of(CharSequence);" in Scanner
In-Reply-To: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
References: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
Message-ID: <B-uFW984eaakFefuoKXNFaUmEQdXdUsJ32cyuJDDc0s=.9c9e3cb6-8934-42f1-b39f-9f537337cbcd@github.com>

On Mon, 9 Feb 2026 07:33:03 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Request provides an implementation for [JDK-8377388](https://bugs.openjdk.org/browse/JDK-8377388): 'Replacing "new StringReader(String)" by "Reader.of(CharSequence);" in Scanner'.

Could someone please sponsor this change?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29627#issuecomment-3933680301

From jpai at openjdk.org  Fri Feb 20 12:09:48 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 20 Feb 2026 12:09:48 GMT
Subject: RFR: 8377388: Replacing "new StringReader(String)" by
 "Reader.of(CharSequence);" in Scanner
In-Reply-To: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
References: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
Message-ID: <2zDcJvnlziAQi-hh3jM0IXtjwGSk36nbGMPWwDAMzLc=.67bf95fa-0784-4240-8675-c7826428376e@github.com>

On Mon, 9 Feb 2026 07:33:03 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Request provides an implementation for [JDK-8377388](https://bugs.openjdk.org/browse/JDK-8377388): 'Replacing "new StringReader(String)" by "Reader.of(CharSequence);" in Scanner'.

Please issue a "/integrate" which then allows this to be sponsored.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29627#issuecomment-3933723218

From jpai at openjdk.org  Fri Feb 20 12:30:58 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 20 Feb 2026 12:30:58 GMT
Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile
 [v3]
In-Reply-To: <FNI7hOi3rFtcJBqAq-YmTmue8fJA7Qfm58btrfAUfAg=.4cd59c00-404a-45e7-9ee4-886d372bd8f4@github.com>
References: <QDvNIqpJBwz2AByfzrrgSs8tKMYI2JpTTkP6M_qoAyc=.9ac31c22-9c76-4bf8-8664-d075caf70ae0@github.com>
 <FNI7hOi3rFtcJBqAq-YmTmue8fJA7Qfm58btrfAUfAg=.4cd59c00-404a-45e7-9ee4-886d372bd8f4@github.com>
Message-ID: <TI0hFoKJ6Egipz44JF-llqTr8U3DpAfGsEvIXPh5WO0=.24d1c790-cf02-4349-83c9-d2fc56c274bb@github.com>

On Tue, 27 Jan 2026 09:30:19 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Hot on the heals of #29288, this PR replaces `ArrayDeque` with `ArrayList` for the Inflater cache implementation in `ZipFile.CleanableResource`.
>> 
>> With this PR, we change the order of the cache from a LIFO queue to a FIFO stack backed by ArrayList. The order seems unimportant, and has indeed been FIFO in the past when using `java.util.Vector`. Intuitively, it should be better to return the most recently used Inflater.
>> 
>> No tests updated, strict refactoring, `noreg-cleanup`.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove null check of final field istreams which is never null

src/java.base/share/classes/java/util/zip/ZipFile.java line 736:

> 734:                         inf.reset();
> 735:                         inflaters.addLast(inf);
> 736:                         return;

Hello Eirik, nit - my preference here would be to use `add(...)`, which is the same as `addLast(...)` but feels a bit more natural when using a `List`. When reading the code, the presence of `addLast(...)` makes me stop for a while to see if there's anything more going on here other than just adding to a `List`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29430#discussion_r2832973747

From eirbjo at openjdk.org  Fri Feb 20 12:51:12 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 20 Feb 2026 12:51:12 GMT
Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile
 [v4]
In-Reply-To: <QDvNIqpJBwz2AByfzrrgSs8tKMYI2JpTTkP6M_qoAyc=.9ac31c22-9c76-4bf8-8664-d075caf70ae0@github.com>
References: <QDvNIqpJBwz2AByfzrrgSs8tKMYI2JpTTkP6M_qoAyc=.9ac31c22-9c76-4bf8-8664-d075caf70ae0@github.com>
Message-ID: <bKvj6vkHxkcqYFnKRzRkzQLn6ebShnf_09A8XPgbLzo=.c34ce43d-24ef-49a0-a777-d07954c243be@github.com>

> Hot on the heals of #29288, this PR replaces `ArrayDeque` with `ArrayList` for the Inflater cache implementation in `ZipFile.CleanableResource`.
> 
> With this PR, we change the order of the cache from a LIFO queue to a FIFO stack backed by ArrayList. The order seems unimportant, and has indeed been FIFO in the past when using `java.util.Vector`. Intuitively, it should be better to return the most recently used Inflater.
> 
> No tests updated, strict refactoring, `noreg-cleanup`.

Eirik Bj?rsn?s has updated the pull request incrementally with three additional commits since the last revision:

 - Add code comment about returning the most recently used Inflater from the cache
 - Replace polling-style iteration with simple for loop
 - Using add instead of addLast seems more natural for a List

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29430/files
  - new: https://git.openjdk.org/jdk/pull/29430/files/388306a7..02de2507

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29430&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29430&range=02-03

  Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/29430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29430/head:pull/29430

PR: https://git.openjdk.org/jdk/pull/29430

From jpai at openjdk.org  Fri Feb 20 12:51:13 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 20 Feb 2026 12:51:13 GMT
Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile
 [v4]
In-Reply-To: <bKvj6vkHxkcqYFnKRzRkzQLn6ebShnf_09A8XPgbLzo=.c34ce43d-24ef-49a0-a777-d07954c243be@github.com>
References: <QDvNIqpJBwz2AByfzrrgSs8tKMYI2JpTTkP6M_qoAyc=.9ac31c22-9c76-4bf8-8664-d075caf70ae0@github.com>
 <bKvj6vkHxkcqYFnKRzRkzQLn6ebShnf_09A8XPgbLzo=.c34ce43d-24ef-49a0-a777-d07954c243be@github.com>
Message-ID: <wJIvnT9i9uVWyxaGIemUlbA4FZzZ7-1UQ_wDSQVRp6I=.fad7f5cd-8751-4023-adf4-e2564ffa17f4@github.com>

On Fri, 20 Feb 2026 12:48:17 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Hot on the heals of #29288, this PR replaces `ArrayDeque` with `ArrayList` for the Inflater cache implementation in `ZipFile.CleanableResource`.
>> 
>> With this PR, we change the order of the cache from a LIFO queue to a FIFO stack backed by ArrayList. The order seems unimportant, and has indeed been FIFO in the past when using `java.util.Vector`. Intuitively, it should be better to return the most recently used Inflater.
>> 
>> No tests updated, strict refactoring, `noreg-cleanup`.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Add code comment about returning the most recently used Inflater from the cache
>  - Replace polling-style iteration with simple for loop
>  - Using add instead of addLast seems more natural for a List

Overall the changes look good to me. I have added some inline review comments.

Please give me a few more days to approve this PR. I remember there was some discussion around the Inflater cache usage and how it may impact the performance. In this PR we have changed the policy on which Inflater we hand out from the cache, I would like to make sure that it doesn't have any unforeseen impact.

src/java.base/share/classes/java/util/zip/ZipFile.java line 719:

> 717:             synchronized (inflaterCache) {
> 718:                 if (!inflaterCache.isEmpty()) {
> 719:                     return inflaterCache.removeLast();

The use `removeLast()` I think is fine. Can you add a one liner comment here to say something like:

// return back the most recently used Inflater from the cache of not-in-use Inflaters

-------------

PR Review: https://git.openjdk.org/jdk/pull/29430#pullrequestreview-3831843273
PR Review Comment: https://git.openjdk.org/jdk/pull/29430#discussion_r2833012466

From eirbjo at openjdk.org  Fri Feb 20 12:51:13 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 20 Feb 2026 12:51:13 GMT
Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile
 [v4]
In-Reply-To: <wJIvnT9i9uVWyxaGIemUlbA4FZzZ7-1UQ_wDSQVRp6I=.fad7f5cd-8751-4023-adf4-e2564ffa17f4@github.com>
References: <QDvNIqpJBwz2AByfzrrgSs8tKMYI2JpTTkP6M_qoAyc=.9ac31c22-9c76-4bf8-8664-d075caf70ae0@github.com>
 <bKvj6vkHxkcqYFnKRzRkzQLn6ebShnf_09A8XPgbLzo=.c34ce43d-24ef-49a0-a777-d07954c243be@github.com>
 <wJIvnT9i9uVWyxaGIemUlbA4FZzZ7-1UQ_wDSQVRp6I=.fad7f5cd-8751-4023-adf4-e2564ffa17f4@github.com>
Message-ID: <hMlgdcLI0ufhek9qN0VO0KuV1oEeYbiAsRaX3y9iFG4=.270a2af5-a04c-4f1f-82bc-bcddc5ef6d32@github.com>

On Fri, 20 Feb 2026 12:41:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I remember there was some discussion around the Inflater cache usage and how it may impact the performance. In this PR we have changed the policy on which Inflater we hand out from the cache, I would like to make sure that it doesn't have any unforeseen impact.

Sure! My gut feeling is that a more recently used Inflater should if anything have better performance based on more recently used memory buffers. But who knows.

I know that Martin investigated the usefulness of this cache (a 'pool' really?) and found it questionable:

https://bugs.openjdk.org/browse/JDK-8156484

> src/java.base/share/classes/java/util/zip/ZipFile.java line 719:
> 
>> 717:             synchronized (inflaterCache) {
>> 718:                 if (!inflaterCache.isEmpty()) {
>> 719:                     return inflaterCache.removeLast();
> 
> The use `removeLast()` I think is fine. Can you add a one liner comment here to say something like:
> 
> // return back the most recently used Inflater from the cache of not-in-use Inflaters

Added comment as suggested.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29430#issuecomment-3934165851
PR Review Comment: https://git.openjdk.org/jdk/pull/29430#discussion_r2833034302

From eirbjo at openjdk.org  Fri Feb 20 12:51:17 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 20 Feb 2026 12:51:17 GMT
Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile
 [v3]
In-Reply-To: <TI0hFoKJ6Egipz44JF-llqTr8U3DpAfGsEvIXPh5WO0=.24d1c790-cf02-4349-83c9-d2fc56c274bb@github.com>
References: <QDvNIqpJBwz2AByfzrrgSs8tKMYI2JpTTkP6M_qoAyc=.9ac31c22-9c76-4bf8-8664-d075caf70ae0@github.com>
 <FNI7hOi3rFtcJBqAq-YmTmue8fJA7Qfm58btrfAUfAg=.4cd59c00-404a-45e7-9ee4-886d372bd8f4@github.com>
 <TI0hFoKJ6Egipz44JF-llqTr8U3DpAfGsEvIXPh5WO0=.24d1c790-cf02-4349-83c9-d2fc56c274bb@github.com>
Message-ID: <sTzV4zjxnRHGIgFu_1SYfmm6CTcgSEe-ZgMG10SQ5CU=.f20b6dbc-65eb-46bc-bfc5-99743be7e908@github.com>

On Fri, 20 Feb 2026 12:28:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove null check of final field istreams which is never null
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 736:
> 
>> 734:                         inf.reset();
>> 735:                         inflaters.addLast(inf);
>> 736:                         return;
> 
> Hello Eirik, nit - my preference here would be to use `add(...)`, which is the same as `addLast(...)` but feels a bit more natural when using a `List`. When reading the code, the presence of `addLast(...)` makes me stop for a while to see if there's anything more going on here other than just adding to a `List`.

I probably did this to balance with the `removeLast` in `getInflater`. And to express the List being used as a FIFO stack.

But I agree this probably raises more questions than answers, so reverted to add.

> src/java.base/share/classes/java/util/zip/ZipFile.java line 755:
> 
>> 753:                     Inflater inf;
>> 754:                     while (!inflaters.isEmpty()) {
>> 755:                         inflaters.removeLast().end();
> 
> I think we should replace this with a trivial:
> 
> 
> for (Inflater inf : inflaters) {
>     inf.end();
> }
> 
> for the same reasons as in my previous comment - it makes it trivial to understand without raising the questions about last vs first.

Good point, yes the iteration order should not matter. 

The list will not be empty after this loop, but it doesn't really matter since it is immediately set to `null` anyhow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29430#discussion_r2833008589
PR Review Comment: https://git.openjdk.org/jdk/pull/29430#discussion_r2833023224

From jpai at openjdk.org  Fri Feb 20 12:51:18 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 20 Feb 2026 12:51:18 GMT
Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile
 [v3]
In-Reply-To: <FNI7hOi3rFtcJBqAq-YmTmue8fJA7Qfm58btrfAUfAg=.4cd59c00-404a-45e7-9ee4-886d372bd8f4@github.com>
References: <QDvNIqpJBwz2AByfzrrgSs8tKMYI2JpTTkP6M_qoAyc=.9ac31c22-9c76-4bf8-8664-d075caf70ae0@github.com>
 <FNI7hOi3rFtcJBqAq-YmTmue8fJA7Qfm58btrfAUfAg=.4cd59c00-404a-45e7-9ee4-886d372bd8f4@github.com>
Message-ID: <iY3JynEQtVsCzpUkoZCihCTjJTWCO52A8AE3pZ2nKo0=.5f55e401-be3c-4d98-bef0-7c44e30c9363@github.com>

On Tue, 27 Jan 2026 09:30:19 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Hot on the heals of #29288, this PR replaces `ArrayDeque` with `ArrayList` for the Inflater cache implementation in `ZipFile.CleanableResource`.
>> 
>> With this PR, we change the order of the cache from a LIFO queue to a FIFO stack backed by ArrayList. The order seems unimportant, and has indeed been FIFO in the past when using `java.util.Vector`. Intuitively, it should be better to return the most recently used Inflater.
>> 
>> No tests updated, strict refactoring, `noreg-cleanup`.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove null check of final field istreams which is never null

src/java.base/share/classes/java/util/zip/ZipFile.java line 755:

> 753:                     Inflater inf;
> 754:                     while (!inflaters.isEmpty()) {
> 755:                         inflaters.removeLast().end();

I think we should replace this with a trivial:


for (Inflater inf : inflaters) {
    inf.end();
}

for the same reasons as in my previous comment - it makes it trivial to understand without raising the questions about last vs first.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29430#discussion_r2832992318

From jpai at openjdk.org  Fri Feb 20 12:51:20 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 20 Feb 2026 12:51:20 GMT
Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile
 [v4]
In-Reply-To: <N-cyasfKC6h97K5Ie_SOV2LdVrRuEERHxwTaPViDhF4=.e35eceb9-7908-4044-a9bd-3a9461470fc6@github.com>
References: <QDvNIqpJBwz2AByfzrrgSs8tKMYI2JpTTkP6M_qoAyc=.9ac31c22-9c76-4bf8-8664-d075caf70ae0@github.com>
 <FNI7hOi3rFtcJBqAq-YmTmue8fJA7Qfm58btrfAUfAg=.4cd59c00-404a-45e7-9ee4-886d372bd8f4@github.com>
 <N-cyasfKC6h97K5Ie_SOV2LdVrRuEERHxwTaPViDhF4=.e35eceb9-7908-4044-a9bd-3a9461470fc6@github.com>
Message-ID: <oZ24H9otEaHP79LE5EGdUQ_9Ecf3Ya81qNvkqfswkBo=.2cd795f2-b961-4c38-ba1b-677d2dc0ef16@github.com>

On Tue, 27 Jan 2026 09:30:54 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Add code comment about returning the most recently used Inflater from the cache
>>  - Replace polling-style iteration with simple for loop
>>  - Using add instead of addLast seems more natural for a List
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 764:
> 
>> 762: 
>> 763:             // Close streams, release their inflaters
>> 764:             if (istreams != null) {
> 
> Small additional fix to remove unnecessary null check of the final, definitely assigned  field `istreams`.
> 
> Unrelated to issue at hand, included here since it is close code and to avoid the PR churn for such a trivial cleanup if fixed separately.

This looks good to me. The null check appears to be an oversight in the original implementation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29430#discussion_r2833047049

From jpai at openjdk.org  Fri Feb 20 13:12:36 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 20 Feb 2026 13:12:36 GMT
Subject: RFR: 8376406: Avoid loading ArrayDeque in
 jdk.internal.loader.NativeLibraries [v2]
In-Reply-To: <tD6kIMyPSzSVbGGfXfi0QqLJRtsdhvvRtPJI7tw1C3A=.e50b6aa5-75ef-4cab-8e3b-6876385e87c1@github.com>
References: <2MTsiQD0RsVBX6TxePBIKbc2ZKisC_BRIVNbh72MeJ4=.18bd1814-41c2-4250-9242-72bdcb113cb0@github.com>
 <tD6kIMyPSzSVbGGfXfi0QqLJRtsdhvvRtPJI7tw1C3A=.e50b6aa5-75ef-4cab-8e3b-6876385e87c1@github.com>
Message-ID: <7uaDSKzIQWsg1FYwm1C1VlULuLnJ8wisVrqFxEd3th8=.bb4d5cd0-f030-4b25-9bec-ad313c8cc46f@github.com>

On Mon, 26 Jan 2026 21:16:41 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which replaces `ArrayDeque` with `ArrayList` for the native library context stack in `jdk.internal.loader.NativeLibraries.NativeLibraryContext`.
>> 
>> With this follow-up to similar changes in #29288 and #29430, a simple JAR-based "hello world" program no longer loads the `ArrayDeque` class during startup.
>> 
>> The change here is mostly a straightforward replacement. The existing processing was a FIFO stack, which it still is after this PR, just backed by ArrayList instead.
>> 
>> Since ArrayList is null-friendly, I added an explicit `Objects.requireNullNull` before pushing to the stack.
>> 
>> Pure refactoring, no tests updated, `noreg-cleanup`.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 479:

> 477: 
> 478:         // Maps thread object to the native library context stack, maintained by each thread
> 479:         private static Map<Thread, List<NativeLibraryImpl>> nativeLibraryThreadContext =

This field can be made `final`.

src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 488:

> 486:                     new Function<>() {
> 487:                         public List<NativeLibraryImpl> apply(Thread t) {
> 488:                             return new ArrayList<>(8);

The `ArrayDeque()` constructor takes the number of "elements" whereas `ArrayList()` constructor takes the initial capacity. Having said that, I can't see why this `8` was used in the first place. It was introduced in https://bugs.openjdk.org/browse/JDK-8228336 and the review thread https://mail.openjdk.org/pipermail/core-libs-dev/2020-March/065194.html doesn't make a mention of it, so this initial number of elements may not be too critical in this code. If we are going to change this to an ArrayList, maybe we should just change this to `new ArrayList<>()`.

It would be good to hear from Alan @AlanBateman about this proposed change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29432#discussion_r2833133016
PR Review Comment: https://git.openjdk.org/jdk/pull/29432#discussion_r2833122765

From eirbjo at openjdk.org  Fri Feb 20 13:17:43 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 20 Feb 2026 13:17:43 GMT
Subject: RFR: 8376406: Avoid loading ArrayDeque in
 jdk.internal.loader.NativeLibraries [v3]
In-Reply-To: <2MTsiQD0RsVBX6TxePBIKbc2ZKisC_BRIVNbh72MeJ4=.18bd1814-41c2-4250-9242-72bdcb113cb0@github.com>
References: <2MTsiQD0RsVBX6TxePBIKbc2ZKisC_BRIVNbh72MeJ4=.18bd1814-41c2-4250-9242-72bdcb113cb0@github.com>
Message-ID: <VLrxyAkeF0uUZHlhj3H9K5E1_wXeTTlV03FLZt53p24=.c5769633-f2a0-4bf7-b5da-a2a801352613@github.com>

> Please review this PR which replaces `ArrayDeque` with `ArrayList` for the native library context stack in `jdk.internal.loader.NativeLibraries.NativeLibraryContext`.
> 
> With this follow-up to similar changes in #29288 and #29430, a simple JAR-based "hello world" program no longer loads the `ArrayDeque` class during startup.
> 
> The change here is mostly a straightforward replacement. The existing processing was a FIFO stack, which it still is after this PR, just backed by ArrayList instead.
> 
> Since ArrayList is null-friendly, I added an explicit `Objects.requireNullNull` before pushing to the stack.
> 
> Pure refactoring, no tests updated, `noreg-cleanup`.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Mark NativeLibraryContext.nativeLibraryThreadContext field final

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29432/files
  - new: https://git.openjdk.org/jdk/pull/29432/files/0a12622c..d5259f9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29432&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29432&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29432.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29432/head:pull/29432

PR: https://git.openjdk.org/jdk/pull/29432

From eirbjo at openjdk.org  Fri Feb 20 13:17:45 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 20 Feb 2026 13:17:45 GMT
Subject: RFR: 8376406: Avoid loading ArrayDeque in
 jdk.internal.loader.NativeLibraries [v2]
In-Reply-To: <7uaDSKzIQWsg1FYwm1C1VlULuLnJ8wisVrqFxEd3th8=.bb4d5cd0-f030-4b25-9bec-ad313c8cc46f@github.com>
References: <2MTsiQD0RsVBX6TxePBIKbc2ZKisC_BRIVNbh72MeJ4=.18bd1814-41c2-4250-9242-72bdcb113cb0@github.com>
 <tD6kIMyPSzSVbGGfXfi0QqLJRtsdhvvRtPJI7tw1C3A=.e50b6aa5-75ef-4cab-8e3b-6876385e87c1@github.com>
 <7uaDSKzIQWsg1FYwm1C1VlULuLnJ8wisVrqFxEd3th8=.bb4d5cd0-f030-4b25-9bec-ad313c8cc46f@github.com>
Message-ID: <keX7RkslngcR8coYUXTFqcIIHtdprRYn_zxqHg2M-Fw=.58a553ca-dae3-4b24-a7ad-c62830e5186e@github.com>

On Fri, 20 Feb 2026 13:10:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year
>
> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 479:
> 
>> 477: 
>> 478:         // Maps thread object to the native library context stack, maintained by each thread
>> 479:         private static Map<Thread, List<NativeLibraryImpl>> nativeLibraryThreadContext =
> 
> This field can be made `final`.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29432#discussion_r2833151779

From eirbjo at openjdk.org  Fri Feb 20 13:25:17 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 20 Feb 2026 13:25:17 GMT
Subject: RFR: 8376406: Avoid loading ArrayDeque in
 jdk.internal.loader.NativeLibraries [v2]
In-Reply-To: <7uaDSKzIQWsg1FYwm1C1VlULuLnJ8wisVrqFxEd3th8=.bb4d5cd0-f030-4b25-9bec-ad313c8cc46f@github.com>
References: <2MTsiQD0RsVBX6TxePBIKbc2ZKisC_BRIVNbh72MeJ4=.18bd1814-41c2-4250-9242-72bdcb113cb0@github.com>
 <tD6kIMyPSzSVbGGfXfi0QqLJRtsdhvvRtPJI7tw1C3A=.e50b6aa5-75ef-4cab-8e3b-6876385e87c1@github.com>
 <7uaDSKzIQWsg1FYwm1C1VlULuLnJ8wisVrqFxEd3th8=.bb4d5cd0-f030-4b25-9bec-ad313c8cc46f@github.com>
Message-ID: <pyBMGHFDDCUjNTbZ6RUqKf-wyoYPGEj52xUoeaikCl4=.addb63f8-92d7-429d-9fd2-7e4114dec82f@github.com>

On Fri, 20 Feb 2026 13:07:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The `ArrayDeque()` constructor takes the number of "elements" whereas `ArrayList()` constructor takes the initial capacity. 

They both seem to allocate Object arrays to fit elements. ArrayList makes an array for 8 objects, ArrayDeque 8 + 1.

> Having said that, I can't see why this `8` was used in the first place. 


> If we are going to change this to an ArrayList, maybe we should just change this to new ArrayList<>().

Sounds reasonable, that would allow `isEmpty()` checks on an empty list to avoid allocation. If that matters.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29432#discussion_r2833180523

From mullan at openjdk.org  Fri Feb 20 15:10:35 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 20 Feb 2026 15:10:35 GMT
Subject: RFR: 8377506: Implementation of PEM Encodings of Cryptographic
 Objects [v2]
In-Reply-To: <YzPtaVvEe6dWIN5V4Nz-gdsUqza5_limqiYlggATDTE=.f46bd178-c664-48d6-99f8-7b0ae28d9617@github.com>
References: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>
 <YzPtaVvEe6dWIN5V4Nz-gdsUqza5_limqiYlggATDTE=.f46bd178-c664-48d6-99f8-7b0ae28d9617@github.com>
Message-ID: <ZqKsqMlfYcSUp-udtwMqQQnqaIPeIGbukMPPpgxrLrQ=.be5dd2f6-14e2-4fa0-97e0-c81ffe2708ea@github.com>

On Fri, 20 Feb 2026 01:32:39 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524), include:
>> 
>> - `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied.
>> - `DEREncodable` is renamed to `BinaryEncodable` to more accurately reflect the binary data stored in PEM text.
>> - In `EncryptedPrivateKeyInfo`, the `encrypt` methods now accept `BinaryEncodable`, and the `getKey()` and `getKeyPair()` methods no longer include a `Provider` parameter.
>> - A new `CryptoException` indicates failures during cryptographic processing at runtime.
>> 
>> thanks
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

src/java.base/share/classes/java/security/PEM.java line 76:

> 74:  */
> 75: 
> 76: final public class PEM implements BinaryEncodable {

I think the order should be "public final".

src/java.base/share/classes/java/security/PEMDecoder.java line 514:

> 512:      * Returns a copy of this {@code PEMDecoder} that decodes and decrypts
> 513:      * encrypted private keys using the specified password.
> 514:      * Unencrypted PEM can also be decoded by the returned instance

Missing period.

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 347:

> 345:      * Specification.
> 346:      *
> 347:      * @param de the {@code BinaryEncodable} to encrypt. Supported types include

Change variable name to `be`.

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 392:

> 390:      * password-based encryption (PBE) algorithm and provider are used.
> 391:      *
> 392:      * @param de the {@code BinaryEncodable} to encrypt. Supported types include

Change variable name to be.

src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line 426:

> 424:      * Specification.
> 425:      *
> 426:      * @param de the {@code BinaryEncodable} to encrypt. Supported types include

Change variable name to be.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2833666554
PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2833557059
PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2833246705
PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2833253745
PR Review Comment: https://git.openjdk.org/jdk/pull/29640#discussion_r2833255134

From rriggs at openjdk.org  Fri Feb 20 15:41:38 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 20 Feb 2026 15:41:38 GMT
Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps [v2]
In-Reply-To: <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
References: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
 <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
Message-ID: <xQ6wowUEWl_Hy0VSZYlwrygmkTpKmlYlVjIzmyaKm2I=.af59191c-eef8-48a1-baa1-e10cacb47c23@github.com>

On Thu, 19 Feb 2026 09:35:00 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps.
>> 
>> Two interesting parts:
>> 
>> 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators.
>> 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps.
>
> Oli Gillespie 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 copyright
>  - Merge remote-tracking branch 'origin/master' into spliterator-test
>  - Switch to Objects.requireNonNull
>  - Add tests and fix impl

Looks good, thanks

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29485#pullrequestreview-3832717288

From duke at openjdk.org  Fri Feb 20 15:50:11 2026
From: duke at openjdk.org (duke)
Date: Fri, 20 Feb 2026 15:50:11 GMT
Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps [v2]
In-Reply-To: <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
References: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
 <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
Message-ID: <PFrnfuTKutPGYZoZDRnj9noCBDUF0eXZmJfkA5gPZjI=.f5479029-d52a-4571-86e6-2ff055846aa1@github.com>

On Thu, 19 Feb 2026 09:35:00 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps.
>> 
>> Two interesting parts:
>> 
>> 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators.
>> 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps.
>
> Oli Gillespie 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 copyright
>  - Merge remote-tracking branch 'origin/master' into spliterator-test
>  - Switch to Objects.requireNonNull
>  - Add tests and fix impl

@olivergillespie 
Your change (at version f376e3c1376b91b9df0e79c78737a3c416fcb3b0) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29485#issuecomment-3935684432

From vyazici at openjdk.org  Fri Feb 20 16:29:00 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 20 Feb 2026 16:29:00 GMT
Subject: RFR: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics [v5]
In-Reply-To: <KeNqd83bGg0oPTyA4m5C8HB_F5q5r4jcY_ac96NNMI4=.74f069e3-4ba1-44b2-b9ac-6d84a745d8cb@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
 <KeNqd83bGg0oPTyA4m5C8HB_F5q5r4jcY_ac96NNMI4=.74f069e3-4ba1-44b2-b9ac-6d84a745d8cb@github.com>
Message-ID: <zDakBYuyNRTDZwJsUAdKkByWK1Pt8stqPNjdcbPcXn4=.3178b834-74e9-4180-97a4-7930b9f92ab9@github.com>

On Tue, 10 Feb 2026 16:36:18 GMT, Damon Fenacci <dfenacci 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 16 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into sLatin1Intr
>>  - Remove redundant checks in `indexOf0(byte[] value, byte[] str)`
>>  - More `indexOf` et al. guards and other review feedback
>>  - Use `vmIntrinsics::*` to refer to intrinsics from Java
>>  - Improve vertical alignment in `vmIntrinsics.hpp`
>>  - Apply review feedback
>>  - More doc updates
>>  - Reflect that `VerifyIntrinsicChecks` is removed
>>  - Merge remote-tracking branch 'upstream/master' into sLatin1Intr
>>  - Fix `Helper`
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/bf17641f...6eb75a06
>
> Thanks for looking into this @vy! I left a couple of comments/questions (I've mostly checked the intrinsic part).

@dafedafe, @RogerRiggs, @rgiulietti, thank you so much for your kind assistance and reviews. I needed some extra time to check the performance implications of the changes (i.e., 6eb75a06d94), but they look good. Tier 1-2 is clear too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28832#issuecomment-3935864428

From vyazici at openjdk.org  Fri Feb 20 16:29:01 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 20 Feb 2026 16:29:01 GMT
Subject: Integrated: 8367129: Move input validation checks to Java for
 java.lang.StringLatin1 intrinsics
In-Reply-To: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
References: <3ZTvvsqpt-QM1L6k4diuCb78ncm5K1x62P2rpPzVbT0=.1666797a-ba37-42ad-b45a-ee1d58ad4c55@github.com>
Message-ID: <mdNvYUGeBRp5jyTv3ZYnq0WqvJEBxsMZmVdPc1i_i-c=.74591716-60b4-4409-96a8-f812413452c1@github.com>

On Mon, 15 Dec 2025 20:30:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Moves input validation checks to Java for `java.lang.StringLatin1` intrinsics. While doing so, affected `java.lang.StringUTF16` methods needed to be updated due to relaxed checks at intrinsics. The javadocs of the touched methods are extensively overhauled.

This pull request has now been integrated.

Changeset: 72b28672
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/72b28672ad2f0f70cf57c9dc753b0ba20f6bcaaa
Stats:     588 lines in 5 files changed: 476 ins; 23 del; 89 mod

8367129: Move input validation checks to Java for java.lang.StringLatin1 intrinsics

Reviewed-by: rriggs, rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/28832

From liach at openjdk.org  Fri Feb 20 16:52:51 2026
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Feb 2026 16:52:51 GMT
Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps [v2]
In-Reply-To: <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
References: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
 <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
Message-ID: <mOKq7P0eQ1l9dDpxrONJp4s1Z6n5b7rhG8YUYzaUUNU=.a299f11b-91f4-48ae-bc95-88f8ca42c218@github.com>

On Thu, 19 Feb 2026 09:35:00 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps.
>> 
>> Two interesting parts:
>> 
>> 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators.
>> 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps.
>
> Oli Gillespie 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 copyright
>  - Merge remote-tracking branch 'origin/master' into spliterator-test
>  - Switch to Objects.requireNonNull
>  - Add tests and fix impl

Thanks for this improvement! Remember to follow the 4th step in ["Writing a release note"](https://openjdk.org/guide/#writing-a-release-note) that you should Resolve the note with resolution "Delivered" so it will show up in https://jdk.java.net/27/release-notes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29485#issuecomment-3935981647

From ogillespie at openjdk.org  Fri Feb 20 16:52:52 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Fri, 20 Feb 2026 16:52:52 GMT
Subject: Integrated: 8376698: Add Spliterator tests for TreeMap sub-maps
In-Reply-To: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
References: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
Message-ID: <bzT7t4ekEGhRtD7MPl6--5nToas6PKnHDa7MgzzYIRc=.54516f6b-9b50-4496-8743-62e92128b046@github.com>

On Thu, 29 Jan 2026 12:40:42 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps.
> 
> Two interesting parts:
> 
> 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators.
> 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps.

This pull request has now been integrated.

Changeset: 932f28c6
Author:    Oli Gillespie <ogillespie at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/932f28c69b8573ad85fde2e0fa00cb3a46d93c2e
Stats:     32 lines in 2 files changed: 29 ins; 1 del; 2 mod

8376698: Add Spliterator tests for TreeMap sub-maps

Reviewed-by: liach, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/29485

From duke at openjdk.org  Fri Feb 20 17:01:13 2026
From: duke at openjdk.org (Markus KARG)
Date: Fri, 20 Feb 2026 17:01:13 GMT
Subject: RFR: 8377388: Replacing "new StringReader(String)" by
 "Reader.of(CharSequence);" in Scanner
In-Reply-To: <2zDcJvnlziAQi-hh3jM0IXtjwGSk36nbGMPWwDAMzLc=.67bf95fa-0784-4240-8675-c7826428376e@github.com>
References: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
 <2zDcJvnlziAQi-hh3jM0IXtjwGSk36nbGMPWwDAMzLc=.67bf95fa-0784-4240-8675-c7826428376e@github.com>
Message-ID: <B6rp77AdfB9hMX0fBiMKcmroZHJlCwQYRmZqL_978-Q=.14200213-4c87-4764-8c6b-1fc333716e35@github.com>

On Fri, 20 Feb 2026 12:07:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Please issue a "/integrate" which then allows this to be sponsored.

Done, but Skara did not pick it up. Maybe you need to explicitly mark this PR as "reviewed" first? ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29627#issuecomment-3936027732

From duke at openjdk.org  Fri Feb 20 17:01:15 2026
From: duke at openjdk.org (duke)
Date: Fri, 20 Feb 2026 17:01:15 GMT
Subject: RFR: 8377388: Replacing "new StringReader(String)" by
 "Reader.of(CharSequence);" in Scanner
In-Reply-To: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
References: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
Message-ID: <xIwoeMnKxiTEmYbWbVBeADD8B6vFbhWOHBqu3r-iPeQ=.264b7e26-03bc-49b6-a18e-7026ee1216c1@github.com>

On Mon, 9 Feb 2026 07:33:03 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Request provides an implementation for [JDK-8377388](https://bugs.openjdk.org/browse/JDK-8377388): 'Replacing "new StringReader(String)" by "Reader.of(CharSequence);" in Scanner'.

@mkarg 
Your change (at version 03837bb46aeb4c907af0fef8063f461aceaf079a) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29627#issuecomment-3936032533

From jbhateja at openjdk.org  Fri Feb 20 17:04:31 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 20 Feb 2026 17:04:31 GMT
Subject: RFR: 8377438: [VectorAPI] Add new carrier type to LaneType class
 [v2]
In-Reply-To: <qmSybXnaUH8CxOjqOJwhdINd_GhiWX6OlG8ABL1GScE=.fe7f9703-d35a-475f-9e85-ed9063f3648d@github.com>
References: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
 <qmSybXnaUH8CxOjqOJwhdINd_GhiWX6OlG8ABL1GScE=.fe7f9703-d35a-475f-9e85-ed9063f3648d@github.com>
Message-ID: <DUrvcot8bNzqEad84BhycEOtC9gFFiaXmrYTMf7CUQ0=.79ac41c0-f385-4e51-83c9-4ba036f8121e@github.com>

On Thu, 19 Feb 2026 12:02:27 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
>> 
>> With Float16 we need to differentiate b/w vector lane element type and carrier type. while element type corresponds to exact type of lane i.e. Float16.class, carrier type corresponds to the storage type required to propagate IEEE 754 float16 values to inline expander.
>> 
>> Patch adds a new carrier type to existing LaneType structure and use it for following purpose.
>>  - To compute preferred shape of vector.
>>  - To allocate vector backing storage during dummy vector and iota array creation.
>>  - Sanity checking to ensure vector lane type is a primitive type in inline expander.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8377438
>  - 8377438: [VectorAPI] Add new carrier type to LaneType class

Hi @PaulSandoz ,  please let me know if there are comments on this

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29629#issuecomment-3936047753

From lancea at openjdk.org  Fri Feb 20 17:11:16 2026
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 20 Feb 2026 17:11:16 GMT
Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile
 [v4]
In-Reply-To: <bKvj6vkHxkcqYFnKRzRkzQLn6ebShnf_09A8XPgbLzo=.c34ce43d-24ef-49a0-a777-d07954c243be@github.com>
References: <QDvNIqpJBwz2AByfzrrgSs8tKMYI2JpTTkP6M_qoAyc=.9ac31c22-9c76-4bf8-8664-d075caf70ae0@github.com>
 <bKvj6vkHxkcqYFnKRzRkzQLn6ebShnf_09A8XPgbLzo=.c34ce43d-24ef-49a0-a777-d07954c243be@github.com>
Message-ID: <X7bWYwFWhtPkXS9NZZ6hhrbFjASDeU94CBv78Skjvqk=.fccf7576-93b5-402e-ba72-ab7cae22d4d3@github.com>

On Fri, 20 Feb 2026 12:51:12 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Hot on the heals of #29288, this PR replaces `ArrayDeque` with `ArrayList` for the Inflater cache implementation in `ZipFile.CleanableResource`.
>> 
>> With this PR, we change the order of the cache from a LIFO queue to a FIFO stack backed by ArrayList. The order seems unimportant, and has indeed been FIFO in the past when using `java.util.Vector`. Intuitively, it should be better to return the most recently used Inflater.
>> 
>> No tests updated, strict refactoring, `noreg-cleanup`.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Add code comment about returning the most recently used Inflater from the cache
>  - Replace polling-style iteration with simple for loop
>  - Using add instead of addLast seems more natural for a List

Lates revision looks fine

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29430#pullrequestreview-3833200302

From rriggs at openjdk.org  Fri Feb 20 17:18:50 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 20 Feb 2026 17:18:50 GMT
Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps [v2]
In-Reply-To: <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
References: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
 <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
Message-ID: <mYDsr1E17-IaE8TWlmSeemFuulXCwk5m7Bl1_k0pLjo=.691e675a-8c6d-4a02-8f21-b47858e7ce3c@github.com>

On Thu, 19 Feb 2026 09:35:00 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps.
>> 
>> Two interesting parts:
>> 
>> 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators.
>> 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps.
>
> Oli Gillespie 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 copyright
>  - Merge remote-tracking branch 'origin/master' into spliterator-test
>  - Switch to Objects.requireNonNull
>  - Add tests and fix impl

The release note title should reflect the change in behavior.
In retrospect, the issue should also have been re-titled to describe the problem, not the tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29485#issuecomment-3936134325

From ogillespie at openjdk.org  Fri Feb 20 17:32:13 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Fri, 20 Feb 2026 17:32:13 GMT
Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps [v2]
In-Reply-To: <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
References: <QGrQQkxA7TdjPn_lPIPP-gRohRmHe4tyBkUYc9r2WJA=.ebc9b6c5-5ed7-4525-9720-6273613109ed@github.com>
 <ESfg4AfBbJwNZfXV2b1OKS4uWvg68oLDuvNYLLembGg=.8ca0eb4c-0b96-44f3-bf9c-b204d315ac1b@github.com>
Message-ID: <fVOr1j_18JBzR6t0zZetbUjZL2COuWW-2A-VLQ7YhFw=.eaf1beab-32e2-4bc1-902e-5c6abf79a0a0@github.com>

On Thu, 19 Feb 2026 09:35:00 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps.
>> 
>> Two interesting parts:
>> 
>> 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators.
>> 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps.
>
> Oli Gillespie 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 copyright
>  - Merge remote-tracking branch 'origin/master' into spliterator-test
>  - Switch to Objects.requireNonNull
>  - Add tests and fix impl

The release note title is `Release Note: NPE for empty TreeMap/TreeSet sub-set Spliterator and Stream`, do you suggest something else?

> In retrospect, the issue should also have been re-titled to describe the problem, not the tests.

Yes my bad, I started out just adding the tests and then realized the behaviour was wrong and fixed that. Forgot to update the title.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29485#issuecomment-3936197508

From lancea at openjdk.org  Fri Feb 20 17:34:01 2026
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 20 Feb 2026 17:34:01 GMT
Subject: RFR: 8377992: (zipfs) Align ZipFileSystem END header validation
 with the ZipFile implementation [v2]
In-Reply-To: <jbBil_B07PotomaIOfzb5ecf9BSBRGvN88-2I0NbIfk=.47162c2c-23df-4559-b12c-59f8b23846b1@github.com>
References: <1tONCY1QoXxaeUtr3LE4YoZk0UitQ5NqadNJOPFjREQ=.9b237170-fb07-4713-82fb-26b968b268de@github.com>
 <jbBil_B07PotomaIOfzb5ecf9BSBRGvN88-2I0NbIfk=.47162c2c-23df-4559-b12c-59f8b23846b1@github.com>
Message-ID: <emb3qTX7bnPrHjsmVOaMJSMGZZCP8ubUztOSsmFYrls=.0166ac24-f321-48ed-8224-7045f01004eb@github.com>

On Thu, 19 Feb 2026 18:44:32 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`.
>> 
>> This brings two validation checks over to `ZipFileSystem`:
>> 
>> * Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746)
>> * Rejection of END headers with a total entry count which cannot fit within the CEN byte array  (JDK-8341625)
>> 
>> Test vector setup in `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is extracted to a new test lib utility class `jdk.test.lib.util.ZipUtils`. `EndOfCenValidation` is then copied to `test/jdk/jdk/nio/zipfs` and adjusted to test `ZipFileSystem` instead of `ZipFile`.
>> 
>> Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries.  Similar adjustments to `ZipFile` was done in JDK-8341625.
>> 
>> `ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Replace ZipFile reference in clas comment with ZipFileSystem
>  - Remove spurious '*'
>  - Extract test vector setup into ZipUtils class reusable across ZipFile/ZipFileSystem tests

thank you for the update Eirik.

Overall looks good.  You might get some asks to remove the extra blank lines here and there.  I have no strong preference.

I think the copyright should just be 2026 for these new files but need to confirm

test/jdk/jdk/nio/zipfs/EndOfCenValidation.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, 2026, Oracle and/or its affiliates. All rights reserved.

As this is a new file, I believe this should be 2026 only

test/lib/jdk/test/lib/util/ZipUtils.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, 2026, Oracle and/or its affiliates. All rights reserved.

Same comment on copyright only being 2026

-------------

PR Review: https://git.openjdk.org/jdk/pull/29747#pullrequestreview-3833307379
PR Review Comment: https://git.openjdk.org/jdk/pull/29747#discussion_r2834291100
PR Review Comment: https://git.openjdk.org/jdk/pull/29747#discussion_r2834293304

From eirbjo at openjdk.org  Fri Feb 20 17:48:04 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 20 Feb 2026 17:48:04 GMT
Subject: RFR: 8377992: (zipfs) Align ZipFileSystem END header validation
 with the ZipFile implementation [v2]
In-Reply-To: <emb3qTX7bnPrHjsmVOaMJSMGZZCP8ubUztOSsmFYrls=.0166ac24-f321-48ed-8224-7045f01004eb@github.com>
References: <1tONCY1QoXxaeUtr3LE4YoZk0UitQ5NqadNJOPFjREQ=.9b237170-fb07-4713-82fb-26b968b268de@github.com>
 <jbBil_B07PotomaIOfzb5ecf9BSBRGvN88-2I0NbIfk=.47162c2c-23df-4559-b12c-59f8b23846b1@github.com>
 <emb3qTX7bnPrHjsmVOaMJSMGZZCP8ubUztOSsmFYrls=.0166ac24-f321-48ed-8224-7045f01004eb@github.com>
Message-ID: <4cyQS2wjOh2dLv41ZoslFVej07g3v8TvKMuZdqJtnwQ=.5f31a1af-c414-4865-beab-b4722834963d@github.com>

On Fri, 20 Feb 2026 17:30:59 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Overall looks good. You might get some asks to remove the extra blank lines here and there. I have no strong preference.

Comparing with mainline I don't see I added much blank lines. If there is any particular places you'd like me to trim existing ones, let me know.

> I think the copyright should just be 2026 for these new files but need to confirm

My reasoning here is that while these are new files, they are copies containing intellectual property written in the period 2023-2026. I am by no means a lawyer, but shouldn't these copyright headers reflect the IP contained in the file, not the file history itsef?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29747#issuecomment-3936269239

From psandoz at openjdk.org  Fri Feb 20 17:54:06 2026
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 20 Feb 2026 17:54:06 GMT
Subject: RFR: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to
 intrinsify
In-Reply-To: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
References: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
Message-ID: <f-kgblEMFVWfgILa2OnOQqZFwv-5WGmaDdqGKKmCWYQ=.b55db16d-2245-4725-b129-63213e4c696d@github.com>

On Fri, 20 Feb 2026 05:30:00 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I ran following code with `-Djdk.incubator.vector.DEBUG=true`, however it was not intrinsified.
> 
> 
>   public static void cos(){
>     var rand = new Random();
>     for(int i = 0; i < 1_000_000; i++){
>       var vec = DoubleVector.fromArray(DoubleVector.SPECIES_256, rand.doubles().limit(4).toArray(), 0);
> 
>       vec.lanewise(VectorOperators.COS);
>     }
>   }
> 
> 
> I knew `__jsvml_cos4_ha_l9()` in libjsvml.so should be called in this case (via vector debug log), but it was not hitted even though I set breakpoint in it.
> 
> `LaneType` has been introduced in [JDK-8376187](https://bugs.openjdk.org/browse/JDK-8376187), and `LibraryCallKit::inline_vector_call()` was updated to handle lane type rather than class of element type. However `VectorMathLibrary` wasn't modified.
> 
> I confirmed `__jsvml_cos4_ha_l9()` is called with this fix, and also all jdk/jdk/incubator/vector jtreg tests passed on Linux AMD64.

Thank you for catching this. We need an IR test, could you investigate if that is possible? Perhaps pick one unary op and one binary op to test.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 295:

> 293:             @SuppressWarnings({"unchecked"})
> 294:             Class<V> vt = (Class<V>)vspecies.vectorType();
> 295:             AbstractSpecies<E> asp = (AbstractSpecies<E>)vspecies;

Instead change method signature to use `AbstractSpecies<E>` (from `VectorSpecies<E>`) and at the call site change the argument to be result of `vspecies()` (from `species()`).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29835#pullrequestreview-3833423836
PR Review Comment: https://git.openjdk.org/jdk/pull/29835#discussion_r2834400678

From lancea at openjdk.org  Fri Feb 20 18:08:59 2026
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 20 Feb 2026 18:08:59 GMT
Subject: RFR: 8377992: (zipfs) Align ZipFileSystem END header validation
 with the ZipFile implementation [v2]
In-Reply-To: <jbBil_B07PotomaIOfzb5ecf9BSBRGvN88-2I0NbIfk=.47162c2c-23df-4559-b12c-59f8b23846b1@github.com>
References: <1tONCY1QoXxaeUtr3LE4YoZk0UitQ5NqadNJOPFjREQ=.9b237170-fb07-4713-82fb-26b968b268de@github.com>
 <jbBil_B07PotomaIOfzb5ecf9BSBRGvN88-2I0NbIfk=.47162c2c-23df-4559-b12c-59f8b23846b1@github.com>
Message-ID: <o2wN7WOYY-3pSVQJ5k81IwOXhYIMZoVUtmQzoyb4LMU=.ff9bff09-fb6c-4512-9878-20fcfa58ede2@github.com>

On Thu, 19 Feb 2026 18:44:32 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`.
>> 
>> This brings two validation checks over to `ZipFileSystem`:
>> 
>> * Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746)
>> * Rejection of END headers with a total entry count which cannot fit within the CEN byte array  (JDK-8341625)
>> 
>> Test vector setup in `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is extracted to a new test lib utility class `jdk.test.lib.util.ZipUtils`. `EndOfCenValidation` is then copied to `test/jdk/jdk/nio/zipfs` and adjusted to test `ZipFileSystem` instead of `ZipFile`.
>> 
>> Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries.  Similar adjustments to `ZipFile` was done in JDK-8341625.
>> 
>> `ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Replace ZipFile reference in clas comment with ZipFileSystem
>  - Remove spurious '*'
>  - Extract test vector setup into ZipUtils class reusable across ZipFile/ZipFileSystem tests

test/jdk/jdk/nio/zipfs/EndOfCenValidation.java line 31:

> 29:  * @run junit/othervm EndOfCenValidation
> 30:  */
> 31: 

Here is an example of a blank line some might ask to have removed

test/jdk/jdk/nio/zipfs/EndOfCenValidation.java line 88:

> 86:     public void shouldRejectTooLargeCenSize() throws IOException {
> 87:         int size = MAX_CEN_SIZE + 1;
> 88: 

Another blank line example.

Again, I don't have a strong preference, but I have been asked in some PRs to consider it.

I wouldn't rush to do anything, my comment was more of an fyi

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29747#discussion_r2834464258
PR Review Comment: https://git.openjdk.org/jdk/pull/29747#discussion_r2834469721

From eirbjo at openjdk.org  Fri Feb 20 18:28:54 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 20 Feb 2026 18:28:54 GMT
Subject: RFR: 8377992: (zipfs) Align ZipFileSystem END header validation
 with the ZipFile implementation [v3]
In-Reply-To: <1tONCY1QoXxaeUtr3LE4YoZk0UitQ5NqadNJOPFjREQ=.9b237170-fb07-4713-82fb-26b968b268de@github.com>
References: <1tONCY1QoXxaeUtr3LE4YoZk0UitQ5NqadNJOPFjREQ=.9b237170-fb07-4713-82fb-26b968b268de@github.com>
Message-ID: <6-UkqPxno7fpp6z_oO9l81t85YxdpsjkL0nr-_qlx0A=.46fd285e-5be7-49e7-a068-f0c4bd536a36@github.com>

> Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`.
> 
> This brings two validation checks over to `ZipFileSystem`:
> 
> * Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746)
> * Rejection of END headers with a total entry count which cannot fit within the CEN byte array  (JDK-8341625)
> 
> Test vector setup in `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is extracted to a new test lib utility class `jdk.test.lib.util.ZipUtils`. `EndOfCenValidation` is then copied to `test/jdk/jdk/nio/zipfs` and adjusted to test `ZipFileSystem` instead of `ZipFile`.
> 
> Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries.  Similar adjustments to `ZipFile` was done in JDK-8341625.
> 
> `ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Dial down on blank lines as vertical space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29747/files
  - new: https://git.openjdk.org/jdk/pull/29747/files/d6fc0aee..89cb85f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29747&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29747&range=01-02

  Stats: 26 lines in 3 files changed: 0 ins; 26 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29747.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29747/head:pull/29747

PR: https://git.openjdk.org/jdk/pull/29747

From eirbjo at openjdk.org  Fri Feb 20 18:28:56 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 20 Feb 2026 18:28:56 GMT
Subject: RFR: 8377992: (zipfs) Align ZipFileSystem END header validation
 with the ZipFile implementation [v2]
In-Reply-To: <o2wN7WOYY-3pSVQJ5k81IwOXhYIMZoVUtmQzoyb4LMU=.ff9bff09-fb6c-4512-9878-20fcfa58ede2@github.com>
References: <1tONCY1QoXxaeUtr3LE4YoZk0UitQ5NqadNJOPFjREQ=.9b237170-fb07-4713-82fb-26b968b268de@github.com>
 <jbBil_B07PotomaIOfzb5ecf9BSBRGvN88-2I0NbIfk=.47162c2c-23df-4559-b12c-59f8b23846b1@github.com>
 <o2wN7WOYY-3pSVQJ5k81IwOXhYIMZoVUtmQzoyb4LMU=.ff9bff09-fb6c-4512-9878-20fcfa58ede2@github.com>
Message-ID: <5VeJewKTjrbrL7TBL5JjfBB8INazrO-97mv6F4pOHZQ=.51351c07-bbc8-47f1-a950-669f69a837de@github.com>

On Fri, 20 Feb 2026 18:05:36 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Replace ZipFile reference in clas comment with ZipFileSystem
>>  - Remove spurious '*'
>>  - Extract test vector setup into ZipUtils class reusable across ZipFile/ZipFileSystem tests
>
> test/jdk/jdk/nio/zipfs/EndOfCenValidation.java line 88:
> 
>> 86:     public void shouldRejectTooLargeCenSize() throws IOException {
>> 87:         int size = MAX_CEN_SIZE + 1;
>> 88: 
> 
> Another blank line example.
> 
> Again, I don't have a strong preference, but I have been asked in some PRs to consider it.
> 
> I wouldn't rush to do anything, my comment was more of an fyi

Thanks Lance, I pushed a commit which reduces some of the excessive vertical space. 

I kept the line following the jtreg comment section since this seems to be very common and I prefer some separation before the import section.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29747#discussion_r2834538507

From duke at openjdk.org  Fri Feb 20 18:29:00 2026
From: duke at openjdk.org (cdw200806)
Date: Fri, 20 Feb 2026 18:29:00 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
Message-ID: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>

"In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red."

-------------

Commit messages:
 - Update ConcurrentHashMap.java

Changes: https://git.openjdk.org/jdk/pull/24612/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24612&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378354
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24612.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24612/head:pull/24612

PR: https://git.openjdk.org/jdk/pull/24612

From dl at openjdk.org  Fri Feb 20 18:29:00 2026
From: dl at openjdk.org (Doug Lea)
Date: Fri, 20 Feb 2026 18:29:00 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
References: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
Message-ID: <l-XI-fDOK8VyMrw4oLnKVOHNAWhu9fWAdKDvOPO3mjY=.6ad96ec8-fb38-4413-8fca-cb2fdb20c97e@github.com>

On Sun, 13 Apr 2025 10:31:34 GMT, cdw200806 <duke at openjdk.org> wrote:

> "In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red."

Thanks for spotting the faulty assertion! It's surprising that this has never triggered in tests.

-------------

Marked as reviewed by dl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24612#pullrequestreview-3832266970

From liach at openjdk.org  Fri Feb 20 18:29:01 2026
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Feb 2026 18:29:01 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
References: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
Message-ID: <zs06q7SzdjMoBSnezTsIha_UQiDpzOWsQQ4PHZKfTbo=.da4d28d3-2227-4d62-9544-141af6ca6645@github.com>

On Sun, 13 Apr 2025 10:31:34 GMT, cdw200806 <duke at openjdk.org> wrote:

> "In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red."

Marked as reviewed by liach (Reviewer).

Makes sense. Since this is assertion code, there is really no way to add a test...

-------------

PR Review: https://git.openjdk.org/jdk/pull/24612#pullrequestreview-3833597386
PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-2800009831

From duke at openjdk.org  Fri Feb 20 18:29:01 2026
From: duke at openjdk.org (cdw200806)
Date: Fri, 20 Feb 2026 18:29:01 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
References: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
Message-ID: <s2q29g07iEehlerMrb5UgEwDk_js-eDQJKNoMBK27WE=.22283160-5f61-4c91-a7e3-46baa8c186d8@github.com>

On Sun, 13 Apr 2025 10:31:34 GMT, cdw200806 <duke at openjdk.org> wrote:

> "In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red."

????????????????????????????????????????????????????????????????????????????????????????

I have signed oca. But maybe the reviewer has not handle it yet.

????????????????????????????????????????????????????????????????????????????????????????

????????????????????????????????????????????????????????????????????????????????????????

????????????????????????????????????????????????????????????????????????????????????????

????????????????????????????????????????????????????????????????????????????????????????

????????????????????????????????????????????????????????????????????????????????????????

????????????????????????????????????????????????????????????????????????????????????????

????????????????????????????????????????????????????????????????????????????????????????

????????????????????????????????????????????????????????????????????????????????????????

????????????????????????????????????????????????????????????????????????????????????????

????????????????????????????????????????????????????????????????????????????????????????

????????????????????????????????????????????????????????????????????????????????????????

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-2799897820
PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-2799899020
PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-2874602240
PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-2957624444
PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3047313514
PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3153730755
PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3244175460
PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3353716764
PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3459499808
PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3584441420
PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3691171111
PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3783256600
PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3928387616

From duke at openjdk.org  Fri Feb 20 18:29:02 2026
From: duke at openjdk.org (cdw200806)
Date: Fri, 20 Feb 2026 18:29:02 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <zs06q7SzdjMoBSnezTsIha_UQiDpzOWsQQ4PHZKfTbo=.da4d28d3-2227-4d62-9544-141af6ca6645@github.com>
References: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
 <zs06q7SzdjMoBSnezTsIha_UQiDpzOWsQQ4PHZKfTbo=.da4d28d3-2227-4d62-9544-141af6ca6645@github.com>
Message-ID: <x8GPCKcWkht62D0rpLxHw1nbjUgu3dgoKYBHyPF7fnM=.94b35017-eb25-43df-91f6-406baa9742d3@github.com>

On Sun, 13 Apr 2025 16:02:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Makes sense. Since this is assertion code, there is really no way to add a test...

Hi, Chen Liang
After half year, finally I pass the oca process.
Do you know who can help me review this pr? 
And, seems this pr need a ticket number before merge it. I don't know how to get it. 
Contributing to JDK is a interesting thing. But If this pr not need merge, I can close it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3466115598

From jpai at openjdk.org  Fri Feb 20 18:29:05 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 20 Feb 2026 18:29:05 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <s2q29g07iEehlerMrb5UgEwDk_js-eDQJKNoMBK27WE=.22283160-5f61-4c91-a7e3-46baa8c186d8@github.com>
References: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
 <s2q29g07iEehlerMrb5UgEwDk_js-eDQJKNoMBK27WE=.22283160-5f61-4c91-a7e3-46baa8c186d8@github.com>
Message-ID: <swv7GSTvc8AUEbyIosr3OGgiwW-L_uwULHsjIj8VtEE=.7aba9570-649b-4ea0-a144-8f9b2cf82540@github.com>

On Thu, 19 Feb 2026 16:33:07 GMT, cdw200806 <duke at openjdk.org> wrote:

>> "In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red."
>
> ????????????????????????????????????????????????????????????????????????????????????????

Hello @cdw200806,

> And, seems this pr need a ticket number before merge it. I don't know how to get it.
> Contributing to JDK is a interesting thing. But If this pr not need merge, I can close it.

The OpenJDK contribution guide has details on how to propose changes to the JDK https://openjdk.org/guide/. For a change like this, that doesn't have a corresponding JBS issue already filed, the suggestion is to first ask in a relevant mailing list whether the change is worth doing. Can you create a discussion in the concurrency-dev mailing list https://mail.openjdk.org/mailman/listinfo/concurrency-discuss and explain what this change is about? The mailing list requires subscription, so please subscribe before posting. That mailing list link has details on how to subscribe.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3934657893

From alanb at openjdk.org  Fri Feb 20 18:29:05 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Feb 2026 18:29:05 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
References: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
Message-ID: <RnB0n6wiz9yELdc1g4ZafxUDrgAInySmJpwotkFaG3k=.4fa6f76f-4c24-4ef5-a327-d8924e1cab0c@github.com>

On Sun, 13 Apr 2025 10:31:34 GMT, cdw200806 <duke at openjdk.org> wrote:

> "In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red."

We should create an issue in JBS for this. The tests run with -esa so I would expect checkInvariants is run a lot in testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3935156711

From jpai at openjdk.org  Fri Feb 20 18:29:06 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 20 Feb 2026 18:29:06 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <RnB0n6wiz9yELdc1g4ZafxUDrgAInySmJpwotkFaG3k=.4fa6f76f-4c24-4ef5-a327-d8924e1cab0c@github.com>
References: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
 <RnB0n6wiz9yELdc1g4ZafxUDrgAInySmJpwotkFaG3k=.4fa6f76f-4c24-4ef5-a327-d8924e1cab0c@github.com>
Message-ID: <hgTPD73vbgs03_6yxzFoiPSAKaEQoyWG-BpdikQCS4I=.357593f5-12fa-4bc0-8a5c-ca338b1a2068@github.com>

On Fri, 20 Feb 2026 14:22:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> We should create an issue in JBS for this. 

I've now filed https://bugs.openjdk.org/browse/JDK-8378354.

@cdw200806, please update the title of this PR to `8378354: Faulty assertion in checkInvariants method of ConcurrentHashMap` to initiate an official review of this change. Please also merge the latest changes from master branch into this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3935474761

From liach at openjdk.org  Fri Feb 20 18:29:07 2026
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Feb 2026 18:29:07 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <l-XI-fDOK8VyMrw4oLnKVOHNAWhu9fWAdKDvOPO3mjY=.6ad96ec8-fb38-4413-8fca-cb2fdb20c97e@github.com>
References: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
 <l-XI-fDOK8VyMrw4oLnKVOHNAWhu9fWAdKDvOPO3mjY=.6ad96ec8-fb38-4413-8fca-cb2fdb20c97e@github.com>
Message-ID: <YVm4Peoyf9eO_lvQIr5onrRPOlLu3Uwam9jhERBRDyY=.174f832b-dacc-4d11-aa00-0da5d7d5d6e6@github.com>

On Fri, 20 Feb 2026 14:18:37 GMT, Doug Lea <dl at openjdk.org> wrote:

> It's surprising that this has never triggered in tests.

The faulty assertion was weaker than the desired one: the desired assertion ensures there is no consecutive red nodes, while the faulty assertion checks there is no red node with both children being red.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3936422803

From duke at openjdk.org  Fri Feb 20 18:38:11 2026
From: duke at openjdk.org (cdw200806)
Date: Fri, 20 Feb 2026 18:38:11 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <hgTPD73vbgs03_6yxzFoiPSAKaEQoyWG-BpdikQCS4I=.357593f5-12fa-4bc0-8a5c-ca338b1a2068@github.com>
References: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
 <RnB0n6wiz9yELdc1g4ZafxUDrgAInySmJpwotkFaG3k=.4fa6f76f-4c24-4ef5-a327-d8924e1cab0c@github.com>
 <hgTPD73vbgs03_6yxzFoiPSAKaEQoyWG-BpdikQCS4I=.357593f5-12fa-4bc0-8a5c-ca338b1a2068@github.com>
Message-ID: <PJfa9UDZnihNPackwOZBjQEgSqlIaS_jd-H_UFwBix4=.c5ae7d02-f78a-4b15-a458-f777db28bf52@github.com>

On Fri, 20 Feb 2026 15:05:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > We should create an issue in JBS for this.
> 
> I've now filed https://bugs.openjdk.org/browse/JDK-8378354.
> 
> @cdw200806, please update the title of this PR to `8378354: Faulty assertion in checkInvariants method of ConcurrentHashMap` to initiate an official review of this change. Please also merge the latest changes from master branch into this PR.

@jaikiran @DougLea @AlanBateman @liach 

Hi Colleagues in JDK, I also have another findings, but it is hard to fix. So I just mention here, please check. If you decide to raise a ticket to me, please share the ticket number to me, thanks. 

        Run this 4 line code in a main() method, JDK will throw StackOverflowError caused by recursion.
        Before throw err, the console print "{(this Map)=Some String}"


        ConcurrentHashMap map = new ConcurrentHashMap();
        map.put(map, "Some String");
        System.out.println(map);
        map.put(map, "Some String");

        The toString() method  of ConcurrentHashMap seems to fixed this issue by replace this map to "(this Map)" .
        But for hashCode() method of ConcurrentHashMap, it seems has not consider the recursion case.

        Why hard to fix: consider this case, the key has recursion it self, it will throw StackOverflowError too.
        ConcurrentHashMap map = new ConcurrentHashMap();
        Map map2 = new HashMap();
        map2.put(map2, "Some String");
        map.put(map2, "Some String");

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3936476482

From jlu at openjdk.org  Fri Feb 20 18:45:48 2026
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 20 Feb 2026 18:45:48 GMT
Subject: RFR: 8378111: Migrate java/util/jar tests to JUnit [v2]
In-Reply-To: <3Dj74Ia5qhHUFkKw4DaZAU96ka6BA1krEaZjukcmY54=.ba525041-8821-4ad1-97ed-b1d8b4c36f81@github.com>
References: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
 <3Dj74Ia5qhHUFkKw4DaZAU96ka6BA1krEaZjukcmY54=.ba525041-8821-4ad1-97ed-b1d8b4c36f81@github.com>
Message-ID: <7Th7vNV04UK-f36ATlj0YeRdckTI4ma-yB1Inh9h0Lc=.958bcf21-ccc3-44d1-808a-f79a93dd4c26@github.com>

On Thu, 19 Feb 2026 21:12:41 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Eirik comments
>>  - Naoto comment
>>  - Andrey comments
>
> test/jdk/java/util/jar/Manifest/IncludeInExceptionsTest.java line 47:
> 
>> 45:  * @run junit/othervm -Djdk.includeInExceptions=jar IncludeInExceptionsTest
>> 46:  * @run junit/othervm IncludeInExceptionsTest
>> 47:  * @summary Verify that the property jdk.net.includeInExceptions works as expected
> 
> `jdk.net.includeInExceptions` is not the property being tested here, should be `jdk.includeInExceptions` ?

Thanks for the review and helpful comments!

Looks like this property was renamed in [JDK-8207846](https://bugs.openjdk.org/browse/JDK-8207846).

> test/jdk/java/util/jar/TestExtra.java line 78:
> 
>> 76:     @Test
>> 77:     void extraHeaderPlusDataTest() throws IOException {
>> 78:         new TestExtra().testHeaderPlusData();
> 
> Consider letting JUnit handle the instance state management  to avoid these wrapper test methods.

The reason I wrapped those tests was to control the executing test class, (i.e. `TestExtra` vs `TestJarExtra`). However, you are right that it's clutter and also doubling the instances. Keeping the inner `TestJarExtra` class is problematic because in its current `static` form, tests have to be run by the outer class leading to the manual ctors. If we make it a non static inner class and use `@nested` it causes a JUnit cycle error for the class hierarchy since the inner class also extends the outer class.

I pulled `TestJarExtra` into its own test file which gets rid of the manual instance handling and is cleaner.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2834609443
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2834609236

From jlu at openjdk.org  Fri Feb 20 18:45:44 2026
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 20 Feb 2026 18:45:44 GMT
Subject: RFR: 8378111: Migrate java/util/jar tests to JUnit [v2]
In-Reply-To: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
References: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
Message-ID: <TItny6dhgHH78eRRoceU7QK-sGGfV9FGx9jM3qWFIiA=.67e42f1e-1ae2-4058-b92d-f7a56876e734@github.com>

> This PR migrates the java/util/jar tests to use _JUnit_.
> 
> https://github.com/openjdk/jdk/commit/afe0aeee746bccbbe4bc6c9a8cd2302228ecc2f6 includes changes for _testNG_ based tests.
> https://github.com/openjdk/jdk/commit/c5a7f75840f96fa77ec3ed7faa713990adb84de6 includes changes for `main` based tests.
> 
> Before: Framework-based tests: 125 = 125 TestNG + 0 JUnit.
> After: Framework-based tests: 174 = 0 TestNG + 174 JUnit

Justin Lu has updated the pull request incrementally with three additional commits since the last revision:

 - Eirik comments
 - Naoto comment
 - Andrey comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29828/files
  - new: https://git.openjdk.org/jdk/pull/29828/files/c5a7f758..c55c722d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29828&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29828&range=00-01

  Stats: 335 lines in 13 files changed: 148 ins; 125 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/29828.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29828/head:pull/29828

PR: https://git.openjdk.org/jdk/pull/29828

From eirbjo at openjdk.org  Fri Feb 20 19:04:18 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 20 Feb 2026 19:04:18 GMT
Subject: RFR: 8378111: Migrate java/util/jar tests to JUnit [v2]
In-Reply-To: <TItny6dhgHH78eRRoceU7QK-sGGfV9FGx9jM3qWFIiA=.67e42f1e-1ae2-4058-b92d-f7a56876e734@github.com>
References: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
 <TItny6dhgHH78eRRoceU7QK-sGGfV9FGx9jM3qWFIiA=.67e42f1e-1ae2-4058-b92d-f7a56876e734@github.com>
Message-ID: <R1qZtrLLaO-gToPOXV-5vQSKXPDrjsuc36T-YBBWS0s=.6a4359e2-9677-4591-9178-86d189a1f222@github.com>

On Fri, 20 Feb 2026 18:45:44 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR migrates the java/util/jar tests to use _JUnit_.
>> 
>> https://github.com/openjdk/jdk/commit/afe0aeee746bccbbe4bc6c9a8cd2302228ecc2f6 includes changes for _testNG_ based tests.
>> https://github.com/openjdk/jdk/commit/c5a7f75840f96fa77ec3ed7faa713990adb84de6 includes changes for `main` based tests.
>> 
>> Before: Framework-based tests: 125 = 125 TestNG + 0 JUnit.
>> After: Framework-based tests: 174 = 0 TestNG + 174 JUnit
>
> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Eirik comments
>  - Naoto comment
>  - Andrey comments

test/jdk/java/util/jar/TestExtra.java line 29:

> 27:  * @summary Test that client-provided data in the extra field is written and
> 28:  * read correctly, taking into account the JAR_MAGIC written into the extra
> 29:  * field of the first entry of JAR files. Zip file specific.

We have been trying to use uppercase ZIP when refering to files and specifications.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2834673333

From eirbjo at openjdk.org  Fri Feb 20 19:23:23 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 20 Feb 2026 19:23:23 GMT
Subject: RFR: 8378111: Migrate java/util/jar tests to JUnit [v2]
In-Reply-To: <7Th7vNV04UK-f36ATlj0YeRdckTI4ma-yB1Inh9h0Lc=.958bcf21-ccc3-44d1-808a-f79a93dd4c26@github.com>
References: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
 <3Dj74Ia5qhHUFkKw4DaZAU96ka6BA1krEaZjukcmY54=.ba525041-8821-4ad1-97ed-b1d8b4c36f81@github.com>
 <7Th7vNV04UK-f36ATlj0YeRdckTI4ma-yB1Inh9h0Lc=.958bcf21-ccc3-44d1-808a-f79a93dd4c26@github.com>
Message-ID: <RwTGLYiTExksOIPHZeCkXcixhbMMY6t2cK4t4zAnbcs=.f79b341a-1908-4b04-aafb-f5f9d31dae37@github.com>

On Fri, 20 Feb 2026 18:42:35 GMT, Justin Lu <jlu at openjdk.org> wrote:

> I pulled `TestJarExtra` into its own test file which gets rid of the manual instance handling and is cleaner.

Thanks for making this cleaner!

Ideally I would like to see these broken up into self-contained tests. The inheritance here just seems like implementation sharing without any real benefits. It just makes it harder to tell where things come from and prevents the tests from "telling a story". 

But yeah, that's probably outside of this JUnit conversion PR; I think you've done a good job already!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2834745684

From rriggs at openjdk.org  Fri Feb 20 20:04:50 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 20 Feb 2026 20:04:50 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
References: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
Message-ID: <lLWBVt2PEc6rlXPZWnhAZu5-aJcscInn_RxLEBvNd8A=.90e7c52b-3091-48d4-ba31-26bfcb6d4ab7@github.com>

On Sun, 13 Apr 2025 10:31:34 GMT, cdw200806 <duke at openjdk.org> wrote:

> "In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red."

Please describe the semantic impact of the violated assertion. Would it ever be observable?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3936854687

From rriggs at openjdk.org  Fri Feb 20 20:11:21 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 20 Feb 2026 20:11:21 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
References: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
Message-ID: <yQpsh6QFz_heHp7UIBz1S4EHkg-1lmarw88RlhRc5fM=.c134ae07-133e-4247-be4d-2c7fb1d5be50@github.com>

On Sun, 13 Apr 2025 10:31:34 GMT, cdw200806 <duke at openjdk.org> wrote:

> "In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red."

It is a common case when a data structure contains cycles; when it is expensive to detect and avoid the cycle, the burden is on the user to avoid creating the cycle or to avoid calling functions that do not know when to quit.  StackOverflow is the warning that a design or api principle has been violated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3936889888

From duke at openjdk.org  Fri Feb 20 20:26:46 2026
From: duke at openjdk.org (cdw200806)
Date: Fri, 20 Feb 2026 20:26:46 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <lLWBVt2PEc6rlXPZWnhAZu5-aJcscInn_RxLEBvNd8A=.90e7c52b-3091-48d4-ba31-26bfcb6d4ab7@github.com>
References: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
 <lLWBVt2PEc6rlXPZWnhAZu5-aJcscInn_RxLEBvNd8A=.90e7c52b-3091-48d4-ba31-26bfcb6d4ab7@github.com>
Message-ID: <XjqgkPLZWUHz7tXUs5IBUU1aqCdOEnPa3JJki4H4kaQ=.58a1a0cc-08ae-4586-9d4f-5c1375bdf96d@github.com>

On Fri, 20 Feb 2026 20:02:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Please describe the semantic impact of the violated assertion. Would it ever be observable?

If concurrent map use red-black-tree correctly(or use it normally as common red-balck-tree algorithm), this bug will never be observable.
In the logic, It just like the old code assert 1 is a Object, but I fix it to 1 is a Integer. More correctly( if 1 is a String it will throw error) , but the old code is not a "bug" , will never throw error(if the tree is build and use correct). I find it by code review.

This assert just like a ut lack some of branch,a ut not perfect, if the red-black-tree operation code is wrong and some case  not as expect happen and it will not aware,but if the code run correctly, maybe it not need to fix, it decide by your team. 

@RogerRiggs

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3936977232

From psandoz at openjdk.org  Fri Feb 20 21:48:10 2026
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 20 Feb 2026 21:48:10 GMT
Subject: RFR: 8377438: [VectorAPI] Add new carrier type to LaneType class
 [v2]
In-Reply-To: <qmSybXnaUH8CxOjqOJwhdINd_GhiWX6OlG8ABL1GScE=.fe7f9703-d35a-475f-9e85-ed9063f3648d@github.com>
References: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
 <qmSybXnaUH8CxOjqOJwhdINd_GhiWX6OlG8ABL1GScE=.fe7f9703-d35a-475f-9e85-ed9063f3648d@github.com>
Message-ID: <n4RmcoS6Glr23HBLlw4xA359-W-9_QijIeMqRpj2S3c=.0e4be8ab-14f5-44d5-a5d5-a9e56e5786fb@github.com>

On Thu, 19 Feb 2026 12:02:27 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
>> 
>> With Float16 we need to differentiate b/w vector lane element type and carrier type. while element type corresponds to exact type of lane i.e. Float16.class, carrier type corresponds to the storage type required to propagate IEEE 754 float16 values to inline expander.
>> 
>> Patch adds a new carrier type to existing LaneType structure and use it for following purpose.
>>  - To compute preferred shape of vector.
>>  - To allocate vector backing storage during dummy vector and iota array creation.
>>  - Sanity checking to ensure vector lane type is a primitive type in inline expander.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8377438
>  - 8377438: [VectorAPI] Add new carrier type to LaneType class

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/gen-src.sh line 76:

> 74:   Boxfptype=$Boxtype
> 75:   carriertype=$type
> 76:   Carriertype=$Type

Is the boxed type of the carrier type used?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29629#discussion_r2835215603

From mikael at openjdk.org  Fri Feb 20 22:44:58 2026
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 20 Feb 2026 22:44:58 GMT
Subject: RFR: 8377905: gcc.md included with every build
Message-ID: <f1qzTvHdFh3IAW1BuGx8lr-rBqRee2QNE9eX0Au9wP8=.a225fa30-7718-4194-a7c2-0a17f78f63e3@github.com>

JDK-8377509 added the gcc.md license file. Unfortunately the file is unconditionally in the built JDK regardless of the toolchain used. This change updates the build logic to only include the file when relevant.

Testing: tier1, builds-tier[2-5], manual verification to ensure the file is only included where expected.

-------------

Commit messages:
 - 8377905: gcc.md included with every build

Changes: https://git.openjdk.org/jdk/pull/29853/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29853&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377905
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29853.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29853/head:pull/29853

PR: https://git.openjdk.org/jdk/pull/29853

From ysuenaga at openjdk.org  Fri Feb 20 23:32:46 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 20 Feb 2026 23:32:46 GMT
Subject: RFR: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to
 intrinsify [v2]
In-Reply-To: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
References: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
Message-ID: <rHl0Xe45FSnixhnp8MDWoaKUBNhFd1avQjDHgdW1aVQ=.baed1460-d50b-46f2-9602-3533639ac679@github.com>

> I ran following code with `-Djdk.incubator.vector.DEBUG=true`, however it was not intrinsified.
> 
> 
>   public static void cos(){
>     var rand = new Random();
>     for(int i = 0; i < 1_000_000; i++){
>       var vec = DoubleVector.fromArray(DoubleVector.SPECIES_256, rand.doubles().limit(4).toArray(), 0);
> 
>       vec.lanewise(VectorOperators.COS);
>     }
>   }
> 
> 
> I knew `__jsvml_cos4_ha_l9()` in libjsvml.so should be called in this case (via vector debug log), but it was not hitted even though I set breakpoint in it.
> 
> `LaneType` has been introduced in [JDK-8376187](https://bugs.openjdk.org/browse/JDK-8376187), and `LibraryCallKit::inline_vector_call()` was updated to handle lane type rather than class of element type. However `VectorMathLibrary` wasn't modified.
> 
> I confirmed `__jsvml_cos4_ha_l9()` is called with this fix, and also all jdk/jdk/incubator/vector jtreg tests passed on Linux AMD64.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Change method signature to AbstractSpecies

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29835/files
  - new: https://git.openjdk.org/jdk/pull/29835/files/c84892e6..3b2b5073

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29835&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29835&range=00-01

  Stats: 10 lines in 3 files changed: 0 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/29835.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29835/head:pull/29835

PR: https://git.openjdk.org/jdk/pull/29835

From ysuenaga at openjdk.org  Fri Feb 20 23:32:49 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 20 Feb 2026 23:32:49 GMT
Subject: RFR: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to
 intrinsify [v2]
In-Reply-To: <f-kgblEMFVWfgILa2OnOQqZFwv-5WGmaDdqGKKmCWYQ=.b55db16d-2245-4725-b129-63213e4c696d@github.com>
References: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
 <f-kgblEMFVWfgILa2OnOQqZFwv-5WGmaDdqGKKmCWYQ=.b55db16d-2245-4725-b129-63213e4c696d@github.com>
Message-ID: <yJuA1-JIr1UGsQrkMoJvDyLY4b05nJRUXvQbnkaQ4tg=.cd932827-7832-44ff-9250-b81572e326be@github.com>

On Fri, 20 Feb 2026 17:51:56 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> We need an IR test, could you investigate if that is possible? 

I do not know how do I do... sorry.

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java line 295:
> 
>> 293:             @SuppressWarnings({"unchecked"})
>> 294:             Class<V> vt = (Class<V>)vspecies.vectorType();
>> 295:             AbstractSpecies<E> asp = (AbstractSpecies<E>)vspecies;
> 
> Instead change method signature to use `AbstractSpecies<E>` (from `VectorSpecies<E>`) and at the call site change the argument to be result of `vspecies()` (from `species()`).

Fixed in new commit.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29835#issuecomment-3937631816
PR Review Comment: https://git.openjdk.org/jdk/pull/29835#discussion_r2835486757

From erikj at openjdk.org  Fri Feb 20 23:47:16 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 20 Feb 2026 23:47:16 GMT
Subject: RFR: 8377905: gcc.md included with every build
In-Reply-To: <f1qzTvHdFh3IAW1BuGx8lr-rBqRee2QNE9eX0Au9wP8=.a225fa30-7718-4194-a7c2-0a17f78f63e3@github.com>
References: <f1qzTvHdFh3IAW1BuGx8lr-rBqRee2QNE9eX0Au9wP8=.a225fa30-7718-4194-a7c2-0a17f78f63e3@github.com>
Message-ID: <6iJ9KM3u7Aap-cMFQdfus1oo4EFibUZ2xPa69grSWLQ=.c77345c0-8a54-49d2-8c33-031c88af2392@github.com>

On Fri, 20 Feb 2026 22:38:20 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> JDK-8377509 added the gcc.md license file. Unfortunately the file is unconditionally in the built JDK regardless of the toolchain used. This change updates the build logic to only include the file when relevant.
> 
> Testing: tier1, builds-tier[2-5], manual verification to ensure the file is only included where expected.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29853#pullrequestreview-3834648917

From swen at openjdk.org  Fri Feb 20 23:48:47 2026
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 20 Feb 2026 23:48:47 GMT
Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter
 parsing to improve performance [v8]
In-Reply-To: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
Message-ID: <9HVKkbAITdivUnZ3mH_gZg40W8sf94uzpGo7rOm1pdM=.2ae56df0-4b57-472a-ae5b-5746cf20e8c1@github.com>

> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.
> 
> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
> 
> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
> 
> Parsing scenarios show improvements from 12% to 95%

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  copyright 2026

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28471/files
  - new: https://git.openjdk.org/jdk/pull/28471/files/9a13e51e..bf26159a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28471&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28471&range=06-07

  Stats: 7 lines in 5 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28471.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28471/head:pull/28471

PR: https://git.openjdk.org/jdk/pull/28471

From jsjolen at openjdk.org  Fri Feb 20 23:57:26 2026
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 20 Feb 2026 23:57:26 GMT
Subject: RFR: 8377905: gcc.md included with every build
In-Reply-To: <f1qzTvHdFh3IAW1BuGx8lr-rBqRee2QNE9eX0Au9wP8=.a225fa30-7718-4194-a7c2-0a17f78f63e3@github.com>
References: <f1qzTvHdFh3IAW1BuGx8lr-rBqRee2QNE9eX0Au9wP8=.a225fa30-7718-4194-a7c2-0a17f78f63e3@github.com>
Message-ID: <gaVPmwGk__TW9MWrUQfHZFLahgynxda2MTWIsryMhzM=.24cbe881-31fc-44f0-a060-4b4be15d1bc1@github.com>

On Fri, 20 Feb 2026 22:38:20 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> JDK-8377509 added the gcc.md license file. Unfortunately the file is unconditionally in the built JDK regardless of the toolchain used. This change updates the build logic to only include the file when relevant.
> 
> Testing: tier1, builds-tier[2-5], manual verification to ensure the file is only included where expected.

Marked as reviewed by jsjolen (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29853#pullrequestreview-3834663945

From prr at openjdk.org  Sat Feb 21 01:02:23 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 01:02:23 GMT
Subject: RFR: 8377905: gcc.md included with every build
In-Reply-To: <f1qzTvHdFh3IAW1BuGx8lr-rBqRee2QNE9eX0Au9wP8=.a225fa30-7718-4194-a7c2-0a17f78f63e3@github.com>
References: <f1qzTvHdFh3IAW1BuGx8lr-rBqRee2QNE9eX0Au9wP8=.a225fa30-7718-4194-a7c2-0a17f78f63e3@github.com>
Message-ID: <9c-pbmP9F9UYzGwdu8pBIsnSMQmFsIoBmJwTK9QNwCA=.fd2cf18d-903d-4244-aaa8-fd99994bd63e@github.com>

On Fri, 20 Feb 2026 22:38:20 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> JDK-8377509 added the gcc.md license file. Unfortunately the file is unconditionally in the built JDK regardless of the toolchain used. This change updates the build logic to only include the file when relevant.
> 
> Testing: tier1, builds-tier[2-5], manual verification to ensure the file is only included where expected.

LGTM.
This change seems very simple .. seems like it would be OK for 26 GA.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29853#pullrequestreview-3834745124

From jpai at openjdk.org  Sat Feb 21 02:16:11 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 21 Feb 2026 02:16:11 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <XjqgkPLZWUHz7tXUs5IBUU1aqCdOEnPa3JJki4H4kaQ=.58a1a0cc-08ae-4586-9d4f-5c1375bdf96d@github.com>
References: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
 <lLWBVt2PEc6rlXPZWnhAZu5-aJcscInn_RxLEBvNd8A=.90e7c52b-3091-48d4-ba31-26bfcb6d4ab7@github.com>
 <XjqgkPLZWUHz7tXUs5IBUU1aqCdOEnPa3JJki4H4kaQ=.58a1a0cc-08ae-4586-9d4f-5c1375bdf96d@github.com>
Message-ID: <3lbrCUIXfJWt5gbRatFP2N6XcmPj8av5UV1krRKEf8g=.62cb0782-564b-4b77-a643-09de84667736@github.com>

On Fri, 20 Feb 2026 20:23:27 GMT, cdw200806 <duke at openjdk.org> wrote:

>> Please describe the semantic impact of the violated assertion. Would it ever be observable?
>
>> Please describe the semantic impact of the violated assertion. Would it ever be observable?
> 
> If concurrent map use red-black-tree correctly(or use it normally as common red-balck-tree algorithm), this bug will never be observable.
> In the logic, It just like the old code assert 1 is a Object, but I fix it to 1 is a Integer. More correctly( if 1 is a String it will throw error) , but the old code is not a "bug" , will never throw error(if the tree is build and use correct). I find it by code review.
> 
> This assert just like a ut lack some of branch,a ut not perfect, if the red-black-tree operation code is wrong and some case  not as expect happen and it will not aware,but if the code run correctly, maybe it not need to fix, it decide by your team. 
> 
> @RogerRiggs

Hello @cdw200806, the line numbers in your change don't match the code in JDK master branch. Can you merge in the latest changes from master branch into yours and update this PR? I'm a bit surprised that the skara bots haven't tagged this PR with a merge-conflict label.

While at it please also enable GitHub Actions in your repo so that the GitHub actions test jobs get run in this PR. See the message here which explains what needs to be done https://github.com/openjdk/jdk/pull/24612/checks?check_run_id=40460799667.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3937937691

From duke at openjdk.org  Sat Feb 21 02:18:57 2026
From: duke at openjdk.org (Markus KARG)
Date: Sat, 21 Feb 2026 02:18:57 GMT
Subject: Integrated: 8377388: Replacing "new StringReader(String)" by
 "Reader.of(CharSequence);" in Scanner
In-Reply-To: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
References: <BYpl52Asr6DlUQrEfSjBrCvEwE1twiNTXOnU-U6-EPY=.9c69963f-874c-41d5-b1cb-5e79f401d004@github.com>
Message-ID: <kEGDhjEWaBS-wMWz8rzAD-YbQxlbgcoEMn6ORcCzI_o=.135414b9-1dd9-4930-8a12-eab8167f1cb8@github.com>

On Mon, 9 Feb 2026 07:33:03 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Request provides an implementation for [JDK-8377388](https://bugs.openjdk.org/browse/JDK-8377388): 'Replacing "new StringReader(String)" by "Reader.of(CharSequence);" in Scanner'.

This pull request has now been integrated.

Changeset: bc971b51
Author:    Markus KARG <markus at headcrashing.eu>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bc971b51b9a27b8b026f6fbbe1b0d49e7b702a6c
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8377388: Replacing "new StringReader(String)" by "Reader.of(CharSequence);" in Scanner

Reviewed-by: jpai, rriggs, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/29627

From dholmes at openjdk.org  Sat Feb 21 06:39:07 2026
From: dholmes at openjdk.org (David Holmes)
Date: Sat, 21 Feb 2026 06:39:07 GMT
Subject: RFR: 8377905: gcc.md included with every build
In-Reply-To: <f1qzTvHdFh3IAW1BuGx8lr-rBqRee2QNE9eX0Au9wP8=.a225fa30-7718-4194-a7c2-0a17f78f63e3@github.com>
References: <f1qzTvHdFh3IAW1BuGx8lr-rBqRee2QNE9eX0Au9wP8=.a225fa30-7718-4194-a7c2-0a17f78f63e3@github.com>
Message-ID: <1b1k1ibyUtYmImEUCHXKBWO9KZ6-NJrAp4XdalzYFic=.94989515-33ac-4aef-b1b4-22bae2481e82@github.com>

On Fri, 20 Feb 2026 22:38:20 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> JDK-8377509 added the gcc.md license file. Unfortunately the file is unconditionally in the built JDK regardless of the toolchain used. This change updates the build logic to only include the file when relevant.
> 
> Testing: tier1, builds-tier[2-5], manual verification to ensure the file is only included where expected.

Much simpler than I had anticipated.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29853#pullrequestreview-3835160056

From ysuenaga at openjdk.org  Sat Feb 21 07:55:02 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 21 Feb 2026 07:55:02 GMT
Subject: RFR: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to
 intrinsify [v3]
In-Reply-To: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
References: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
Message-ID: <2ZETD5VINau9XPTgVsTq6Z7aJovNUKrKhVuA3AeKsyM=.051f07e5-215f-4a4d-8102-095649760085@github.com>

> I ran following code with `-Djdk.incubator.vector.DEBUG=true`, however it was not intrinsified.
> 
> 
>   public static void cos(){
>     var rand = new Random();
>     for(int i = 0; i < 1_000_000; i++){
>       var vec = DoubleVector.fromArray(DoubleVector.SPECIES_256, rand.doubles().limit(4).toArray(), 0);
> 
>       vec.lanewise(VectorOperators.COS);
>     }
>   }
> 
> 
> I knew `__jsvml_cos4_ha_l9()` in libjsvml.so should be called in this case (via vector debug log), but it was not hitted even though I set breakpoint in it.
> 
> `LaneType` has been introduced in [JDK-8376187](https://bugs.openjdk.org/browse/JDK-8376187), and `LibraryCallKit::inline_vector_call()` was updated to handle lane type rather than class of element type. However `VectorMathLibrary` wasn't modified.
> 
> I confirmed `__jsvml_cos4_ha_l9()` is called with this fix, and also all jdk/jdk/incubator/vector jtreg tests passed on Linux AMD64.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Add test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29835/files
  - new: https://git.openjdk.org/jdk/pull/29835/files/3b2b5073..dd007253

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29835&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29835&range=01-02

  Stats: 67 lines in 2 files changed: 67 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29835.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29835/head:pull/29835

PR: https://git.openjdk.org/jdk/pull/29835

From ysuenaga at openjdk.org  Sat Feb 21 07:55:03 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 21 Feb 2026 07:55:03 GMT
Subject: RFR: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to
 intrinsify [v3]
In-Reply-To: <f-kgblEMFVWfgILa2OnOQqZFwv-5WGmaDdqGKKmCWYQ=.b55db16d-2245-4725-b129-63213e4c696d@github.com>
References: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
 <f-kgblEMFVWfgILa2OnOQqZFwv-5WGmaDdqGKKmCWYQ=.b55db16d-2245-4725-b129-63213e4c696d@github.com>
Message-ID: <ycU5WySH6ik6kKzuH1l800q-JrVb9UNdVNhyWAdi-EU=.8041f6ae-22a8-441f-a40e-83c4c8b0a16e@github.com>

On Fri, 20 Feb 2026 17:51:56 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test
>
> Thank you for catching this. We need an IR test, could you investigate if that is possible? Perhaps pick one unary op and one binary op to test.

@PaulSandoz I found the test which uses IR Test Framework. So I added the test with it. It works on my Linux AMD64. Is this what you intended?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29835#issuecomment-3938404634

From alanb at openjdk.org  Sat Feb 21 08:26:15 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Feb 2026 08:26:15 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
References: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
Message-ID: <fCXIOU3jLNJREK05euFAVhnmFX-1ajVkANXCJjJZ_ZI=.6fbff661-4afa-4331-8c43-e57e00a8af4b@github.com>

On Sun, 13 Apr 2025 10:31:34 GMT, cdw200806 <duke at openjdk.org> wrote:

> "In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red."

I've run tier1+tier2 with the tighter check and the assert checkInvariants didn't trip.

I agree with Jai that the PR branch should be sync'ed up as it's baseline is from 9 months ago.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3938444058

From alanb at openjdk.org  Sat Feb 21 08:44:10 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Feb 2026 08:44:10 GMT
Subject: RFR: 8376406: Avoid loading ArrayDeque in
 jdk.internal.loader.NativeLibraries [v2]
In-Reply-To: <pyBMGHFDDCUjNTbZ6RUqKf-wyoYPGEj52xUoeaikCl4=.addb63f8-92d7-429d-9fd2-7e4114dec82f@github.com>
References: <2MTsiQD0RsVBX6TxePBIKbc2ZKisC_BRIVNbh72MeJ4=.18bd1814-41c2-4250-9242-72bdcb113cb0@github.com>
 <tD6kIMyPSzSVbGGfXfi0QqLJRtsdhvvRtPJI7tw1C3A=.e50b6aa5-75ef-4cab-8e3b-6876385e87c1@github.com>
 <7uaDSKzIQWsg1FYwm1C1VlULuLnJ8wisVrqFxEd3th8=.bb4d5cd0-f030-4b25-9bec-ad313c8cc46f@github.com>
 <pyBMGHFDDCUjNTbZ6RUqKf-wyoYPGEj52xUoeaikCl4=.addb63f8-92d7-429d-9fd2-7e4114dec82f@github.com>
Message-ID: <-8gUOUcroB6WeenO1E93pvn5uOphn2mJdmxBsA37PEQ=.91500133-7cf6-4300-9fbe-70ee3c3c57ee@github.com>

On Fri, 20 Feb 2026 13:22:40 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 488:
>> 
>>> 486:                     new Function<>() {
>>> 487:                         public List<NativeLibraryImpl> apply(Thread t) {
>>> 488:                             return new ArrayList<>(8);
>> 
>> The `ArrayDeque()` constructor takes the number of "elements" whereas `ArrayList()` constructor takes the initial capacity. Having said that, I can't see why this `8` was used in the first place. It was introduced in https://bugs.openjdk.org/browse/JDK-8228336 and the review thread https://mail.openjdk.org/pipermail/core-libs-dev/2020-March/065194.html doesn't make a mention of it, so this initial number of elements may not be too critical in this code. If we are going to change this to an ArrayList, maybe we should just change this to `new ArrayList<>()`.
>> 
>> It would be good to hear from Alan @AlanBateman about this proposed change.
>
>> The `ArrayDeque()` constructor takes the number of "elements" whereas `ArrayList()` constructor takes the initial capacity. 
> 
> They both seem to allocate Object arrays to fit elements. ArrayList makes an array for 8 objects, ArrayDeque 8 + 1.
> 
>> Having said that, I can't see why this `8` was used in the first place. 
> 
> 
>> If we are going to change this to an ArrayList, maybe we should just change this to new ArrayList<>().
> 
> Sounds reasonable, that would allow `isEmpty()` checks on an empty list to avoid allocation. If that matters.

> It would be good to hear from Alan @AlanBateman about this proposed change.

It looks okay but fragile in the sense that ArrayDeque is widely used, it's just a question on when rather if it will be loaded. With going work on AOT and in Leyden then I hope we can be less concerned about doing these kinds of changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29432#discussion_r2835988721

From eirbjo at openjdk.org  Sat Feb 21 09:58:08 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 21 Feb 2026 09:58:08 GMT
Subject: RFR: 8376406: Avoid loading ArrayDeque in
 jdk.internal.loader.NativeLibraries [v2]
In-Reply-To: <-8gUOUcroB6WeenO1E93pvn5uOphn2mJdmxBsA37PEQ=.91500133-7cf6-4300-9fbe-70ee3c3c57ee@github.com>
References: <2MTsiQD0RsVBX6TxePBIKbc2ZKisC_BRIVNbh72MeJ4=.18bd1814-41c2-4250-9242-72bdcb113cb0@github.com>
 <tD6kIMyPSzSVbGGfXfi0QqLJRtsdhvvRtPJI7tw1C3A=.e50b6aa5-75ef-4cab-8e3b-6876385e87c1@github.com>
 <7uaDSKzIQWsg1FYwm1C1VlULuLnJ8wisVrqFxEd3th8=.bb4d5cd0-f030-4b25-9bec-ad313c8cc46f@github.com>
 <pyBMGHFDDCUjNTbZ6RUqKf-wyoYPGEj52xUoeaikCl4=.addb63f8-92d7-429d-9fd2-7e4114dec82f@github.com>
 <-8gUOUcroB6WeenO1E93pvn5uOphn2mJdmxBsA37PEQ=.91500133-7cf6-4300-9fbe-70ee3c3c57ee@github.com>
Message-ID: <6H_1ZS03J9sruUt80J_faNtKK8SzkP_Rywj837NPHuo=.a1bd4e24-3d03-46b3-a61f-e20ba35dbe11@github.com>

On Sat, 21 Feb 2026 08:41:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It looks okay but fragile in the sense that ArrayDeque is widely used, it's just a question on when rather if it will be loaded. 

Understood. My goal here and with the preceding ones in `ZipFile` and `URLClassPath` was to remove ArrayDeque from startup of a simple `java -cp file.jar` program. No plans to go hunting for more after this.   

Specifically for this change: Do you have any sense if `new ArrayList()` would be beneficial here, given that ArrayLIst provides lazy initialization of the elements array while ArrayDeque does not and allocates 17 elements per default constructor?

In other words, is it common for this stack to be empty?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29432#discussion_r2836034908

From eirbjo at gmail.com  Sat Feb 21 10:08:57 2026
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 21 Feb 2026 11:08:57 +0100
Subject: RFD: ArrayDeque bulk adds and lambda
Message-ID: <CA+pBWhuBF0gJVLnVvCDsAgoPMDTDVoVJ4mAG366PHAsiuX+59g@mail.gmail.com>

Hi,

While working on JDK-8375580, I noticed the following code and comment in
URLClassPath:

        // can't use ArrayDeque#addAll or new ArrayDeque(Collection);
    // it's too early in the bootstrap to trigger use of lambdas
    [..]
    for (int i = 0; i < size; i++)
        unopenedUrls.add(path.get(i));

This code avoids using bulk add operations on ArrayDeque, presumably to
work around problems caused by early initialization of lambda machinery.

And indeed, in ArrayDeque::copyElements, we find this:

         c.forEach(this::addLast);

While I don't know if the above code is still a concern, should we consider
replacing it with a simple for loop, like this:

        for (E e : c) {
        addLast(e);
    }

Can this make ArrayDeque somewhat safer to use in early bootstrap code?

Wdyt?

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260221/ccf273e9/attachment-0001.htm>

From eirbjo at gmail.com  Sat Feb 21 10:45:33 2026
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 21 Feb 2026 11:45:33 +0100
Subject: RFD: ArrayDeque bulk adds and lambda
In-Reply-To: <CA+pBWhuBF0gJVLnVvCDsAgoPMDTDVoVJ4mAG366PHAsiuX+59g@mail.gmail.com>
References: <CA+pBWhuBF0gJVLnVvCDsAgoPMDTDVoVJ4mAG366PHAsiuX+59g@mail.gmail.com>
Message-ID: <CA+pBWhvCxgKqtFi_H9BuB4X7=V6exkaBS=KCdba-4vUoR9xOaQ@mail.gmail.com>

On Sat, Feb 21, 2026 at 11:08?AM Eirik Bj?rsn?s <eirbjo at gmail.com> wrote:

Can this make ArrayDeque somewhat safer to use in early bootstrap code?
>

Adding some context from testing:

When modifying the mentioned code to not avoid the lambda bulk operation,
nothing crashes but the number of loaded classes during 'java -cp
hello.jar' is increased from 576 to 663. Here's a full list of extra
classes loaded:

88a89
> java.lang.NoSuchMethodException
148a150,170
> java.lang.classfile.Annotation
> java.lang.classfile.AnnotationElement
> java.lang.classfile.Attribute
> java.lang.classfile.AttributeMapper
> java.lang.classfile.AttributeMapper$AttributeStability
> java.lang.classfile.Attributes
> java.lang.classfile.BootstrapMethodEntry
> java.lang.classfile.ClassElement
> java.lang.classfile.ClassFileElement
> java.lang.classfile.FieldElement
> java.lang.classfile.MethodElement
> java.lang.classfile.TypeKind
> java.lang.classfile.attribute.RuntimeVisibleAnnotationsAttribute
> java.lang.classfile.constantpool.AnnotationConstantValueEntry
> java.lang.classfile.constantpool.ClassEntry
> java.lang.classfile.constantpool.ConstantPool
> java.lang.classfile.constantpool.ConstantPoolBuilder
> java.lang.classfile.constantpool.LoadableConstantEntry
> java.lang.classfile.constantpool.PoolEntry
> java.lang.classfile.constantpool.Utf8Entry
> java.lang.constant.ClassDesc
150a173,182
> java.lang.constant.ConstantDescs
> java.lang.constant.DirectMethodHandleDesc
> java.lang.constant.DirectMethodHandleDesc$Kind
> java.lang.constant.DynamicConstantDesc
> java.lang.constant.DynamicConstantDesc$AnonymousDynamicConstantDesc
> java.lang.constant.MethodHandleDesc
> java.lang.constant.MethodHandleDesc$1
> java.lang.constant.MethodTypeDesc
> java.lang.invoke.AbstractValidatingLambdaMetafactory
> java.lang.invoke.BootstrapMethodInvoker
153a186,193
> java.lang.invoke.DirectMethodHandle$Constructor
> java.lang.invoke.DirectMethodHandle$Holder
> java.lang.invoke.InfoFromMemberName
> java.lang.invoke.InnerClassLambdaMetafactory
> java.lang.invoke.InvokerBytecodeGenerator
> java.lang.invoke.InvokerBytecodeGenerator$8
> java.lang.invoke.Invokers
> java.lang.invoke.Invokers$Holder
154a195,201
> java.lang.invoke.LambdaForm$BasicType
> java.lang.invoke.LambdaForm$Holder
> java.lang.invoke.LambdaForm$Kind
> java.lang.invoke.LambdaForm$Name
> java.lang.invoke.LambdaForm$NamedFunction
> java.lang.invoke.LambdaMetafactory
> java.lang.invoke.LambdaProxyClassArchive
158a206,208
> java.lang.invoke.MethodHandleImpl$1
> java.lang.invoke.MethodHandleImpl$Intrinsic
> java.lang.invoke.MethodHandleInfo
163a214,215
> java.lang.invoke.MethodType$1
> java.lang.invoke.MethodTypeForm
169a222,223
> java.lang.invoke.VarHandle$AccessMode
> java.lang.invoke.VarHandle$AccessType
199a254
> java.lang.reflect.Array
270a326
> java.util.ArrayDeque$$Lambda/0x800000001
273d328
< java.util.ArrayList$Itr
359a415
> java.util.function.Consumer
393a450
> jdk.internal.access.JavaLangInvokeAccess
402a460,484
> jdk.internal.classfile.impl.AbstractAttributeMapper
>
jdk.internal.classfile.impl.AbstractAttributeMapper$RuntimeVisibleAnnotationsMapper
> jdk.internal.classfile.impl.AbstractElement
> jdk.internal.classfile.impl.AbstractPoolEntry
> jdk.internal.classfile.impl.AbstractPoolEntry$AbstractNamedEntry
> jdk.internal.classfile.impl.AbstractPoolEntry$AbstractRefEntry
> jdk.internal.classfile.impl.AbstractPoolEntry$ClassEntryImpl
> jdk.internal.classfile.impl.AbstractPoolEntry$Utf8EntryImpl
> jdk.internal.classfile.impl.AbstractPoolEntry$Utf8EntryImpl$State
> jdk.internal.classfile.impl.AnnotationImpl
> jdk.internal.classfile.impl.BootstrapMethodEntryImpl
> jdk.internal.classfile.impl.EntryMap
> jdk.internal.classfile.impl.SplitConstantPool
> jdk.internal.classfile.impl.TemporaryConstantPool
> jdk.internal.classfile.impl.UnboundAttribute
>
jdk.internal.classfile.impl.UnboundAttribute$UnboundRuntimeVisibleAnnotationsAttribute
> jdk.internal.classfile.impl.Util
> jdk.internal.classfile.impl.Util$Writable
> jdk.internal.constant.ArrayClassDescImpl
> jdk.internal.constant.ClassOrInterfaceDescImpl
> jdk.internal.constant.ConstantUtils
> jdk.internal.constant.DirectMethodHandleDescImpl
> jdk.internal.constant.DirectMethodHandleDescImpl$1
> jdk.internal.constant.MethodTypeDescImpl
> jdk.internal.constant.PrimitiveClassDescImpl
512a595
> jdk.internal.util.WeakReferenceKey
524a608
> sun.invoke.util.ValueConversions
525a610,612
> sun.invoke.util.VerifyType
> sun.invoke.util.Wrapper
> sun.invoke.util.Wrapper$Format

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260221/1f530752/attachment.htm>

From duke at openjdk.org  Sat Feb 21 13:50:13 2026
From: duke at openjdk.org (ExE Boss)
Date: Sat, 21 Feb 2026 13:50:13 GMT
Subject: RFR: 8160821: VarHandle accesses are penalized when argument
 conversion is required [v13]
In-Reply-To: <kr-zeuOunrUSwxZgULGX3I0-9wnMZqYHqkhKXjroG2o=.fa269f1f-0c06-4a15-8680-d87a23a70729@github.com>
References: <h57Syk2j8lETuGBxxM3ixuQRdpc2b8mkpKlX96sPG4M=.3ad64d74-fc83-4b7a-b652-ac2da8f3c25e@github.com>
 <vE_Xxcr_XE2aka17Etg-4RmhG_bigGRDp2L-B7r9Sz8=.169d31b0-838f-4986-b869-50975e6c4f03@github.com>
 <kr-zeuOunrUSwxZgULGX3I0-9wnMZqYHqkhKXjroG2o=.fa269f1f-0c06-4a15-8680-d87a23a70729@github.com>
Message-ID: <JqYJlojC7GwbwbxVZ1UjkejmYu5yZCdfcn2tNkqJ_a0=.3642ba5e-c3e9-4b83-82cf-82c12d53e016@github.com>

On Fri, 23 Jan 2026 23:02:34 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:
>> 
>>   Wording update, thanks Jorn
>
> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2022:
> 
>> 2020:     // In a class file, the JVM creates one access descriptor for one (name, type) combination.
>> 2021:     // Many call sites in one class can have the same (name, type) combination.
>> 2022:     // In this case, they share the same access descriptor.
> 
> I love it when, as part of maintenance, informative comments like these are added.  Thanks!
> 
> Please add a comment something like this as well:
> 
> 
> // Note:  The integers type and mode are proxies for the AccessType and
> // AccessMode enumerations, and the access type simply summarizes something
> // about the shape of the access mode.  The crucial type here, of the (name, type)
> // combination, is the MethodType that decorates the access shape with specific
> // strong types for the handle operation inputs and outputs.
> 
> 
> I think it was a small faux pas, some time ago, to choose the term `AccessType` instead of `AccessKind`, simply because the term "type" is already disastrously overloaded in our system.  But that?s water under the bridge.  Now we have one more "type" floating around in this neighborhood.

Well, `AccessType` can?probably be?renamed to?`AccessKind`, since?it?s a?package?private member of?[`VarHandle`] ([`AccessMode`] is?the?public?enum).
https://github.com/openjdk/jdk/blob/a35945ae067ffd60d5f374060086650636ebd9de/src/java.base/share/classes/java/lang/invoke/VarHandle.java#L1669-L1674

[`VarHandle`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/invoke/VarHandle.html#nested-class-summary
[`AccessMode`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/invoke/VarHandle.AccessMode.html

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2836196360

From vklang at openjdk.org  Sat Feb 21 16:02:14 2026
From: vklang at openjdk.org (Viktor Klang)
Date: Sat, 21 Feb 2026 16:02:14 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
References: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
Message-ID: <CRhvkd4g1P1ckvT9UuFDBPrPX4IIKLAy87Pn2vpXyTU=.edfe0c86-7f86-494e-9c69-d92c7c19a7c8@github.com>

On Sun, 13 Apr 2025 10:31:34 GMT, cdw200806 <duke at openjdk.org> wrote:

> "In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red."

Seconding Alan's comment

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3939010005

From vklang at openjdk.org  Sat Feb 21 16:18:13 2026
From: vklang at openjdk.org (Viktor Klang)
Date: Sat, 21 Feb 2026 16:18:13 GMT
Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile
 [v4]
In-Reply-To: <bKvj6vkHxkcqYFnKRzRkzQLn6ebShnf_09A8XPgbLzo=.c34ce43d-24ef-49a0-a777-d07954c243be@github.com>
References: <QDvNIqpJBwz2AByfzrrgSs8tKMYI2JpTTkP6M_qoAyc=.9ac31c22-9c76-4bf8-8664-d075caf70ae0@github.com>
 <bKvj6vkHxkcqYFnKRzRkzQLn6ebShnf_09A8XPgbLzo=.c34ce43d-24ef-49a0-a777-d07954c243be@github.com>
Message-ID: <0VU_gVgSYt6HF4YuD5zV_jgnINPo4Tr3yINKnuLjxOc=.4b12fd04-5721-412f-9145-1270649f6b8d@github.com>

On Fri, 20 Feb 2026 12:51:12 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Hot on the heals of #29288, this PR replaces `ArrayDeque` with `ArrayList` for the Inflater cache implementation in `ZipFile.CleanableResource`.
>> 
>> With this PR, we change the order of the cache from a LIFO queue to a FIFO stack backed by ArrayList. The order seems unimportant, and has indeed been FIFO in the past when using `java.util.Vector`. Intuitively, it should be better to return the most recently used Inflater.
>> 
>> No tests updated, strict refactoring, `noreg-cleanup`.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Add code comment about returning the most recently used Inflater from the cache
>  - Replace polling-style iteration with simple for loop
>  - Using add instead of addLast seems more natural for a List

src/java.base/share/classes/java/util/zip/ZipFile.java line 754:

> 752:                     // no need to double-check as only one thread gets a
> 753:                     // chance to execute run() (Cleaner guarantee)...
> 754:                     for (Inflater inf : inflaters) {

There's an important difference between the previous version and the proposed change?poll removes elements whereas forEach just traverses the collection. Is this change intended and for what reason?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29430#discussion_r2836324373

From markus at headcrashing.eu  Sat Feb 21 16:32:30 2026
From: markus at headcrashing.eu (Markus KARG)
Date: Sat, 21 Feb 2026 17:32:30 +0100
Subject: 8377939: Improving efficiency of StreamEncoder::append(CharSequence)
 and StreamEncoder::(CharSequence, int, int)
Message-ID: <9bd6738b-5dc0-4cbe-8a97-5aaafde60e9b@headcrashing.eu>

Core-Lib Devs,

as proposed in https://bugs.openjdk.org/browse/JDK-8377939 I would like 
to improve efficiency of StreamEncoder::append(CharSequence) (and in 
turn OutputStreamWriter::append(CharSequence)) for non-String and 
non-CharBuffer values, which seems to be safe and simple:

* No API or behavior is changed.
* StreamEncoder is final and is only used internally of OpenJDK, and is 
not leaked.
* AFAIK the proposed change has no side effects other than being 
potentially more efficient.
* Only few classes make actual use of StreamEncoder; OutputStreamWriter 
is probably the most popular one, and immediately provides potential 
benefit to I/O-bound applications dealing with StringBuilder-crafted output.

I have meanwhile coded the change (see diff at 
https://github.com/openjdk/jdk/compare/master...mkarg:jdk:StreamEncoder-uses-CharsSequence-getChars) 
and tested it successfully using OpenJDK Github Actions (see result at 
https://github.com/mkarg/jdk/actions/runs/22259626078).

Are you fine with me opening a Pull Request on Github?

Thanks!

-Markus


From eirbjo at openjdk.org  Sat Feb 21 16:48:13 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 21 Feb 2026 16:48:13 GMT
Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile
 [v4]
In-Reply-To: <0VU_gVgSYt6HF4YuD5zV_jgnINPo4Tr3yINKnuLjxOc=.4b12fd04-5721-412f-9145-1270649f6b8d@github.com>
References: <QDvNIqpJBwz2AByfzrrgSs8tKMYI2JpTTkP6M_qoAyc=.9ac31c22-9c76-4bf8-8664-d075caf70ae0@github.com>
 <bKvj6vkHxkcqYFnKRzRkzQLn6ebShnf_09A8XPgbLzo=.c34ce43d-24ef-49a0-a777-d07954c243be@github.com>
 <0VU_gVgSYt6HF4YuD5zV_jgnINPo4Tr3yINKnuLjxOc=.4b12fd04-5721-412f-9145-1270649f6b8d@github.com>
Message-ID: <0bIzWQQyKuYbLSVNNVuza7Spqsa3qaCLYzWEU5HGAwY=.6601fac6-65cf-4022-a18c-5afefdbd61e9@github.com>

On Sat, 21 Feb 2026 16:15:56 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Add code comment about returning the most recently used Inflater from the cache
>>  - Replace polling-style iteration with simple for loop
>>  - Using add instead of addLast seems more natural for a List
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 754:
> 
>> 752:                     // no need to double-check as only one thread gets a
>> 753:                     // chance to execute run() (Cleaner guarantee)...
>> 754:                     for (Inflater inf : inflaters) {
> 
> There's an important difference between the previous version and the proposed change?poll removes elements whereas forEach just traverses the collection. Is this change intended and for what reason?

The change to use a simple loop was suggested by Jaikiran, see [#discussion_r2832992318.](https://github.com/openjdk/jdk/pull/29430#discussion_r2832992318)

The rationale was that ordering does not matter when ending inflaters and that the reference is set to null immediately after.

Setting a synchronized field to null is a bit of a code smell, so ideally I think that `inflaterCache` should be made final,  the list should be cleared instead of nulled and we should introduce a separate `boolean` field to track the closed state of the cache. But that's perhaps for another PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29430#discussion_r2836348971

From duke at openjdk.org  Sat Feb 21 16:56:45 2026
From: duke at openjdk.org (cdw200806)
Date: Sat, 21 Feb 2026 16:56:45 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
Message-ID: <jXQygbK7vttEt0NTmm-QS7ZlHV3bFpsFlpZXM0_GMQ4=.f2266e7c-2f0e-4c70-b10d-efc088e3e0b6@github.com>

Raise a new PR. for https://github.com/openjdk/jdk/pull/24612 is too old.

"In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red."

-------------

Commit messages:
 - Fix red-black tree invariant check in ConcurrentHashMap

Changes: https://git.openjdk.org/jdk/pull/29857/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29857&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378354
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29857.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29857/head:pull/29857

PR: https://git.openjdk.org/jdk/pull/29857

From duke at openjdk.org  Sat Feb 21 16:59:20 2026
From: duke at openjdk.org (cdw200806)
Date: Sat, 21 Feb 2026 16:59:20 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <XjqgkPLZWUHz7tXUs5IBUU1aqCdOEnPa3JJki4H4kaQ=.58a1a0cc-08ae-4586-9d4f-5c1375bdf96d@github.com>
References: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
 <lLWBVt2PEc6rlXPZWnhAZu5-aJcscInn_RxLEBvNd8A=.90e7c52b-3091-48d4-ba31-26bfcb6d4ab7@github.com>
 <XjqgkPLZWUHz7tXUs5IBUU1aqCdOEnPa3JJki4H4kaQ=.58a1a0cc-08ae-4586-9d4f-5c1375bdf96d@github.com>
Message-ID: <_QlUCYw5XcOOHaGFfjnQEFHUjPMaQ7RFlLQgkkoIV48=.3dfdb66f-e966-41ab-b848-1ba224b26cd8@github.com>

On Fri, 20 Feb 2026 20:23:27 GMT, cdw200806 <duke at openjdk.org> wrote:

>> Please describe the semantic impact of the violated assertion. Would it ever be observable?
>
>> Please describe the semantic impact of the violated assertion. Would it ever be observable?
> 
> If concurrent map use red-black-tree correctly(or use it normally as common red-balck-tree algorithm), this bug will never be observable.
> In the logic, It just like the old code assert 1 is a Object, but I fix it to 1 is a Integer. More correctly( if 1 is a String it will throw error) , but the old code is not a "bug" , will never throw error(if the tree is build and use correct). I find it by code review.
> 
> This assert just like a ut lack some of branch,a ut not perfect, if the red-black-tree operation code is wrong and some case  not as expect happen and it will not aware,but if the code run correctly, maybe it not need to fix, it decide by your team. 
> 
> @RogerRiggs

> Hello @cdw200806, the line numbers in your change don't match the code in JDK master branch. Can you merge in the latest changes from master branch into yours and update this PR? I'm a bit surprised that the skara bots haven't tagged this PR with a merge-conflict label.
> 
> While at it please also enable GitHub Actions in your repo so that the GitHub actions test jobs get run in this PR. See the message here which explains what needs to be done https://github.com/openjdk/jdk/pull/24612/checks?check_run_id=40460799667.

Hi colleagues, I raise a new PR to resolve conflict issue.  We can close this outdated PR.
https://github.com/openjdk/jdk/pull/29857 
@jaikiran @AlanBateman @viktorklang-ora

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3939087442

From eirbjo at openjdk.org  Sat Feb 21 17:01:10 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 21 Feb 2026 17:01:10 GMT
Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile
 [v4]
In-Reply-To: <0bIzWQQyKuYbLSVNNVuza7Spqsa3qaCLYzWEU5HGAwY=.6601fac6-65cf-4022-a18c-5afefdbd61e9@github.com>
References: <QDvNIqpJBwz2AByfzrrgSs8tKMYI2JpTTkP6M_qoAyc=.9ac31c22-9c76-4bf8-8664-d075caf70ae0@github.com>
 <bKvj6vkHxkcqYFnKRzRkzQLn6ebShnf_09A8XPgbLzo=.c34ce43d-24ef-49a0-a777-d07954c243be@github.com>
 <0VU_gVgSYt6HF4YuD5zV_jgnINPo4Tr3yINKnuLjxOc=.4b12fd04-5721-412f-9145-1270649f6b8d@github.com>
 <0bIzWQQyKuYbLSVNNVuza7Spqsa3qaCLYzWEU5HGAwY=.6601fac6-65cf-4022-a18c-5afefdbd61e9@github.com>
Message-ID: <nmqp-U1bmXWUFVap8GuP8vKsCaNoSjOhLsx44BIS41s=.0bbe612e-d650-4640-a78a-4eda5125dc7d@github.com>

On Sat, 21 Feb 2026 16:45:44 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Setting a synchronized field to null is a bit of a code smell, so ideally I think that `inflaterCache` should be made final, the list should be cleared instead of nulled and we should introduce a separate `boolean` field to track the closed state of the cache. But that's perhaps for another PR.

Another benefit of making the closed state explicit is that it would remove the awkward `null` and double `==` checking.

Diff on top of this PR:


Index: src/java.base/share/classes/java/util/zip/ZipFile.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java b/src/java.base/share/classes/java/util/zip/ZipFile.java
--- a/src/java.base/share/classes/java/util/zip/ZipFile.java	(revision 02de2507929a1431a1070e0d6660c1585152cf9f)
+++ b/src/java.base/share/classes/java/util/zip/ZipFile.java	(date 1771693058851)
@@ -691,7 +691,9 @@
         final Set<InputStream> istreams;
 
         // List of cached Inflater objects for decompression
-        List<Inflater> inflaterCache;
+        final List<Inflater> inflaterCache;
+        // Closed state, access guarded by inflaterCache
+        boolean inflaterCacheClosed;
 
         final Cleanable cleanable;
 
@@ -727,36 +729,28 @@
          * Releases the specified inflater to the list of available inflaters.
          */
         void releaseInflater(Inflater inf) {
-            List<Inflater> inflaters = this.inflaterCache;
-            if (inflaters != null) {
-                synchronized (inflaters) {
-                    // double checked!
-                    if (inflaters == this.inflaterCache) {
-                        inf.reset();
-                        inflaters.add(inf);
-                        return;
-                    }
-                }
-            }
-            // inflaters cache already closed - just end it.
-            inf.end();
+            synchronized (inflaterCache) {
+                if (inflaterCacheClosed) {
+                    // inflaters cache already closed - just end it.
+                    inf.end();
+                } else {
+                    inf.reset();
+                    inflaterCache.add(inf);
+                }
+            }
         }
 
         public void run() {
             IOException ioe = null;
 
             // Release cached inflaters and close the cache first
-            List<Inflater> inflaters = this.inflaterCache;
-            if (inflaters != null) {
-                synchronized (inflaters) {
-                    // no need to double-check as only one thread gets a
-                    // chance to execute run() (Cleaner guarantee)...
-                    for (Inflater inf : inflaters) {
-                        inf.end();
-                    }
-                    // close inflaters cache
-                    this.inflaterCache = null;
-                }
+            synchronized (inflaterCache) {
+                for (Inflater inf : inflaterCache) {
+                    inf.end();
+                }
+                inflaterCache.clear();
+                // close inflaters cache
+                this.inflaterCacheClosed = true;
             }
 
             // Close streams, release their inflaters

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29430#discussion_r2836359284

From alanb at openjdk.org  Sat Feb 21 17:58:14 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Feb 2026 17:58:14 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <jXQygbK7vttEt0NTmm-QS7ZlHV3bFpsFlpZXM0_GMQ4=.f2266e7c-2f0e-4c70-b10d-efc088e3e0b6@github.com>
References: <jXQygbK7vttEt0NTmm-QS7ZlHV3bFpsFlpZXM0_GMQ4=.f2266e7c-2f0e-4c70-b10d-efc088e3e0b6@github.com>
Message-ID: <oRXzFhKFWGIEDl1wwkSF79wYsCNuFKMgNcBjRrf3xyc=.d8bfe6c6-feb5-4bf5-bcd0-e394e69641d9@github.com>

On Sat, 21 Feb 2026 16:51:17 GMT, cdw200806 <duke at openjdk.org> wrote:

> Raise a new PR. for https://github.com/openjdk/jdk/pull/24612 is too old.
> 
> "In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red."

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29857#pullrequestreview-3835741973

From jbhateja at openjdk.org  Sun Feb 22 05:15:12 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 22 Feb 2026 05:15:12 GMT
Subject: RFR: 8377438: [VectorAPI] Add new carrier type to LaneType class
 [v2]
In-Reply-To: <n4RmcoS6Glr23HBLlw4xA359-W-9_QijIeMqRpj2S3c=.0e4be8ab-14f5-44d5-a5d5-a9e56e5786fb@github.com>
References: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
 <qmSybXnaUH8CxOjqOJwhdINd_GhiWX6OlG8ABL1GScE=.fe7f9703-d35a-475f-9e85-ed9063f3648d@github.com>
 <n4RmcoS6Glr23HBLlw4xA359-W-9_QijIeMqRpj2S3c=.0e4be8ab-14f5-44d5-a5d5-a9e56e5786fb@github.com>
Message-ID: <PAsUT1jmqLS2tImaLXntjI-MiPW--V9lnKQKj1vVd_k=.210319c7-36c8-46d8-9305-d446ac1c8af7@github.com>

On Fri, 20 Feb 2026 21:44:55 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8377438
>>  - 8377438: [VectorAPI] Add new carrier type to LaneType class
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/gen-src.sh line 76:
> 
>> 74:   Boxfptype=$Boxtype
>> 75:   carriertype=$type
>> 76:   Carriertype=$Type
> 
> Is the boxed type of the carrier type used?

Yes, at one place
https://github.com/jatin-bhateja/jdk/blob/91889b08ffcb17355aa35f2e798bf4c108332ce9/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template#L57

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29629#discussion_r2837139364

From plevart at openjdk.org  Sun Feb 22 14:31:46 2026
From: plevart at openjdk.org (Peter Levart)
Date: Sun, 22 Feb 2026 14:31:46 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas, take 2
Message-ID: <v1EodJYVhybUixNNmOriqvyw0uDl12EdD2fMN9dCFz0=.33c50295-fcb8-4bb4-b75a-637553feb4f9@github.com>

Hi,

When administering my mailing lists, my attention was drawn to this pull request: https://github.com/openjdk/jdk/pull/28575, which tries to tackle this scaling problem. Although it was dismissed, I remembered that I was dealing with a similar problem in the past, so I looked closely...

Here's an alternative take at the problem. It reuses a maintained public component of JDK, the LongAdder, so in this respect, it does not add complexity and maintainance burden. It also does not change the internal API of the MemorySessionImpl. The size of the patch is also smaller.

For experimenting and benchmarking, I created a separate impmenetation of just the acquire/release/close logic with existing "simple" and this new "striped" implementations here:

https://github.com/plevart/acquire-release-close

Running it on my 8 core (16 threads) Linux PC, it gives promising results without regression for single-threaded use:


** Simple, measure run #1...
concurrency: 1, nanos: 39909697 (x 1.0)
concurrency: 2, nanos: 164735444 (x 4.127704702944751)
concurrency: 4, nanos: 394283724 (x 9.87939657873123)
concurrency: 8, nanos: 672278915 (x 16.84500172978011)
concurrency: 16, nanos: 2169282886 (x 54.3547821473062)
** Simple, measure run #2...
concurrency: 1, nanos: 40318379 (x 1.0)
concurrency: 2, nanos: 163438657 (x 4.053701092496799)
concurrency: 4, nanos: 399382210 (x 9.905710991009832)
concurrency: 8, nanos: 694862623 (x 17.23438888750959)
concurrency: 16, nanos: 2182386494 (x 54.12882531810121)
** Simple, measure run #3...
concurrency: 1, nanos: 39871197 (x 1.0)
concurrency: 2, nanos: 168843686 (x 4.234728292707139)
concurrency: 4, nanos: 375489497 (x 9.417562683156966)
concurrency: 8, nanos: 675885694 (x 16.951728186138983)
concurrency: 16, nanos: 2083500812 (x 52.255787856080666)
** end.

** Striped, measure run #1...
concurrency: 1, nanos: 36698350 (x 1.0)
concurrency: 2, nanos: 47349695 (x 1.290240433152989)
concurrency: 4, nanos: 58622304 (x 1.5974098018030782)
concurrency: 8, nanos: 60548173 (x 1.6498881557345222)
concurrency: 16, nanos: 70607406 (x 1.9239940215295783)
** Striped, measure run #2...
concurrency: 1, nanos: 37217044 (x 1.0)
concurrency: 2, nanos: 38610020 (x 1.0374284427317764)
concurrency: 4, nanos: 39166893 (x 1.0523912914738742)
concurrency: 8, nanos: 51778829 (x 1.3912665659314587)
concurrency: 16, nanos: 70277394 (x 1.8883120862581133)
** Striped, measure run #3...
concurrency: 1, nanos: 37589735 (x 1.0)
concurrency: 2, nanos: 38748261 (x 1.0308202758013592)
concurrency: 4, nanos: 38656911 (x 1.0283900910714054)
concurrency: 8, nanos: 40530711 (x 1.0782388064188269)
concurrency: 16, nanos: 52545852 (x 1.3978776918751887)
** end.

-------------

Commit messages:
 - 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas, take 2

Changes: https://git.openjdk.org/jdk/pull/29866/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29866&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371260
  Stats: 62 lines in 3 files changed: 32 ins; 13 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/29866.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29866/head:pull/29866

PR: https://git.openjdk.org/jdk/pull/29866

From vklang at openjdk.org  Sun Feb 22 14:53:09 2026
From: vklang at openjdk.org (Viktor Klang)
Date: Sun, 22 Feb 2026 14:53:09 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <jXQygbK7vttEt0NTmm-QS7ZlHV3bFpsFlpZXM0_GMQ4=.f2266e7c-2f0e-4c70-b10d-efc088e3e0b6@github.com>
References: <jXQygbK7vttEt0NTmm-QS7ZlHV3bFpsFlpZXM0_GMQ4=.f2266e7c-2f0e-4c70-b10d-efc088e3e0b6@github.com>
Message-ID: <B_1wtnfV6J8_-9q0NhEYGCRMD_7ru991VokirU6a3ak=.72772b45-7ae3-4d4a-b0f8-445830f217f5@github.com>

On Sat, 21 Feb 2026 16:51:17 GMT, cdw200806 <duke at openjdk.org> wrote:

> Raise a new PR. for https://github.com/openjdk/jdk/pull/24612 is too old.
> 
> "In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red."

Thanks for the discovery and fix.

-------------

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29857#pullrequestreview-3837949299

From plevart at openjdk.org  Sun Feb 22 14:54:57 2026
From: plevart at openjdk.org (Peter Levart)
Date: Sun, 22 Feb 2026 14:54:57 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas, take 2 [v2]
In-Reply-To: <v1EodJYVhybUixNNmOriqvyw0uDl12EdD2fMN9dCFz0=.33c50295-fcb8-4bb4-b75a-637553feb4f9@github.com>
References: <v1EodJYVhybUixNNmOriqvyw0uDl12EdD2fMN9dCFz0=.33c50295-fcb8-4bb4-b75a-637553feb4f9@github.com>
Message-ID: <8rU1kgHPew-IjDRlne7dHNCXgi5eF7ocY0sbm9ER048=.7e6cd89a-0cc2-4a03-ad7b-8c295171b4ad@github.com>

> Hi,
> 
> When administering my mailing lists, my attention was drawn to this pull request: https://github.com/openjdk/jdk/pull/28575, which tries to tackle this scaling problem. Although it was dismissed, I remembered that I was dealing with a similar problem in the past, so I looked closely...
> 
> Here's an alternative take at the problem. It reuses a maintained public component of JDK, the LongAdder, so in this respect, it does not add complexity and maintainance burden. It also does not change the internal API of the MemorySessionImpl. The size of the patch is also smaller.
> 
> For experimenting and benchmarking, I created a separate impmenetation of just the acquire/release/close logic with existing "simple" and this new "striped" implementations here:
> 
> https://github.com/plevart/acquire-release-close
> 
> Running it on my 8 core (16 threads) Linux PC, it gives promising results without regression for single-threaded use:
> 
> 
> ** Simple, measure run #1...
> concurrency: 1, nanos: 39909697 (x 1.0)
> concurrency: 2, nanos: 164735444 (x 4.127704702944751)
> concurrency: 4, nanos: 394283724 (x 9.87939657873123)
> concurrency: 8, nanos: 672278915 (x 16.84500172978011)
> concurrency: 16, nanos: 2169282886 (x 54.3547821473062)
> ** Simple, measure run #2...
> concurrency: 1, nanos: 40318379 (x 1.0)
> concurrency: 2, nanos: 163438657 (x 4.053701092496799)
> concurrency: 4, nanos: 399382210 (x 9.905710991009832)
> concurrency: 8, nanos: 694862623 (x 17.23438888750959)
> concurrency: 16, nanos: 2182386494 (x 54.12882531810121)
> ** Simple, measure run #3...
> concurrency: 1, nanos: 39871197 (x 1.0)
> concurrency: 2, nanos: 168843686 (x 4.234728292707139)
> concurrency: 4, nanos: 375489497 (x 9.417562683156966)
> concurrency: 8, nanos: 675885694 (x 16.951728186138983)
> concurrency: 16, nanos: 2083500812 (x 52.255787856080666)
> ** end.
> 
> ** Striped, measure run #1...
> concurrency: 1, nanos: 36698350 (x 1.0)
> concurrency: 2, nanos: 47349695 (x 1.290240433152989)
> concurrency: 4, nanos: 58622304 (x 1.5974098018030782)
> concurrency: 8, nanos: 60548173 (x 1.6498881557345222)
> concurrency: 16, nanos: 70607406 (x 1.9239940215295783)
> ** Striped, measure run #2...
> concurrency: 1, nanos: 37217044 (x 1.0)
> concurrency: 2, nanos: 38610020 (x 1.0374284427317764)
> concurrency: 4, nanos: 39166893 (x 1.0523912914738742)
> concurrency: 8, nanos: 51778829 (x 1.3912665659314587)
> concurrency: 16, nanos: 70277394 (x 1.8883120862581133)
> ** Striped, measure run #3...
> concurrency: 1, nanos: 37589735 (x 1.0)
> concurrency: 2, nanos: 38748261 (x 1.03...

Peter Levart has updated the pull request incrementally with one additional commit since the last revision:

  8371260: Prevent two theoretical reorderings of volatile write beyond volatile read

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29866/files
  - new: https://git.openjdk.org/jdk/pull/29866/files/fa88fcca..bced1b62

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29866&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29866&range=00-01

  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29866.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29866/head:pull/29866

PR: https://git.openjdk.org/jdk/pull/29866

From plevart at openjdk.org  Sun Feb 22 15:01:11 2026
From: plevart at openjdk.org (Peter Levart)
Date: Sun, 22 Feb 2026 15:01:11 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas, take 2 [v2]
In-Reply-To: <8rU1kgHPew-IjDRlne7dHNCXgi5eF7ocY0sbm9ER048=.7e6cd89a-0cc2-4a03-ad7b-8c295171b4ad@github.com>
References: <v1EodJYVhybUixNNmOriqvyw0uDl12EdD2fMN9dCFz0=.33c50295-fcb8-4bb4-b75a-637553feb4f9@github.com>
 <8rU1kgHPew-IjDRlne7dHNCXgi5eF7ocY0sbm9ER048=.7e6cd89a-0cc2-4a03-ad7b-8c295171b4ad@github.com>
Message-ID: <L0SzJuTaVGL2Nzn0Wd2Ecq2xqfLdjx7FIsyBmXhsujY=.13dae9b3-e0a1-408b-9270-f91dd9432312@github.com>

On Sun, 22 Feb 2026 14:54:57 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Hi,
>> 
>> When administering my mailing lists, my attention was drawn to this pull request: https://github.com/openjdk/jdk/pull/28575, which tries to tackle this scaling problem. Although it was dismissed, I remembered that I was dealing with a similar problem in the past, so I looked closely...
>> 
>> Here's an alternative take at the problem. It reuses a maintained public component of JDK, the LongAdder, so in this respect, it does not add complexity and maintainance burden. It also does not change the internal API of the MemorySessionImpl. The size of the patch is also smaller.
>> 
>> For experimenting and benchmarking, I created a separate impmenetation of just the acquire/release/close logic with existing "simple" and this new "striped" implementations here:
>> 
>> https://github.com/plevart/acquire-release-close
>> 
>> Running it on my 8 core (16 threads) Linux PC, it gives promising results without regression for single-threaded use:
>> 
>> 
>> ** Simple, measure run #1...
>> concurrency: 1, nanos: 39909697 (x 1.0)
>> concurrency: 2, nanos: 164735444 (x 4.127704702944751)
>> concurrency: 4, nanos: 394283724 (x 9.87939657873123)
>> concurrency: 8, nanos: 672278915 (x 16.84500172978011)
>> concurrency: 16, nanos: 2169282886 (x 54.3547821473062)
>> ** Simple, measure run #2...
>> concurrency: 1, nanos: 40318379 (x 1.0)
>> concurrency: 2, nanos: 163438657 (x 4.053701092496799)
>> concurrency: 4, nanos: 399382210 (x 9.905710991009832)
>> concurrency: 8, nanos: 694862623 (x 17.23438888750959)
>> concurrency: 16, nanos: 2182386494 (x 54.12882531810121)
>> ** Simple, measure run #3...
>> concurrency: 1, nanos: 39871197 (x 1.0)
>> concurrency: 2, nanos: 168843686 (x 4.234728292707139)
>> concurrency: 4, nanos: 375489497 (x 9.417562683156966)
>> concurrency: 8, nanos: 675885694 (x 16.951728186138983)
>> concurrency: 16, nanos: 2083500812 (x 52.255787856080666)
>> ** end.
>> 
>> ** Striped, measure run #1...
>> concurrency: 1, nanos: 36698350 (x 1.0)
>> concurrency: 2, nanos: 47349695 (x 1.290240433152989)
>> concurrency: 4, nanos: 58622304 (x 1.5974098018030782)
>> concurrency: 8, nanos: 60548173 (x 1.6498881557345222)
>> concurrency: 16, nanos: 70607406 (x 1.9239940215295783)
>> ** Striped, measure run #2...
>> concurrency: 1, nanos: 37217044 (x 1.0)
>> concurrency: 2, nanos: 38610020 (x 1.0374284427317764)
>> concurrency: 4, nanos: 39166893 (x 1.0523912914738742)
>> concurrency: 8, nanos: 51778829 (x 1.3912665659314587)
>> concurrency: 16, nanos: 70277394 (x 1.8883120862581133)
>> ** Striped, measu...
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8371260: Prevent two theoretical reorderings of volatile write beyond volatile read

So after JMM theory kicks in, some faults are discovered. I mitigated them with two explicit fullFence(s). This does introduce some overhead to single-thread usage though. Here's again the comparison report:


** Simple, measure run #1...
concurrency: 1, nanos: 39909697 (x 1.0)
concurrency: 2, nanos: 164735444 (x 4.127704702944751)
concurrency: 4, nanos: 394283724 (x 9.87939657873123)
concurrency: 8, nanos: 672278915 (x 16.84500172978011)
concurrency: 16, nanos: 2169282886 (x 54.3547821473062)
** Simple, measure run #2...
concurrency: 1, nanos: 40318379 (x 1.0)
concurrency: 2, nanos: 163438657 (x 4.053701092496799)
concurrency: 4, nanos: 399382210 (x 9.905710991009832)
concurrency: 8, nanos: 694862623 (x 17.23438888750959)
concurrency: 16, nanos: 2182386494 (x 54.12882531810121)
** Simple, measure run #3...
concurrency: 1, nanos: 39871197 (x 1.0)
concurrency: 2, nanos: 168843686 (x 4.234728292707139)
concurrency: 4, nanos: 375489497 (x 9.417562683156966)
concurrency: 8, nanos: 675885694 (x 16.951728186138983)
concurrency: 16, nanos: 2083500812 (x 52.255787856080666)
** end.

** Striped, measure run #1...
concurrency: 1, nanos: 58248553 (x 1.0)
concurrency: 2, nanos: 77375592 (x 1.3283693416384095)
concurrency: 4, nanos: 70015083 (x 1.2020055330816544)
concurrency: 8, nanos: 60701425 (x 1.0421104366317906)
concurrency: 16, nanos: 65387340 (x 1.1225573277331027)
** Striped, measure run #2...
concurrency: 1, nanos: 58836025 (x 1.0)
concurrency: 2, nanos: 78600629 (x 1.3359269087264138)
concurrency: 4, nanos: 63892822 (x 1.085947291646572)
concurrency: 8, nanos: 62594145 (x 1.063874471465399)
concurrency: 16, nanos: 89972108 (x 1.5292009954785355)
** Striped, measure run #3...
concurrency: 1, nanos: 59242988 (x 1.0)
concurrency: 2, nanos: 63316159 (x 1.0687536388272652)
concurrency: 4, nanos: 60279613 (x 1.0174978513912905)
concurrency: 8, nanos: 66596046 (x 1.1241169334672991)
concurrency: 16, nanos: 107654519 (x 1.8171689618356184)
** end.


There is a 50% increase in latency for single-thread usage which is payed off whenever there is contention in Simple implementation though. I wonder what results would be like on other hardware.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29866#issuecomment-3941129435

From dl at openjdk.org  Sun Feb 22 23:27:02 2026
From: dl at openjdk.org (Doug Lea)
Date: Sun, 22 Feb 2026 23:27:02 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v41]
In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
Message-ID: <MF1ExjmiL-4M3zx24mdr6HT1k9skgKXNgqpKvohEyvg=.70355d0d-c938-4c04-a303-2bf07db589bc@github.com>

> Changes signal filtering to avoid possible starvation

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Another set of scan tradeoffs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28797/files
  - new: https://git.openjdk.org/jdk/pull/28797/files/067aaee9..821ed264

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=40
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=39-40

  Stats: 139 lines in 1 file changed: 56 ins; 37 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/28797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28797/head:pull/28797

PR: https://git.openjdk.org/jdk/pull/28797

From darcy at openjdk.org  Mon Feb 23 00:56:33 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 23 Feb 2026 00:56:33 GMT
Subject: RFR: 8378414: Add methods to test for representation equivalence
Message-ID: <mioOgE5dVvyj1CgG7BNDyixbbwIOyRFqKs9s7-vgqCE=.825997f5-c363-4a94-a45b-499dfa255420@github.com>

Floating-point values have a notion of representation equivalence distinct from the comparison done by ==. This notion of equivalence could have a method to provide the predicate directly, rather than relying on one of several expressions listed in the documentation ([JDK-8295391](https://bugs.openjdk.org/browse/JDK-8295391)).

-------------

Commit messages:
 - 8378414: Add methods to test for representation equivalence

Changes: https://git.openjdk.org/jdk/pull/29870/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29870&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378414
  Stats: 89 lines in 5 files changed: 66 ins; 0 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/29870.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29870/head:pull/29870

PR: https://git.openjdk.org/jdk/pull/29870

From jpai at openjdk.org  Mon Feb 23 01:21:45 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Feb 2026 01:21:45 GMT
Subject: RFR: 8378378: Remove references to obsolete
 jdk.net.usePlainDatagramSocketImpl property from tests
Message-ID: <u5AsYpwj5lBAVG8m4_wTbIuop804rWs7dlUWgnICNUA=.56dc3b7f-a9e9-4c65-a187-55e754b578d3@github.com>

Can I please get a review of this test-only change which removes reference to the obsolete `jdk.net.usePlainDatagramSocketImpl` property?

This property and the related fallback support was removed in https://bugs.openjdk.org/browse/JDK-8253119. The property plays no role anymore. The tests continue to pass after this change.

-------------

Commit messages:
 - remove references to obsolete jdk.net.usePlainDatagramSocketImpl property

Changes: https://git.openjdk.org/jdk/pull/29871/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29871&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378378
  Stats: 79 lines in 3 files changed: 0 ins; 50 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/29871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29871/head:pull/29871

PR: https://git.openjdk.org/jdk/pull/29871

From jpai at openjdk.org  Mon Feb 23 01:21:46 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Feb 2026 01:21:46 GMT
Subject: RFR: 8378378: Remove references to obsolete
 jdk.net.usePlainDatagramSocketImpl property from tests
In-Reply-To: <u5AsYpwj5lBAVG8m4_wTbIuop804rWs7dlUWgnICNUA=.56dc3b7f-a9e9-4c65-a187-55e754b578d3@github.com>
References: <u5AsYpwj5lBAVG8m4_wTbIuop804rWs7dlUWgnICNUA=.56dc3b7f-a9e9-4c65-a187-55e754b578d3@github.com>
Message-ID: <fe-cb-zfLrPNVAHx53zvZFfq1eqJble24AwCj83ZRyA=.b7bcf525-faef-4a30-bce3-a840d395bb33@github.com>

On Mon, 23 Feb 2026 01:14:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which removes reference to the obsolete `jdk.net.usePlainDatagramSocketImpl` property?
> 
> This property and the related fallback support was removed in https://bugs.openjdk.org/browse/JDK-8253119. The property plays no role anymore. The tests continue to pass after this change.

test/jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java line 39:

> 37:  * @library ../lib/
> 38:  * @modules java.base/sun.security.util
> 39:  * @run main PortUnreachable

The `othervm` was introduced when that property was added to this test. I haven't spotted anything else in this test that requires a `othervm`, so I have removed that part too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29871#discussion_r2838753438

From jpai at openjdk.org  Mon Feb 23 01:46:52 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Feb 2026 01:46:52 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v5]
In-Reply-To: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
Message-ID: <39nXLnFR2Kl257ljgwgsenJDyFCuL6EegMWXeeSZGI0=.3c3c2250-2ff9-44e1-8647-c23bf643a14b@github.com>

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?
> 
> The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.
> 
> When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.
> 
> When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.
> 
> Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `OutputStream` is a `Bu...

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 11 additional commits since the last revision:

 - merge latest from master branch
 - Daniel's review - recheck while holding the lock
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - add comment
 - copyright years
 - alternate fix
 - rename test
 - 8362268: NPE thrown from SASL GSSAPI impl when  TLS is  used with QOP auth-int against Active Directory
 - ... and 1 more: https://git.openjdk.org/jdk/compare/e63a50da...fa582f62

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29638/files
  - new: https://git.openjdk.org/jdk/pull/29638/files/52517a9d..fa582f62

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29638&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29638&range=03-04

  Stats: 85637 lines in 374 files changed: 35843 ins; 35691 del; 14103 mod
  Patch: https://git.openjdk.org/jdk/pull/29638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29638/head:pull/29638

PR: https://git.openjdk.org/jdk/pull/29638

From liach at openjdk.org  Mon Feb 23 02:02:07 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 23 Feb 2026 02:02:07 GMT
Subject: RFR: 8378414: Add methods to test for representation equivalence
In-Reply-To: <mioOgE5dVvyj1CgG7BNDyixbbwIOyRFqKs9s7-vgqCE=.825997f5-c363-4a94-a45b-499dfa255420@github.com>
References: <mioOgE5dVvyj1CgG7BNDyixbbwIOyRFqKs9s7-vgqCE=.825997f5-c363-4a94-a45b-499dfa255420@github.com>
Message-ID: <zYuApVBaFbPz_VrCHEIctFlnpyoA8CO8XGbxncUMGrw=.c3a6b218-19e9-4e86-bc2f-a6af7d0a16a0@github.com>

On Mon, 23 Feb 2026 00:48:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Floating-point values have a notion of representation equivalence distinct from the comparison done by ==. This notion of equivalence could have a method to provide the predicate directly, rather than relying on one of several expressions listed in the documentation ([JDK-8295391](https://bugs.openjdk.org/browse/JDK-8295391)).

This equivalence is already covered by their `equals(Object)` methods. I would assume they are declared as `equals(double, double)` etc. similar to how instance `Double::isInfinite()` and static `Double::isInfinite(double)` are declared.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29870#issuecomment-3942150565

From darcy at openjdk.org  Mon Feb 23 02:05:13 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 23 Feb 2026 02:05:13 GMT
Subject: RFR: 8378414: Add methods to test for representation equivalence
In-Reply-To: <mioOgE5dVvyj1CgG7BNDyixbbwIOyRFqKs9s7-vgqCE=.825997f5-c363-4a94-a45b-499dfa255420@github.com>
References: <mioOgE5dVvyj1CgG7BNDyixbbwIOyRFqKs9s7-vgqCE=.825997f5-c363-4a94-a45b-499dfa255420@github.com>
Message-ID: <NLfGIPXju_H1tx_DyPzfTtRGUHZtqJbSyHkvlaeMDrI=.2408ea29-7ef2-42bf-8db1-155da40d194f@github.com>

On Mon, 23 Feb 2026 00:48:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Floating-point values have a notion of representation equivalence distinct from the comparison done by ==. This notion of equivalence could have a method to provide the predicate directly, rather than relying on one of several expressions listed in the documentation ([JDK-8295391](https://bugs.openjdk.org/browse/JDK-8295391)).

I'll acknowledge possible bike-shedding on the name of the method. I choose "equivalent" to make the discussion in Double.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29870#issuecomment-3942154614

From darcy at openjdk.org  Mon Feb 23 02:48:06 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 23 Feb 2026 02:48:06 GMT
Subject: RFR: 8378414: Add methods to test for representation equivalence
In-Reply-To: <zYuApVBaFbPz_VrCHEIctFlnpyoA8CO8XGbxncUMGrw=.c3a6b218-19e9-4e86-bc2f-a6af7d0a16a0@github.com>
References: <mioOgE5dVvyj1CgG7BNDyixbbwIOyRFqKs9s7-vgqCE=.825997f5-c363-4a94-a45b-499dfa255420@github.com>
 <zYuApVBaFbPz_VrCHEIctFlnpyoA8CO8XGbxncUMGrw=.c3a6b218-19e9-4e86-bc2f-a6af7d0a16a0@github.com>
Message-ID: <0c0gdxzdx89GRTz0mEbpIndhAocsMwbpUGhvCNb8IYQ=.46355665-6ab6-455d-83e3-5947b34a6fb6@github.com>

On Mon, 23 Feb 2026 01:59:52 GMT, Chen Liang <liach at openjdk.org> wrote:

> This equivalence is already covered by their `equals(Object)` methods. I would assume they are declared as `equals(double, double)` etc. similar to how instance `Double::isInfinite()` and static `Double::isInfinite(double)` are declared.

It is true that there are already multiple expressions using existing methods can be written to implement that functionality. However, conceptually, I don't think boxing up to Double should be necessary (or desirable).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29870#issuecomment-3942229402

From jbhateja at openjdk.org  Mon Feb 23 04:58:15 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 23 Feb 2026 04:58:15 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating
 broadcasted inputs [v3]
In-Reply-To: <S09FWymoHUyMEhDZNodmP8jQKslTWH5pa1bilHA0I7w=.5e9af240-b87d-4b11-bcc4-8e07d3b9d00b@github.com>
References: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
 <S09FWymoHUyMEhDZNodmP8jQKslTWH5pa1bilHA0I7w=.5e9af240-b87d-4b11-bcc4-8e07d3b9d00b@github.com>
Message-ID: <QFbGRwnY0m6HQ3Rh1vT6YIH5al5Cz7-3rNeVJL9MZp0=.c444a2f2-6311-4eea-9116-e01ee40c8cbb@github.com>

On Tue, 10 Feb 2026 02:40:03 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolution
>
> Good work @jatin-bhateja ! I left some comments below. Thanks!

Hi @XiaohongGong , your comments have been addressed. Please let me know if there are other comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25617#issuecomment-3942633960

From xgong at openjdk.org  Mon Feb 23 06:11:19 2026
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 23 Feb 2026 06:11:19 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating
 broadcasted inputs [v3]
In-Reply-To: <S09FWymoHUyMEhDZNodmP8jQKslTWH5pa1bilHA0I7w=.5e9af240-b87d-4b11-bcc4-8e07d3b9d00b@github.com>
References: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
 <S09FWymoHUyMEhDZNodmP8jQKslTWH5pa1bilHA0I7w=.5e9af240-b87d-4b11-bcc4-8e07d3b9d00b@github.com>
Message-ID: <XUwlb9kjVDNZskHoj5UiBI6HRN8bijLa_fdSfpXWgc8=.d5b13929-490a-4cff-a998-238f59962abd@github.com>

On Tue, 10 Feb 2026 02:40:03 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolution
>
> Good work @jatin-bhateja ! I left some comments below. Thanks!

> Hi @XiaohongGong , your comments have been addressed. Please let me know if there are other comments.

Just returned from my holiday. I?ll take another look today?thanks for your update!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25617#issuecomment-3942877498

From xgong at openjdk.org  Mon Feb 23 06:46:17 2026
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 23 Feb 2026 06:46:17 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v13]
In-Reply-To: <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
Message-ID: <e7FJHcLy2gkZDnt7e5hpJe8n1VqxhM77bFpGdc-MG0w=.3f9b91db-3a67-4bd6-b141-9e39c6d17242@github.com>

On Mon, 9 Feb 2026 21:36:16 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 with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - Review comments resolutions
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - Review comments resolutions
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - Update callGenerator.hpp copyright year
>  - Review comments resolution
>  - Cleanups
>  - Review comments resolutions
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/ffb6279c...1dfff558

I?m fine with using the more straightforward approach to intrinsify the slice API when the origin is a constant. In my view, this could also benefit other APIs and future optimizations (for example, https://github.com/openjdk/jdk/pull/28520), since slice is a general vector operation. Relying on pattern matching makes the compiler implementation significantly more complex in my opinion.

Regarding inlining of the fallback implementation, I think we do need such a mechanism to handle APIs that fail to inline on the first attempt, given that the current fallback overhead is much heavier and leads to worse performance. And I agree with @merykitty  that a more generic solution would be more preferable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3942980796

From xgong at openjdk.org  Mon Feb 23 07:07:13 2026
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 23 Feb 2026 07:07:13 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating
 broadcasted inputs [v3]
In-Reply-To: <JO48amlT-BaATLTxZv05xSRGyz-UcGM0jgrCDXSHRwY=.0b1ca7d4-0e93-4a1e-af41-0bb6ae906998@github.com>
References: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
 <JO48amlT-BaATLTxZv05xSRGyz-UcGM0jgrCDXSHRwY=.0b1ca7d4-0e93-4a1e-af41-0bb6ae906998@github.com>
Message-ID: <1BMgPIQeBzVYy9-fmBwXPnmlLGRSt00NmRC6mFD4YWc=.3d6e1292-7892-4036-aee2-d8b7df3b5393@github.com>

On Thu, 12 Feb 2026 05:18:36 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch optimizes SIMD kernels making heavy use of broadcasted inputs through following reassociating ideal transformations.
>> 
>> 
>>  VectorOperation (VectorBroadcast INP1,  VectorBroadcast INP2) => 
>>                             VectorBroadcast (ScalarOpration INP1, INP2)
>> 
>>  VectorOperation (VectorBroadcast INP1) (VectorOperation (VectorBroadcast INP2) INP3) => 
>>                              VectorOperation INP3 (VectorOperation (VectorBroadcast INP1) (VectorOperation INP2))
>> 
>> 
>> The idea is to push broadcasts across the vector operation and replace the vector with an equivalent, cheaper scalar variant.  Currently, patch handles most common vector operations.
>> 
>> Following are the performance number of benchmark included with this patch on latest generation x86 targets:- 
>> 
>> **AMD Turin (2.1GHz)**
>> <img width="1122" height="355" alt="image" src="https://github.com/user-attachments/assets/3f5087bf-0e14-4c56-b0c2-3d23253bad54" />
>> 
>> **Intel Granite Rapids (2.1GHz)**
>> <img width="1105" height="325" alt="image" src="https://github.com/user-attachments/assets/c8481f86-4db2-4c4e-bd65-51542c59fe63" />
>> 
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolution

src/hotspot/share/opto/vectornode.cpp line 1193:

> 1191: }
> 1192: 
> 1193: bool VectorNode::can_push_broadcasts_across_vector_operation(BasicType bt) {

Better to add a comment for this method?

src/hotspot/share/opto/vectornode.cpp line 1331:

> 1329:       return create_reassociated_node(this, in(1), in(2), in1_2, in1_1, phase);
> 1330:     }
> 1331:   }

These two parts are duplicated. How about merging the code like:

Suggestion:

  Node* in1 = in(1);
  Node* in2 = in(2);
 
  // Swap broadcast operation to left to make the following reassociation simpler
  if (in2->Opcode() == Op_Replicate) {
    swap(in1, in2);
  }
 
  if (in1->Opcode() == Op_Replicate && in2->Opcode() == Opcode()) {
    ...
  }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2839339938
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2839336882

From xgong at openjdk.org  Mon Feb 23 07:07:15 2026
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 23 Feb 2026 07:07:15 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating
 broadcasted inputs [v3]
In-Reply-To: <8NV2dH7Ingzw2y7E4MEflV9bipfpei8MYIgA9ErG_AI=.ab852238-f137-4f22-8247-28758c57c1e2@github.com>
References: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
 <S09FWymoHUyMEhDZNodmP8jQKslTWH5pa1bilHA0I7w=.5e9af240-b87d-4b11-bcc4-8e07d3b9d00b@github.com>
 <8NV2dH7Ingzw2y7E4MEflV9bipfpei8MYIgA9ErG_AI=.ab852238-f137-4f22-8247-28758c57c1e2@github.com>
Message-ID: <HsWohyElLTSz6Ht7ns2eo1ftP_GP81PFRPDp74m0HjE=.ffa8f03c-dd96-4eb5-9588-31a64ef6ce76@github.com>

On Tue, 10 Feb 2026 05:33:28 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/vectornode.cpp line 1317:
>> 
>>> 1315:   }
>>> 1316:   return nullptr;
>>> 1317: }
>> 
>> Reassociation can be a separate optimization for vector nodes to me. Do you think it's better to split it as a separate change following the broadcast optimization? We can add specific tests for it.
>
> Reassociation are only applicable to integral vector operation, for vector API we only use fp-fast model semantics for reductions of floating point vector, I have now added tests to cover all possible transformations so that we can include both associated transforms in same patch.

I still keep my point that separating the reassociation as a separate PR for better maintain. WDYT?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2839345895

From alanb at openjdk.org  Mon Feb 23 07:20:08 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Feb 2026 07:20:08 GMT
Subject: RFR: 8378378: Remove references to obsolete
 jdk.net.usePlainDatagramSocketImpl property from tests
In-Reply-To: <u5AsYpwj5lBAVG8m4_wTbIuop804rWs7dlUWgnICNUA=.56dc3b7f-a9e9-4c65-a187-55e754b578d3@github.com>
References: <u5AsYpwj5lBAVG8m4_wTbIuop804rWs7dlUWgnICNUA=.56dc3b7f-a9e9-4c65-a187-55e754b578d3@github.com>
Message-ID: <EqwrOXu3bLugm1Qz_CCsz54ypx7zw3YInXuBUQbwLps=.62762fe9-4be9-4edc-a182-a8adbc8fafeb@github.com>

On Mon, 23 Feb 2026 01:14:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which removes reference to the obsolete `jdk.net.usePlainDatagramSocketImpl` property?
> 
> This property and the related fallback support was removed in https://bugs.openjdk.org/browse/JDK-8253119. The property plays no role anymore. The tests continue to pass after this change.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29871#pullrequestreview-3839465095

From vyazici at openjdk.org  Mon Feb 23 08:07:12 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 23 Feb 2026 08:07:12 GMT
Subject: RFR: 8378378: Remove references to obsolete
 jdk.net.usePlainDatagramSocketImpl property from tests
In-Reply-To: <u5AsYpwj5lBAVG8m4_wTbIuop804rWs7dlUWgnICNUA=.56dc3b7f-a9e9-4c65-a187-55e754b578d3@github.com>
References: <u5AsYpwj5lBAVG8m4_wTbIuop804rWs7dlUWgnICNUA=.56dc3b7f-a9e9-4c65-a187-55e754b578d3@github.com>
Message-ID: <RYLekyr8GYQ6dqkHjPLxy01IBzZ2lyyoxoOZfOqTz7M=.d7ce02b4-90b2-4be5-895c-625275a15c2f@github.com>

On Mon, 23 Feb 2026 01:14:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which removes reference to the obsolete `jdk.net.usePlainDatagramSocketImpl` property?
> 
> This property and the related fallback support was removed in https://bugs.openjdk.org/browse/JDK-8253119. The property plays no role anymore. The tests continue to pass after this change.

Changes LGTM. `git grep usePlainDatagramSocketImpl` indeed does not return any other files than the ones touched in this PR.

-------------

Marked as reviewed by vyazici (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29871#pullrequestreview-3839610540

From plevart at openjdk.org  Mon Feb 23 10:01:31 2026
From: plevart at openjdk.org (Peter Levart)
Date: Mon, 23 Feb 2026 10:01:31 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas, take 2 [v2]
In-Reply-To: <8rU1kgHPew-IjDRlne7dHNCXgi5eF7ocY0sbm9ER048=.7e6cd89a-0cc2-4a03-ad7b-8c295171b4ad@github.com>
References: <v1EodJYVhybUixNNmOriqvyw0uDl12EdD2fMN9dCFz0=.33c50295-fcb8-4bb4-b75a-637553feb4f9@github.com>
 <8rU1kgHPew-IjDRlne7dHNCXgi5eF7ocY0sbm9ER048=.7e6cd89a-0cc2-4a03-ad7b-8c295171b4ad@github.com>
Message-ID: <rgJDM1nyK2akcaSiHDWUlA1g-dbELcbs9QQdOrTWN8M=.b6b5b7e7-5be7-4700-aebe-b29da6518e59@github.com>

On Sun, 22 Feb 2026 14:54:57 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Hi,
>> 
>> When administering my mailing lists, my attention was drawn to this pull request: https://github.com/openjdk/jdk/pull/28575, which tries to tackle this scaling problem. Although it was dismissed, I remembered that I was dealing with a similar problem in the past, so I looked closely...
>> 
>> Here's an alternative take at the problem. It reuses a maintained public component of JDK, the LongAdder, so in this respect, it does not add complexity and maintainance burden. It also does not change the internal API of the MemorySessionImpl. The size of the patch is also smaller.
>> 
>> For experimenting and benchmarking, I created a separate impmenetation of just the acquire/release/close logic with existing "simple" and this new "striped" implementations here:
>> 
>> https://github.com/plevart/acquire-release-close
>> 
>> Running it on my 8 core (16 threads) Linux PC, it gives promising results without regression for single-threaded use:
>> 
>> 
>> ** Simple, measure run #1...
>> concurrency: 1, nanos: 39909697 (x 1.0)
>> concurrency: 2, nanos: 164735444 (x 4.127704702944751)
>> concurrency: 4, nanos: 394283724 (x 9.87939657873123)
>> concurrency: 8, nanos: 672278915 (x 16.84500172978011)
>> concurrency: 16, nanos: 2169282886 (x 54.3547821473062)
>> ** Simple, measure run #2...
>> concurrency: 1, nanos: 40318379 (x 1.0)
>> concurrency: 2, nanos: 163438657 (x 4.053701092496799)
>> concurrency: 4, nanos: 399382210 (x 9.905710991009832)
>> concurrency: 8, nanos: 694862623 (x 17.23438888750959)
>> concurrency: 16, nanos: 2182386494 (x 54.12882531810121)
>> ** Simple, measure run #3...
>> concurrency: 1, nanos: 39871197 (x 1.0)
>> concurrency: 2, nanos: 168843686 (x 4.234728292707139)
>> concurrency: 4, nanos: 375489497 (x 9.417562683156966)
>> concurrency: 8, nanos: 675885694 (x 16.951728186138983)
>> concurrency: 16, nanos: 2083500812 (x 52.255787856080666)
>> ** end.
>> 
>> ** Striped, measure run #1...
>> concurrency: 1, nanos: 36698350 (x 1.0)
>> concurrency: 2, nanos: 47349695 (x 1.290240433152989)
>> concurrency: 4, nanos: 58622304 (x 1.5974098018030782)
>> concurrency: 8, nanos: 60548173 (x 1.6498881557345222)
>> concurrency: 16, nanos: 70607406 (x 1.9239940215295783)
>> ** Striped, measure run #2...
>> concurrency: 1, nanos: 37217044 (x 1.0)
>> concurrency: 2, nanos: 38610020 (x 1.0374284427317764)
>> concurrency: 4, nanos: 39166893 (x 1.0523912914738742)
>> concurrency: 8, nanos: 51778829 (x 1.3912665659314587)
>> concurrency: 16, nanos: 70277394 (x 1.8883120862581133)
>> ** Striped, measu...
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8371260: Prevent two theoretical reorderings of volatile write beyond volatile read

Hm, I'm trying to see why some tests are failing...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29866#issuecomment-3943752935

From dfuchs at openjdk.org  Mon Feb 23 10:45:46 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 23 Feb 2026 10:45:46 GMT
Subject: RFR: 8378378: Remove references to obsolete
 jdk.net.usePlainDatagramSocketImpl property from tests
In-Reply-To: <u5AsYpwj5lBAVG8m4_wTbIuop804rWs7dlUWgnICNUA=.56dc3b7f-a9e9-4c65-a187-55e754b578d3@github.com>
References: <u5AsYpwj5lBAVG8m4_wTbIuop804rWs7dlUWgnICNUA=.56dc3b7f-a9e9-4c65-a187-55e754b578d3@github.com>
Message-ID: <_EuJfOa-XMObXptI5Adg8RlZ61F0ZtVV3sRrfw-BGVY=.4dfb97d8-8c70-48fb-8719-ed3ca3b9ee9a@github.com>

On Mon, 23 Feb 2026 01:14:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which removes reference to the obsolete `jdk.net.usePlainDatagramSocketImpl` property?
> 
> This property and the related fallback support was removed in https://bugs.openjdk.org/browse/JDK-8253119. The property plays no role anymore. The tests continue to pass after this change.

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29871#pullrequestreview-3840296411

From flmartin at cegid.com  Mon Feb 23 10:53:44 2026
From: flmartin at cegid.com (Florent MARTIN)
Date: Mon, 23 Feb 2026 10:53:44 +0000
Subject: macOS: pkg signing full chain workflow
In-Reply-To: <MRWPR01MB12445D43463D74871856B9F23DE62A@MRWPR01MB12445.eurprd01.prod.exchangelabs.com>
References: <MRWPR01MB12445D43463D74871856B9F23DE62A@MRWPR01MB12445.eurprd01.prod.exchangelabs.com>
Message-ID: <MRWPR01MB12445A5B7ADC4B1CFA89C1DEEDE77A@MRWPR01MB12445.eurprd01.prod.exchangelabs.com>

Hello,

For an application, I need to create a pkg for macOS of a Java application, but jpackage does not provide support for all the steps required. As a reminder, here is the full workflow needed to create a valid pkg that passes Gatekeeper on macOS, which requires three different certificates:

  *   A standard signing certificate
  *   An Apple Developer ID Application certificate
  *   An Apple Developer ID Installer certificate

The full workflow is:

  1.  Signing the native libraries inside the JAR (requires a Developer ID Application certificate)
     *   Basically, this involves extracting the JAR, signing all .jnilib and .dylib files, and rebuilding the JAR.
  2.  Signing the JAR itself (requires a standard certificate)
     *   Using jarsigner to pass the JVM security check.
  3.  Generating an application image (.app)
  4.  Signing the native libraries included in the image (requires a Developer ID Application certificate)
  5.  Signing the main executable of the image (requires a Developer ID Application certificate)
  6.  Signing the main bundle of the image (requires a Developer ID Application certificate)
  7.  (Optional) Adding an entitlements.plist file to allow JNI usage
     *   Needed if using restricted features such as JNI.
  8.  Creating the installer package (.pkg)
  9.  Signing the installer package (requires a Developer ID Installer certificate)
  10. Notarizing the package (submission to Apple for verification)
  11. Stapling the package (embedding the notarization directly into the package)

If we skip steps 1 and 2 for preparing the JAR (it would be better if jpackage could handle this automatically), as well as steps 10 and 11, then for steps 3 to 9 we need to use two different certificates, but jpackage provides only a single `--mac-sign` parameter, which does not support multiple certificates and would ideally be split into separate parameters for the application certificate and the installer certificate; as a result, when creating a pkg with jpackage, the App Image inside remains unsigned, which causes Gatekeeper to block the application.

Best regards,
Florent MARTIN
D?veloppeur
Cegid Relations Bancaires

+33 (0)2 99 55 33 22
flmartin at cegid.com<mailto:flmartin at cegid.com>

[Facebook]<https://www.facebook.com/CegidGroup/>  [Twitter] <https://twitter.com/CegidGroup>   [LinkedIn] <https://fr.linkedin.com/company/cegid>
cegid.com<https://www.cegid.com/>
[Cegid]<http://www.cegid.com/>




Cegid est susceptible d'effectuer un traitement sur vos donn?es personnelles ? des fins de gestion de notre relation commerciale. Pour plus d'information, consultez https://www.cegid.com/fr/privacy-policy
Ce message et les pi?ces jointes sont confidentiels et ?tablis ? l'attention exclusive de ses destinataires. Toute utilisation ou diffusion, m?me partielle, non autoris?e est interdite. Tout message ?lectronique est susceptible d'alt?ration; Cegid d?cline donc toute responsabilit? au titre de ce message. Si vous n'?tes pas le destinataire de ce message, merci de le d?truire et d'avertir l'exp?diteur.

Cegid may process your personal data for the purpose of our business relationship management. For more information, please visit our website https://www.cegid.com/en/privacy-policy
This message and any attachments are confidential and intended solely for the addressees. Any unauthorized use or disclosure, either whole or partial is prohibited. E-mails are susceptible to alteration; Cegid shall therefore not be liable for the content of this message. If you are not the intended recipient of this message, please delete it and notify the sender.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260223/bdf09bcd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1048 bytes
Desc: image001.png
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260223/bdf09bcd/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1264 bytes
Desc: image002.png
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260223/bdf09bcd/image002-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 1388 bytes
Desc: image003.png
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260223/bdf09bcd/image003-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 8492 bytes
Desc: image004.png
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260223/bdf09bcd/image004-0001.png>

From ogillespie at openjdk.org  Mon Feb 23 11:12:22 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Mon, 23 Feb 2026 11:12:22 GMT
Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v3]
In-Reply-To: <M5Kk3KWYQZ5UagIv_f-nNwN8gNby1VZP3TlFsXUkBwY=.bfb41c1f-091f-4df4-b68f-6155607db159@github.com>
References: <M5Kk3KWYQZ5UagIv_f-nNwN8gNby1VZP3TlFsXUkBwY=.bfb41c1f-091f-4df4-b68f-6155607db159@github.com>
Message-ID: <qMRILxOM9XhFYp_lRrGetI7Pvc2_ThyKYdZFRJ0AA7c=.f17db465-7bfd-4b69-9945-1c7775a56910@github.com>

> `TreeMap` sub-maps use the default `IteratorSpliterator` implementation for `TreeMap$EntrySetView` which is slow for some operations, because `EntrySetView.size()` iterates all elements. This is most trivially shown by something like `largeTreeMap.tailMap(0L, false).entrySet().limit(1).count()` taking a long time. This showed up in my application, where it was trivial to mitigate by switching to a for loop, but I think the fix is easy enough.
> 
> `keySet()` does not have the same problem, as it provides a custom `Spliterator` implementation which is not `Spliterator.SIZED`, and returns `Long.MAX_VALUE` for `estimateSize()` (which is the recommended approach when the size is expensive to compute). I'm *assuming* this optimization was simply missed for the EntryIterator in the original implementation, but I don't know for sure.
> 
> This patch fixes the issue by providing a custom spliterator for `EntrySetView`, which is not SIZED. The implementation is copied almost exactly from the equivalent `KeyIterator` classes in this file (`SubMapKeyIterator`, `DescendingSubMapKeyIterator`). The only difference is in `SubMapEntryIterator.getComparator`, for which I copied the implementation from `TreeMap$EntrySpliterator`.
> 
> 
> Basic performance test: `map.tailMap(0L, false).entrySet().stream().limit(1).count()` for a `TreeMap` with `10_000_000` entries.
> 
> Before (keySet is fast using `SubMapKeyIterator`, entrySet is slow using `IteratorSpliterator`):
> 
> class java.util.TreeMap$KeySet
>     .stream().limit(1).count() took 0.046ms
>     spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807
> class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView
>     .stream().limit(1).count() took 218ms
>     spliterator = IteratorSpliterator, estimateSize() = 9999999 
> 
> 
> After (entrySet is now fast, using `SubMapEntryIterator`):
> 
> class java.util.TreeMap$KeySet
> 	.stream().limit(1).count() took 0.017ms
> 	spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807
> class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView
> 	.stream().limit(1).count() took 0.013ms
> 	spliterator = SubMapEntryIterator, estimateSize() = 9223372036854775807

Oli Gillespie 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 8372946
 - Fix failing test
 - Attempt to fix 8372946

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28608/files
  - new: https://git.openjdk.org/jdk/pull/28608/files/9e669145..e8bda724

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28608&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28608&range=01-02

  Stats: 783324 lines in 5939 files changed: 403540 ins; 330673 del; 49111 mod
  Patch: https://git.openjdk.org/jdk/pull/28608.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28608/head:pull/28608

PR: https://git.openjdk.org/jdk/pull/28608

From ogillespie at openjdk.org  Mon Feb 23 11:16:16 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Mon, 23 Feb 2026 11:16:16 GMT
Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v4]
In-Reply-To: <M5Kk3KWYQZ5UagIv_f-nNwN8gNby1VZP3TlFsXUkBwY=.bfb41c1f-091f-4df4-b68f-6155607db159@github.com>
References: <M5Kk3KWYQZ5UagIv_f-nNwN8gNby1VZP3TlFsXUkBwY=.bfb41c1f-091f-4df4-b68f-6155607db159@github.com>
Message-ID: <kVAdSfhQqpvUoirf-FPTCyONo-YnIOnBdqRneppV1-8=.cc90825b-41ca-4443-bf1c-aa056b42ffc5@github.com>

> `TreeMap` sub-maps use the default `IteratorSpliterator` implementation for `TreeMap$EntrySetView` which is slow for some operations, because `EntrySetView.size()` iterates all elements. This is most trivially shown by something like `largeTreeMap.tailMap(0L, false).entrySet().limit(1).count()` taking a long time. This showed up in my application, where it was trivial to mitigate by switching to a for loop, but I think the fix is easy enough.
> 
> `keySet()` does not have the same problem, as it provides a custom `Spliterator` implementation which is not `Spliterator.SIZED`, and returns `Long.MAX_VALUE` for `estimateSize()` (which is the recommended approach when the size is expensive to compute). I'm *assuming* this optimization was simply missed for the EntryIterator in the original implementation, but I don't know for sure.
> 
> This patch fixes the issue by providing a custom spliterator for `EntrySetView`, which is not SIZED. The implementation is copied almost exactly from the equivalent `KeyIterator` classes in this file (`SubMapKeyIterator`, `DescendingSubMapKeyIterator`). The only difference is in `SubMapEntryIterator.getComparator`, for which I copied the implementation from `TreeMap$EntrySpliterator`.
> 
> 
> Basic performance test: `map.tailMap(0L, false).entrySet().stream().limit(1).count()` for a `TreeMap` with `10_000_000` entries.
> 
> Before (keySet is fast using `SubMapKeyIterator`, entrySet is slow using `IteratorSpliterator`):
> 
> class java.util.TreeMap$KeySet
>     .stream().limit(1).count() took 0.046ms
>     spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807
> class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView
>     .stream().limit(1).count() took 218ms
>     spliterator = IteratorSpliterator, estimateSize() = 9999999 
> 
> 
> After (entrySet is now fast, using `SubMapEntryIterator`):
> 
> class java.util.TreeMap$KeySet
> 	.stream().limit(1).count() took 0.017ms
> 	spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807
> class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView
> 	.stream().limit(1).count() took 0.013ms
> 	spliterator = SubMapEntryIterator, estimateSize() = 9223372036854775807

Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:

  Use Spliterators.spliteratorUnknownSize

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28608/files
  - new: https://git.openjdk.org/jdk/pull/28608/files/e8bda724..144216ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28608&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28608&range=02-03

  Stats: 70 lines in 1 file changed: 2 ins; 65 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28608.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28608/head:pull/28608

PR: https://git.openjdk.org/jdk/pull/28608

From ogillespie at openjdk.org  Mon Feb 23 11:35:12 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Mon, 23 Feb 2026 11:35:12 GMT
Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v4]
In-Reply-To: <kVAdSfhQqpvUoirf-FPTCyONo-YnIOnBdqRneppV1-8=.cc90825b-41ca-4443-bf1c-aa056b42ffc5@github.com>
References: <M5Kk3KWYQZ5UagIv_f-nNwN8gNby1VZP3TlFsXUkBwY=.bfb41c1f-091f-4df4-b68f-6155607db159@github.com>
 <kVAdSfhQqpvUoirf-FPTCyONo-YnIOnBdqRneppV1-8=.cc90825b-41ca-4443-bf1c-aa056b42ffc5@github.com>
Message-ID: <vC2v-bC5AG0brylnZWpsYUFBG1Lf03315i6Awp93hr8=.ad77b243-39fd-4c54-aad9-0af7b8e247ca@github.com>

On Mon, 23 Feb 2026 11:16:16 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> `TreeMap` sub-maps use the default `IteratorSpliterator` implementation for `TreeMap$EntrySetView` which is slow for some operations, because `EntrySetView.size()` iterates all elements. This is most trivially shown by something like `largeTreeMap.tailMap(0L, false).entrySet().limit(1).count()` taking a long time. This showed up in my application, where it was trivial to mitigate by switching to a for loop, but I think the fix is easy enough.
>> 
>> `keySet()` does not have the same problem, as it provides a custom `Spliterator` implementation which is not `Spliterator.SIZED`, and returns `Long.MAX_VALUE` for `estimateSize()` (which is the recommended approach when the size is expensive to compute). I'm *assuming* this optimization was simply missed for the EntryIterator in the original implementation, but I don't know for sure.
>> 
>> This patch fixes the issue by using `Spliterators.spliteratorUnknownSize` for `EntrySetView`, marking the size as unknown avoids accidentally iterating the whole thing for simple operations.
>> 
>> 
>> Basic performance test: `map.tailMap(0L, false).entrySet().stream().limit(1).count()` for a `TreeMap` with `10_000_000` entries.
>> 
>> Before (keySet is fast using `SubMapKeyIterator`, entrySet is slow):
>> 
>> class java.util.TreeMap$KeySet
>>     .stream().limit(1).count() took 0.046ms
>>     spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807
>> class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView
>>     .stream().limit(1).count() took 218ms
>>     spliterator = IteratorSpliterator, estimateSize() = 9999999 
>> 
>> 
>> After (entrySet is now fast):
>> 
>> class java.util.TreeMap$KeySet
>> 	.stream().limit(1).count() took 0.017ms
>> 	spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807
>> class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView
>> 	.stream().limit(1).count() took 0.115419ms
>> 	spliterator = IteratorSpliterator, estimateSize() = 9223372036854775807
>> 
>> 
>> Behaviour is tested by the test cases added in https://bugs.openjdk.org/browse/JDK-8376698.
>> 
>> CollectionAndMapModifyStreamTes intentionally modifies the backing map while holding an iterator, which is not safe in general. It got away with it before, but the new implementation reasonably throws CME, so added descendingMap to the ignore list similar to headMap.
>
> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Spliterators.spliteratorUnknownSize

Updated with the simpler implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28608#issuecomment-3944229912

From plevart at openjdk.org  Mon Feb 23 11:46:29 2026
From: plevart at openjdk.org (Peter Levart)
Date: Mon, 23 Feb 2026 11:46:29 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas, take 2 [v3]
In-Reply-To: <v1EodJYVhybUixNNmOriqvyw0uDl12EdD2fMN9dCFz0=.33c50295-fcb8-4bb4-b75a-637553feb4f9@github.com>
References: <v1EodJYVhybUixNNmOriqvyw0uDl12EdD2fMN9dCFz0=.33c50295-fcb8-4bb4-b75a-637553feb4f9@github.com>
Message-ID: <FzuidARtZvWUXAsP-owv-430dRlO77SbIvOmWpFJ5TQ=.22ade2b4-ed37-437b-8673-4fe2eda7315f@github.com>

> Hi,
> 
> When administering my mailing lists, my attention was drawn to this pull request: https://github.com/openjdk/jdk/pull/28575, which tries to tackle this scaling problem. Although it was dismissed, I remembered that I was dealing with a similar problem in the past, so I looked closely...
> 
> Here's an alternative take at the problem. It reuses a maintained public component of JDK, the LongAdder, so in this respect, it does not add complexity and maintainance burden. It also does not change the internal API of the MemorySessionImpl. The size of the patch is also smaller.
> 
> For experimenting and benchmarking, I created a separate impmenetation of just the acquire/release/close logic with existing "simple" and this new "striped" implementations here:
> 
> https://github.com/plevart/acquire-release-close
> 
> Running it on my 8 core (16 threads) Linux PC, it gives promising results without regression for single-threaded use:
> 
> 
> ** Simple, measure run #1...
> concurrency: 1, nanos: 39909697 (x 1.0)
> concurrency: 2, nanos: 164735444 (x 4.127704702944751)
> concurrency: 4, nanos: 394283724 (x 9.87939657873123)
> concurrency: 8, nanos: 672278915 (x 16.84500172978011)
> concurrency: 16, nanos: 2169282886 (x 54.3547821473062)
> ** Simple, measure run #2...
> concurrency: 1, nanos: 40318379 (x 1.0)
> concurrency: 2, nanos: 163438657 (x 4.053701092496799)
> concurrency: 4, nanos: 399382210 (x 9.905710991009832)
> concurrency: 8, nanos: 694862623 (x 17.23438888750959)
> concurrency: 16, nanos: 2182386494 (x 54.12882531810121)
> ** Simple, measure run #3...
> concurrency: 1, nanos: 39871197 (x 1.0)
> concurrency: 2, nanos: 168843686 (x 4.234728292707139)
> concurrency: 4, nanos: 375489497 (x 9.417562683156966)
> concurrency: 8, nanos: 675885694 (x 16.951728186138983)
> concurrency: 16, nanos: 2083500812 (x 52.255787856080666)
> ** end.
> 
> ** Striped, measure run #1...
> concurrency: 1, nanos: 36698350 (x 1.0)
> concurrency: 2, nanos: 47349695 (x 1.290240433152989)
> concurrency: 4, nanos: 58622304 (x 1.5974098018030782)
> concurrency: 8, nanos: 60548173 (x 1.6498881557345222)
> concurrency: 16, nanos: 70607406 (x 1.9239940215295783)
> ** Striped, measure run #2...
> concurrency: 1, nanos: 37217044 (x 1.0)
> concurrency: 2, nanos: 38610020 (x 1.0374284427317764)
> concurrency: 4, nanos: 39166893 (x 1.0523912914738742)
> concurrency: 8, nanos: 51778829 (x 1.3912665659314587)
> concurrency: 16, nanos: 70277394 (x 1.8883120862581133)
> ** Striped, measure run #3...
> concurrency: 1, nanos: 37589735 (x 1.0)
> concurrency: 2, nanos: 38748261 (x 1.03...

Peter Levart has updated the pull request incrementally with one additional commit since the last revision:

  8371260: Fix wrong VarHandle usage, remove unneeded fullFence from justClose()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29866/files
  - new: https://git.openjdk.org/jdk/pull/29866/files/bced1b62..1a3b0cf7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29866&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29866&range=01-02

  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/29866.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29866/head:pull/29866

PR: https://git.openjdk.org/jdk/pull/29866

From liach at openjdk.org  Mon Feb 23 13:50:40 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 23 Feb 2026 13:50:40 GMT
Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v4]
In-Reply-To: <kVAdSfhQqpvUoirf-FPTCyONo-YnIOnBdqRneppV1-8=.cc90825b-41ca-4443-bf1c-aa056b42ffc5@github.com>
References: <M5Kk3KWYQZ5UagIv_f-nNwN8gNby1VZP3TlFsXUkBwY=.bfb41c1f-091f-4df4-b68f-6155607db159@github.com>
 <kVAdSfhQqpvUoirf-FPTCyONo-YnIOnBdqRneppV1-8=.cc90825b-41ca-4443-bf1c-aa056b42ffc5@github.com>
Message-ID: <zdlkfKNlVhjSwlM69QB8T33nQropqQY_SowxQQ0afG4=.5e09fe10-17eb-40f4-bc49-2204f94b42de@github.com>

On Mon, 23 Feb 2026 11:16:16 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> `TreeMap` sub-maps use the default `IteratorSpliterator` implementation for `TreeMap$EntrySetView` which is slow for some operations, because `EntrySetView.size()` iterates all elements. This is most trivially shown by something like `largeTreeMap.tailMap(0L, false).entrySet().limit(1).count()` taking a long time. This showed up in my application, where it was trivial to mitigate by switching to a for loop, but I think the fix is easy enough.
>> 
>> `keySet()` does not have the same problem, as it provides a custom `Spliterator` implementation which is not `Spliterator.SIZED`, and returns `Long.MAX_VALUE` for `estimateSize()` (which is the recommended approach when the size is expensive to compute). I'm *assuming* this optimization was simply missed for the EntryIterator in the original implementation, but I don't know for sure.
>> 
>> This patch fixes the issue by using `Spliterators.spliteratorUnknownSize` for `EntrySetView`, marking the size as unknown avoids accidentally iterating the whole thing for simple operations.
>> 
>> 
>> Basic performance test: `map.tailMap(0L, false).entrySet().stream().limit(1).count()` for a `TreeMap` with `10_000_000` entries.
>> 
>> Before (keySet is fast using `SubMapKeyIterator`, entrySet is slow):
>> 
>> class java.util.TreeMap$KeySet
>>     .stream().limit(1).count() took 0.046ms
>>     spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807
>> class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView
>>     .stream().limit(1).count() took 218ms
>>     spliterator = IteratorSpliterator, estimateSize() = 9999999 
>> 
>> 
>> After (entrySet is now fast):
>> 
>> class java.util.TreeMap$KeySet
>> 	.stream().limit(1).count() took 0.017ms
>> 	spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807
>> class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView
>> 	.stream().limit(1).count() took 0.115419ms
>> 	spliterator = IteratorSpliterator, estimateSize() = 9223372036854775807
>> 
>> 
>> Behaviour is tested by the test cases added in https://bugs.openjdk.org/browse/JDK-8376698.
>> 
>> CollectionAndMapModifyStreamTest intentionally modifies the backing map while holding an iterator, which is not safe in general. It got away with it before, but the new implementation reasonably throws CME, so added descendingMap to the ignore list similar to headMap.
>
> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Spliterators.spliteratorUnknownSize

test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java line 123:

> 121: 
> 122:         // The following are not lazy
> 123: //        maps.put(TreeMap.class.getName() + ".descendingMap()", () -> new TreeMap<>(content).descendingMap());

Is this test modification still necessary?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28608#discussion_r2840959875

From ogillespie at openjdk.org  Mon Feb 23 14:20:05 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Mon, 23 Feb 2026 14:20:05 GMT
Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v4]
In-Reply-To: <zdlkfKNlVhjSwlM69QB8T33nQropqQY_SowxQQ0afG4=.5e09fe10-17eb-40f4-bc49-2204f94b42de@github.com>
References: <M5Kk3KWYQZ5UagIv_f-nNwN8gNby1VZP3TlFsXUkBwY=.bfb41c1f-091f-4df4-b68f-6155607db159@github.com>
 <kVAdSfhQqpvUoirf-FPTCyONo-YnIOnBdqRneppV1-8=.cc90825b-41ca-4443-bf1c-aa056b42ffc5@github.com>
 <zdlkfKNlVhjSwlM69QB8T33nQropqQY_SowxQQ0afG4=.5e09fe10-17eb-40f4-bc49-2204f94b42de@github.com>
Message-ID: <I7tsrhzAwGOb5Ri_kmrnjtimgGv2GtX85MnKu9YhIJk=.76d53686-bf1c-4c45-90d6-66a49e3d45b8@github.com>

On Mon, 23 Feb 2026 13:48:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use Spliterators.spliteratorUnknownSize
>
> test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java line 123:
> 
>> 121: 
>> 122:         // The following are not lazy
>> 123: //        maps.put(TreeMap.class.getName() + ".descendingMap()", () -> new TreeMap<>(content).descendingMap());
> 
> Is this test modification still necessary?

That case still fails, yes, but I'm not totally sure why. I'm looking into it.


java.util.ConcurrentModificationException
	at java.base/java.util.TreeMap$NavigableSubMap$SubMapIterator.prevEntry(TreeMap.java:2070)
	at java.base/java.util.TreeMap$NavigableSubMap$DescendingSubMapEntryIterator.next(TreeMap.java:2121)
	at java.base/java.util.TreeMap$NavigableSubMap$DescendingSubMapEntryIterator.next(TreeMap.java:2114)
	at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
	at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1939)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:570)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:560)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:635)
	at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:291)
	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:652)
	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:658)
	at org.openjdk.tests.java.util.stream.CollectionAndMapModifyStreamTest.testEntrySetSizeRemove(CollectionAndMapModifyStreamTest.java:164)
	at org.openjdk.tests.java.util.stream.CollectionAndMapModifyStreamTest.testMapEntriesSizeRemove(CollectionAndMapModifyStreamTest.java:155)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28608#discussion_r2841102126

From rgiulietti at openjdk.org  Mon Feb 23 14:34:07 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 23 Feb 2026 14:34:07 GMT
Subject: RFR: 8378414: Add methods to test for representation equivalence
In-Reply-To: <0c0gdxzdx89GRTz0mEbpIndhAocsMwbpUGhvCNb8IYQ=.46355665-6ab6-455d-83e3-5947b34a6fb6@github.com>
References: <mioOgE5dVvyj1CgG7BNDyixbbwIOyRFqKs9s7-vgqCE=.825997f5-c363-4a94-a45b-499dfa255420@github.com>
 <zYuApVBaFbPz_VrCHEIctFlnpyoA8CO8XGbxncUMGrw=.c3a6b218-19e9-4e86-bc2f-a6af7d0a16a0@github.com>
 <0c0gdxzdx89GRTz0mEbpIndhAocsMwbpUGhvCNb8IYQ=.46355665-6ab6-455d-83e3-5947b34a6fb6@github.com>
Message-ID: <Uqc5EfZAgrIdJG5GjP382R5e5ErOQATb3FHIpAB7LYA=.756e1b4a-eb0f-462b-a712-39d2623e418b@github.com>

On Mon, 23 Feb 2026 02:45:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This equivalence is already covered by their `equals(Object)` methods. I would assume they are declared as `equals(double, double)` etc. similar to how instance `Double::isInfinite()` and static `Double::isInfinite(double)` are declared.
>
>> This equivalence is already covered by their `equals(Object)` methods. I would assume they are declared as `equals(double, double)` etc. similar to how instance `Double::isInfinite()` and static `Double::isInfinite(double)` are declared.
> 
> It is true that there are already multiple expressions using existing methods can be written to implement that functionality. However, conceptually, I don't think boxing up to Double should be necessary (or desirable).

@jddarcy The `java/lang/Math` tests fail (but disregard my previous message).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29870#issuecomment-3945104630

From ogillespie at openjdk.org  Mon Feb 23 14:43:42 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Mon, 23 Feb 2026 14:43:42 GMT
Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v4]
In-Reply-To: <I7tsrhzAwGOb5Ri_kmrnjtimgGv2GtX85MnKu9YhIJk=.76d53686-bf1c-4c45-90d6-66a49e3d45b8@github.com>
References: <M5Kk3KWYQZ5UagIv_f-nNwN8gNby1VZP3TlFsXUkBwY=.bfb41c1f-091f-4df4-b68f-6155607db159@github.com>
 <kVAdSfhQqpvUoirf-FPTCyONo-YnIOnBdqRneppV1-8=.cc90825b-41ca-4443-bf1c-aa056b42ffc5@github.com>
 <zdlkfKNlVhjSwlM69QB8T33nQropqQY_SowxQQ0afG4=.5e09fe10-17eb-40f4-bc49-2204f94b42de@github.com>
 <I7tsrhzAwGOb5Ri_kmrnjtimgGv2GtX85MnKu9YhIJk=.76d53686-bf1c-4c45-90d6-66a49e3d45b8@github.com>
Message-ID: <EdriGMb-EC4hEuUqJvyCGuvXq9GOgwelp5t0B9X9un8=.f207febf-7613-4576-901b-a90e99fd112a@github.com>

On Mon, 23 Feb 2026 14:17:53 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java line 123:
>> 
>>> 121: 
>>> 122:         // The following are not lazy
>>> 123: //        maps.put(TreeMap.class.getName() + ".descendingMap()", () -> new TreeMap<>(content).descendingMap());
>> 
>> Is this test modification still necessary?
>
> That case still fails, yes, but I'm not totally sure why. I'm looking into it.
> 
> 
> java.util.ConcurrentModificationException
> 	at java.base/java.util.TreeMap$NavigableSubMap$SubMapIterator.prevEntry(TreeMap.java:2070)
> 	at java.base/java.util.TreeMap$NavigableSubMap$DescendingSubMapEntryIterator.next(TreeMap.java:2121)
> 	at java.base/java.util.TreeMap$NavigableSubMap$DescendingSubMapEntryIterator.next(TreeMap.java:2114)
> 	at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> 	at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1939)
> 	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:570)
> 	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:560)
> 	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:635)
> 	at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:291)
> 	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:652)
> 	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:658)
> 	at org.openjdk.tests.java.util.stream.CollectionAndMapModifyStreamTest.testEntrySetSizeRemove(CollectionAndMapModifyStreamTest.java:164)
> 	at org.openjdk.tests.java.util.stream.CollectionAndMapModifyStreamTest.testMapEntriesSizeRemove(CollectionAndMapModifyStreamTest.java:155)

Oh I understand now. The default Set spliterator is `Spliterator<T> spliterator(Collection<? extends T> c, int characteristics)`. It doesn't create an iterator until forEachRemaining is called, which in the test is *after* the .remove modification, so it doesn't observe a discrepancy. The new implementation uses creates the iterator up-front to pass to `spliteratorUnknownSize`, so in that case the iterator is created before the modification, hence CME.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28608#discussion_r2841224287

From ogillespie at openjdk.org  Mon Feb 23 14:47:32 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Mon, 23 Feb 2026 14:47:32 GMT
Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v4]
In-Reply-To: <EdriGMb-EC4hEuUqJvyCGuvXq9GOgwelp5t0B9X9un8=.f207febf-7613-4576-901b-a90e99fd112a@github.com>
References: <M5Kk3KWYQZ5UagIv_f-nNwN8gNby1VZP3TlFsXUkBwY=.bfb41c1f-091f-4df4-b68f-6155607db159@github.com>
 <kVAdSfhQqpvUoirf-FPTCyONo-YnIOnBdqRneppV1-8=.cc90825b-41ca-4443-bf1c-aa056b42ffc5@github.com>
 <zdlkfKNlVhjSwlM69QB8T33nQropqQY_SowxQQ0afG4=.5e09fe10-17eb-40f4-bc49-2204f94b42de@github.com>
 <I7tsrhzAwGOb5Ri_kmrnjtimgGv2GtX85MnKu9YhIJk=.76d53686-bf1c-4c45-90d6-66a49e3d45b8@github.com>
 <EdriGMb-EC4hEuUqJvyCGuvXq9GOgwelp5t0B9X9un8=.f207febf-7613-4576-901b-a90e99fd112a@github.com>
Message-ID: <DHMy4lgZXGGUXs_g5dgzkldBx7VEKnzOkCsXs_6loPw=.da834dd8-7b93-42e5-a084-583f09e61680@github.com>

On Mon, 23 Feb 2026 14:40:57 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> That case still fails, yes, but I'm not totally sure why. I'm looking into it.
>> 
>> 
>> java.util.ConcurrentModificationException
>> 	at java.base/java.util.TreeMap$NavigableSubMap$SubMapIterator.prevEntry(TreeMap.java:2070)
>> 	at java.base/java.util.TreeMap$NavigableSubMap$DescendingSubMapEntryIterator.next(TreeMap.java:2121)
>> 	at java.base/java.util.TreeMap$NavigableSubMap$DescendingSubMapEntryIterator.next(TreeMap.java:2114)
>> 	at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>> 	at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1939)
>> 	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:570)
>> 	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:560)
>> 	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:635)
>> 	at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:291)
>> 	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:652)
>> 	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:658)
>> 	at org.openjdk.tests.java.util.stream.CollectionAndMapModifyStreamTest.testEntrySetSizeRemove(CollectionAndMapModifyStreamTest.java:164)
>> 	at org.openjdk.tests.java.util.stream.CollectionAndMapModifyStreamTest.testMapEntriesSizeRemove(CollectionAndMapModifyStreamTest.java:155)
>
> Oh I understand now. The default Set spliterator is `Spliterator<T> spliterator(Collection<? extends T> c, int characteristics)`. It doesn't create an iterator until forEachRemaining is called, which in the test is *after* the .remove modification, so it doesn't observe a discrepancy. The new implementation uses creates the iterator up-front to pass to `spliteratorUnknownSize`, so in that case the iterator is created before the modification, hence CME.

It ends up something like this:


public static void main(String[] args) {
    List<String> strings = new LinkedList<>();
    strings.add("foo");
    strings.add("bar");

    Spliterator<String> s = Spliterators.spliterator(strings, Spliterator.DISTINCT); // Don't create iterator yet
    strings.remove(strings.iterator().next());
    s.forEachRemaining(System.out::println); // Spliterator creates iterator here, after the .remove call. No CME

    s = Spliterators.spliteratorUnknownSize(strings.iterator(), Spliterator.DISTINCT); // Eagerly create the iterator
    strings.remove(strings.iterator().next()); // Modifying after the iterator was created
    s.forEachRemaining(System.out::println); // ConcurrentModificationException
}


So it's just a side effect of `spliteratorUnknownSize` needing the iterator to be created already. I think the test skip is valid, then - it's true that this case is no longer lazy like it was.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28608#discussion_r2841246021

From rriggs at openjdk.org  Mon Feb 23 15:03:13 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 23 Feb 2026 15:03:13 GMT
Subject: RFR: 8378118: Test tools/jimage/JImageBadFileTest.java failed on
 Windows
In-Reply-To: <osTab7bHlL02EfiBJGHxrsjqzGcRVxrS8jbWWVz_eFg=.ed9d1730-0cd6-425c-9ccf-ebd7e1e96a79@github.com>
References: <osTab7bHlL02EfiBJGHxrsjqzGcRVxrS8jbWWVz_eFg=.ed9d1730-0cd6-425c-9ccf-ebd7e1e96a79@github.com>
Message-ID: <Oz0MYlG6I9qUbvKGncoQ0r6VMiN5B7bf_-dAdrBx2as=.25135ea0-dda5-4676-8fe2-b77da5f20d23@github.com>

On Wed, 18 Feb 2026 10:42:01 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removed the manual file tidyup on the expectation that jtreg will sort that all out.
> Switched to using Utils.createTempFile() while I was there.

Good to clean up the CI.

test/jdk/tools/jimage/JImageBadFileTest.java line 145:

> 143:         // Self test that the file copying isn't itself corrupting anything.
> 144:         Path tempJimage = writeModifiedJimage("good_file", -1, b -> {});
> 145:         jimage("info", tempJimage.toString()).assertSuccess();

I know its a bit late to complain now, but "jimage" is not a very nor a very descriptive name of a central utility method.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29783#pullrequestreview-3841592785
PR Review Comment: https://git.openjdk.org/jdk/pull/29783#discussion_r2841339788

From alanb at openjdk.org  Mon Feb 23 15:28:26 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Feb 2026 15:28:26 GMT
Subject: RFR: 8378118: Test tools/jimage/JImageBadFileTest.java failed on
 Windows
In-Reply-To: <Oz0MYlG6I9qUbvKGncoQ0r6VMiN5B7bf_-dAdrBx2as=.25135ea0-dda5-4676-8fe2-b77da5f20d23@github.com>
References: <osTab7bHlL02EfiBJGHxrsjqzGcRVxrS8jbWWVz_eFg=.ed9d1730-0cd6-425c-9ccf-ebd7e1e96a79@github.com>
 <Oz0MYlG6I9qUbvKGncoQ0r6VMiN5B7bf_-dAdrBx2as=.25135ea0-dda5-4676-8fe2-b77da5f20d23@github.com>
Message-ID: <JmFRxrp87hpEQ43e7vqTbksprvFLTRbd0PcncYIifUs=.2d50f115-9b81-4c9f-bade-2d29eb231ae5@github.com>

On Mon, 23 Feb 2026 15:00:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Removed the manual file tidyup on the expectation that jtreg will sort that all out.
>> Switched to using Utils.createTempFile() while I was there.
>
> test/jdk/tools/jimage/JImageBadFileTest.java line 145:
> 
>> 143:         // Self test that the file copying isn't itself corrupting anything.
>> 144:         Path tempJimage = writeModifiedJimage("good_file", -1, b -> {});
>> 145:         jimage("info", tempJimage.toString()).assertSuccess();
> 
> I know its a bit late to complain now, but "jimage" is not a very nor a very descriptive name of a central utility method.

It's a method on JImageCliTest, the super class of the tests for the jimage tool.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29783#discussion_r2841476475

From liach at openjdk.org  Mon Feb 23 15:35:40 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 23 Feb 2026 15:35:40 GMT
Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v4]
In-Reply-To: <DHMy4lgZXGGUXs_g5dgzkldBx7VEKnzOkCsXs_6loPw=.da834dd8-7b93-42e5-a084-583f09e61680@github.com>
References: <M5Kk3KWYQZ5UagIv_f-nNwN8gNby1VZP3TlFsXUkBwY=.bfb41c1f-091f-4df4-b68f-6155607db159@github.com>
 <kVAdSfhQqpvUoirf-FPTCyONo-YnIOnBdqRneppV1-8=.cc90825b-41ca-4443-bf1c-aa056b42ffc5@github.com>
 <zdlkfKNlVhjSwlM69QB8T33nQropqQY_SowxQQ0afG4=.5e09fe10-17eb-40f4-bc49-2204f94b42de@github.com>
 <I7tsrhzAwGOb5Ri_kmrnjtimgGv2GtX85MnKu9YhIJk=.76d53686-bf1c-4c45-90d6-66a49e3d45b8@github.com>
 <EdriGMb-EC4hEuUqJvyCGuvXq9GOgwelp5t0B9X9un8=.f207febf-7613-4576-901b-a90e99fd112a@github.com>
 <DHMy4lgZXGGUXs_g5dgzkldBx7VEKnzOkCsXs_6loPw=.da834dd8-7b93-42e5-a084-583f09e61680@github.com>
Message-ID: <pzruiRy5OL0aqki3JEKxVAeQVybZRBvg8ksd8N2r8KI=.cb791880-795b-46d5-8b79-bda211f6bd91@github.com>

On Mon, 23 Feb 2026 14:44:59 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Oh I understand now. The default Set spliterator is `Spliterator<T> spliterator(Collection<? extends T> c, int characteristics)`. It doesn't create an iterator until forEachRemaining is called, which in the test is *after* the .remove modification, so it doesn't observe a discrepancy. The new implementation uses creates the iterator up-front to pass to `spliteratorUnknownSize`, so in that case the iterator is created before the modification, hence CME.
>
> It ends up something like this:
> 
> 
> public static void main(String[] args) {
>     List<String> strings = new LinkedList<>();
>     strings.add("foo");
>     strings.add("bar");
> 
>     Spliterator<String> s = Spliterators.spliterator(strings, Spliterator.DISTINCT); // Don't create iterator yet
>     strings.remove(strings.iterator().next());
>     s.forEachRemaining(System.out::println); // Spliterator creates iterator here, after the .remove call. No CME
> 
>     s = Spliterators.spliteratorUnknownSize(strings.iterator(), Spliterator.DISTINCT); // Eagerly create the iterator
>     strings.remove(strings.iterator().next()); // Modifying after the iterator was created
>     s.forEachRemaining(System.out::println); // ConcurrentModificationException
> }
> 
> 
> So it's just a side effect of `spliteratorUnknownSize` needing the iterator to be created already. I think the test skip is valid, then - it's true that this case is no longer lazy like it was.

Yes, seems you cannot create a spliterator with a lazy iterator. This is fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28608#discussion_r2841502408

From liach at openjdk.org  Mon Feb 23 15:35:41 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 23 Feb 2026 15:35:41 GMT
Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v4]
In-Reply-To: <pzruiRy5OL0aqki3JEKxVAeQVybZRBvg8ksd8N2r8KI=.cb791880-795b-46d5-8b79-bda211f6bd91@github.com>
References: <M5Kk3KWYQZ5UagIv_f-nNwN8gNby1VZP3TlFsXUkBwY=.bfb41c1f-091f-4df4-b68f-6155607db159@github.com>
 <kVAdSfhQqpvUoirf-FPTCyONo-YnIOnBdqRneppV1-8=.cc90825b-41ca-4443-bf1c-aa056b42ffc5@github.com>
 <zdlkfKNlVhjSwlM69QB8T33nQropqQY_SowxQQ0afG4=.5e09fe10-17eb-40f4-bc49-2204f94b42de@github.com>
 <I7tsrhzAwGOb5Ri_kmrnjtimgGv2GtX85MnKu9YhIJk=.76d53686-bf1c-4c45-90d6-66a49e3d45b8@github.com>
 <EdriGMb-EC4hEuUqJvyCGuvXq9GOgwelp5t0B9X9un8=.f207febf-7613-4576-901b-a90e99fd112a@github.com>
 <DHMy4lgZXGGUXs_g5dgzkldBx7VEKnzOkCsXs_6loPw=.da834dd8-7b93-42e5-a084-583f09e61680@github.com>
 <pzruiRy5OL0aqki3JEKxVAeQVybZRBvg8ksd8N2r8KI=.cb791880-795b-46d5-8b79-bda211f6bd91@github.com>
Message-ID: <MqcByRYB6_RUiifVEaq1G6YlQSQc-NJWtYcc3euXdrY=.a991553d-4631-4cdc-a177-61f346de9e28@github.com>

On Mon, 23 Feb 2026 15:30:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> It ends up something like this:
>> 
>> 
>> public static void main(String[] args) {
>>     List<String> strings = new LinkedList<>();
>>     strings.add("foo");
>>     strings.add("bar");
>> 
>>     Spliterator<String> s = Spliterators.spliterator(strings, Spliterator.DISTINCT); // Don't create iterator yet
>>     strings.remove(strings.iterator().next());
>>     s.forEachRemaining(System.out::println); // Spliterator creates iterator here, after the .remove call. No CME
>> 
>>     s = Spliterators.spliteratorUnknownSize(strings.iterator(), Spliterator.DISTINCT); // Eagerly create the iterator
>>     strings.remove(strings.iterator().next()); // Modifying after the iterator was created
>>     s.forEachRemaining(System.out::println); // ConcurrentModificationException
>> }
>> 
>> 
>> So it's just a side effect of `spliteratorUnknownSize` needing the iterator to be created already. I think the test skip is valid, then - it's true that this case is no longer lazy like it was.
>
> Yes, seems you cannot create a spliterator with a lazy iterator. This is fine.

Alternatively we can override `stream()` to call the `StreamSupport.stream` that takes a `Supplier<? extends Spliterator<T>>` instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28608#discussion_r2841514718

From chen.l.liang at oracle.com  Mon Feb 23 16:02:19 2026
From: chen.l.liang at oracle.com (Chen Liang)
Date: Mon, 23 Feb 2026 16:02:19 +0000
Subject: RFD: ArrayDeque bulk adds and lambda
In-Reply-To: <CA+pBWhvCxgKqtFi_H9BuB4X7=V6exkaBS=KCdba-4vUoR9xOaQ@mail.gmail.com>
References: <CA+pBWhuBF0gJVLnVvCDsAgoPMDTDVoVJ4mAG366PHAsiuX+59g@mail.gmail.com>
 <CA+pBWhvCxgKqtFi_H9BuB4X7=V6exkaBS=KCdba-4vUoR9xOaQ@mail.gmail.com>
Message-ID: <SJ2PR10MB766946AA5F069D6178FBC5A4A277A@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Eirik, this looks like a standard set of classes that should be loaded for lambda expression generation at early bootstrap.
If this particular site does not trigger such loading, any lambda use in user code would still trigger all these.
I think the loop version is only better for bootstrap. Otherwise, in terms of hotspot compilation abilities, these two pieces of code suffer from the same profile pollution problem.

But given that collections are used in early bootstrap in general, I think being bootstrap-proof might be a good idea.

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Eirik Bj?rsn?s <eirbjo at gmail.com>
Sent: Saturday, February 21, 2026 4:45 AM
To: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: RFD: ArrayDeque bulk adds and lambda

On Sat, Feb 21, 2026 at 11:08?AM Eirik Bj?rsn?s <eirbjo at gmail.com<mailto:eirbjo at gmail.com>> wrote:

Can this make ArrayDeque somewhat safer to use in early bootstrap code?

Adding some context from testing:

When modifying the mentioned code to not avoid the lambda bulk operation, nothing crashes but the number of loaded classes during 'java -cp hello.jar' is increased from 576 to 663. Here's a full list of extra classes loaded:

88a89
> java.lang.NoSuchMethodException
148a150,170
> java.lang.classfile.Annotation
> java.lang.classfile.AnnotationElement
> java.lang.classfile.Attribute
> java.lang.classfile.AttributeMapper
> java.lang.classfile.AttributeMapper$AttributeStability
> java.lang.classfile.Attributes
> java.lang.classfile.BootstrapMethodEntry
> java.lang.classfile.ClassElement
> java.lang.classfile.ClassFileElement
> java.lang.classfile.FieldElement
> java.lang.classfile.MethodElement
> java.lang.classfile.TypeKind
> java.lang.classfile.attribute.RuntimeVisibleAnnotationsAttribute
> java.lang.classfile.constantpool.AnnotationConstantValueEntry
> java.lang.classfile.constantpool.ClassEntry
> java.lang.classfile.constantpool.ConstantPool
> java.lang.classfile.constantpool.ConstantPoolBuilder
> java.lang.classfile.constantpool.LoadableConstantEntry
> java.lang.classfile.constantpool.PoolEntry
> java.lang.classfile.constantpool.Utf8Entry
> java.lang.constant.ClassDesc
150a173,182
> java.lang.constant.ConstantDescs
> java.lang.constant.DirectMethodHandleDesc
> java.lang.constant.DirectMethodHandleDesc$Kind
> java.lang.constant.DynamicConstantDesc
> java.lang.constant.DynamicConstantDesc$AnonymousDynamicConstantDesc
> java.lang.constant.MethodHandleDesc
> java.lang.constant.MethodHandleDesc$1
> java.lang.constant.MethodTypeDesc
> java.lang.invoke.AbstractValidatingLambdaMetafactory
> java.lang.invoke.BootstrapMethodInvoker
153a186,193
> java.lang.invoke.DirectMethodHandle$Constructor
> java.lang.invoke.DirectMethodHandle$Holder
> java.lang.invoke.InfoFromMemberName
> java.lang.invoke.InnerClassLambdaMetafactory
> java.lang.invoke.InvokerBytecodeGenerator
> java.lang.invoke.InvokerBytecodeGenerator$8
> java.lang.invoke.Invokers
> java.lang.invoke.Invokers$Holder
154a195,201
> java.lang.invoke.LambdaForm$BasicType
> java.lang.invoke.LambdaForm$Holder
> java.lang.invoke.LambdaForm$Kind
> java.lang.invoke.LambdaForm$Name
> java.lang.invoke.LambdaForm$NamedFunction
> java.lang.invoke.LambdaMetafactory
> java.lang.invoke.LambdaProxyClassArchive
158a206,208
> java.lang.invoke.MethodHandleImpl$1
> java.lang.invoke.MethodHandleImpl$Intrinsic
> java.lang.invoke.MethodHandleInfo
163a214,215
> java.lang.invoke.MethodType$1
> java.lang.invoke.MethodTypeForm
169a222,223
> java.lang.invoke.VarHandle$AccessMode
> java.lang.invoke.VarHandle$AccessType
199a254
> java.lang.reflect.Array
270a326
> java.util.ArrayDeque$$Lambda/0x800000001
273d328
< java.util.ArrayList$Itr
359a415
> java.util.function.Consumer
393a450
> jdk.internal.access.JavaLangInvokeAccess
402a460,484
> jdk.internal.classfile.impl.AbstractAttributeMapper
> jdk.internal.classfile.impl.AbstractAttributeMapper$RuntimeVisibleAnnotationsMapper
> jdk.internal.classfile.impl.AbstractElement
> jdk.internal.classfile.impl.AbstractPoolEntry
> jdk.internal.classfile.impl.AbstractPoolEntry$AbstractNamedEntry
> jdk.internal.classfile.impl.AbstractPoolEntry$AbstractRefEntry
> jdk.internal.classfile.impl.AbstractPoolEntry$ClassEntryImpl
> jdk.internal.classfile.impl.AbstractPoolEntry$Utf8EntryImpl
> jdk.internal.classfile.impl.AbstractPoolEntry$Utf8EntryImpl$State
> jdk.internal.classfile.impl.AnnotationImpl
> jdk.internal.classfile.impl.BootstrapMethodEntryImpl
> jdk.internal.classfile.impl.EntryMap
> jdk.internal.classfile.impl.SplitConstantPool
> jdk.internal.classfile.impl.TemporaryConstantPool
> jdk.internal.classfile.impl.UnboundAttribute
> jdk.internal.classfile.impl.UnboundAttribute$UnboundRuntimeVisibleAnnotationsAttribute
> jdk.internal.classfile.impl.Util
> jdk.internal.classfile.impl.Util$Writable
> jdk.internal.constant.ArrayClassDescImpl
> jdk.internal.constant.ClassOrInterfaceDescImpl
> jdk.internal.constant.ConstantUtils
> jdk.internal.constant.DirectMethodHandleDescImpl
> jdk.internal.constant.DirectMethodHandleDescImpl$1
> jdk.internal.constant.MethodTypeDescImpl
> jdk.internal.constant.PrimitiveClassDescImpl
512a595
> jdk.internal.util.WeakReferenceKey
524a608
> sun.invoke.util.ValueConversions
525a610,612
> sun.invoke.util.VerifyType
> sun.invoke.util.Wrapper
> sun.invoke.util.Wrapper$Format

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260223/5361c505/attachment-0001.htm>

From alanb at openjdk.org  Mon Feb 23 16:04:52 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Feb 2026 16:04:52 GMT
Subject: RFR: 8378118: Test tools/jimage/JImageBadFileTest.java failed on
 Windows
In-Reply-To: <osTab7bHlL02EfiBJGHxrsjqzGcRVxrS8jbWWVz_eFg=.ed9d1730-0cd6-425c-9ccf-ebd7e1e96a79@github.com>
References: <osTab7bHlL02EfiBJGHxrsjqzGcRVxrS8jbWWVz_eFg=.ed9d1730-0cd6-425c-9ccf-ebd7e1e96a79@github.com>
Message-ID: <Lt3_4_Uge6VQ_uWQByh331hnNCywDRU3a8ontlKbdxw=.7b2a863b-39f9-42ec-b9e0-5e53e3ff0346@github.com>

On Wed, 18 Feb 2026 10:42:01 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removed the manual file tidyup on the expectation that jtreg will sort that all out.
> Switched to using Utils.createTempFile() while I was there.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29783#pullrequestreview-3841971250

From liach at openjdk.org  Mon Feb 23 16:22:50 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 23 Feb 2026 16:22:50 GMT
Subject: RFR: 8376234: Migrate java/lang/constant tests away from TestNG
 [v2]
In-Reply-To: <OdyavIz4EF19kdDjM05Un-d0XGg3SNisPGcF_WHvAb4=.b26f0248-eb76-47df-9505-9690c8206b2d@github.com>
References: <OdyavIz4EF19kdDjM05Un-d0XGg3SNisPGcF_WHvAb4=.b26f0248-eb76-47df-9505-9690c8206b2d@github.com>
Message-ID: <MobsfNg55aFe_062RkMD64eBU1IWAHZDX9kWIYqqWBc=.9c9e3409-5c1a-4029-9b80-dcc1f5aabb26@github.com>

> Convert all TestNG tests in java/lang/constant to JUnit tests.

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:

 - Reviews
 - Merge branch 'master' of https://github.com/openjdk/jdk into test/constant-no-testng
 - Bugs in migration
 - No testng in constant

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29396/files
  - new: https://git.openjdk.org/jdk/pull/29396/files/0fd824da..aa4d0df5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29396&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29396&range=00-01

  Stats: 562922 lines in 1947 files changed: 283390 ins; 260516 del; 19016 mod
  Patch: https://git.openjdk.org/jdk/pull/29396.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29396/head:pull/29396

PR: https://git.openjdk.org/jdk/pull/29396

From liach at openjdk.org  Mon Feb 23 16:22:53 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 23 Feb 2026 16:22:53 GMT
Subject: RFR: 8376234: Migrate java/lang/constant tests away from TestNG
 [v2]
In-Reply-To: <08BNNvYjMiNpHw9c4rEfI-iiLE7JUWUyQCnBs1aq3U0=.51aa6873-59e9-4793-a2ba-22a050b2dcaa@github.com>
References: <OdyavIz4EF19kdDjM05Un-d0XGg3SNisPGcF_WHvAb4=.b26f0248-eb76-47df-9505-9690c8206b2d@github.com>
 <08BNNvYjMiNpHw9c4rEfI-iiLE7JUWUyQCnBs1aq3U0=.51aa6873-59e9-4793-a2ba-22a050b2dcaa@github.com>
Message-ID: <CGDNqwWAonacs7yVIDLQAaBJyKbvHlBCWV4MRgNBPmc=.1d29cfc4-1704-4a7b-915d-7b0af1db93d2@github.com>

On Thu, 12 Feb 2026 13:57:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> 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:
>> 
>>  - Reviews
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into test/constant-no-testng
>>  - Bugs in migration
>>  - No testng in constant
>
> test/jdk/java/lang/constant/MethodHandleDescTest.java line 113:
> 
>> 111:         testMethodHandleDesc(r);
>> 112: 
>> 113:         assertMHEquals(mh, r.resolveConstantDesc(LOOKUP));
> 
> Swapping the arguments isn't necessary since assertMHEquals is reflexive.
> The method arguments don't follow the junit expected/actual ordering.

I checked again, after the migration, the assertMHEquals behaves effectively as (expected, actual). I have updated the arguments of that code to indicate this intention.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29396#discussion_r2841759945

From alexey.semenyuk at oracle.com  Mon Feb 23 16:38:14 2026
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Mon, 23 Feb 2026 11:38:14 -0500
Subject: macOS: pkg signing full chain workflow
In-Reply-To: <MRWPR01MB12445A5B7ADC4B1CFA89C1DEEDE77A@MRWPR01MB12445.eurprd01.prod.exchangelabs.com>
References: <MRWPR01MB12445D43463D74871856B9F23DE62A@MRWPR01MB12445.eurprd01.prod.exchangelabs.com>
 <MRWPR01MB12445A5B7ADC4B1CFA89C1DEEDE77A@MRWPR01MB12445.eurprd01.prod.exchangelabs.com>
Message-ID: <e8f3851e-dffe-4ab5-8aa6-262f09f5950c@oracle.com>

Hi Florent,

jpackage doesn't build the application jar. Likewise, it doesn't 
notarize and staple the package. These limitations leave steps 1, 2, 10, 
and 11 out of scope. The remaining steps are handled by jpackage, and 
each can be customized.
There are three CLI options to control signing certificates: 
--mac-signing-key-user-name, --mac-app-image-sign-identity, and 
--mac-installer-sign-identity.
--mac-signing-key-user-name option allows specifying a portion of the 
names of certificates for signing the application bundle and .pkg 
installer. jpackage will use the value of this option to lookup for 
certificates.
E.g., say you have "Developer ID Application: Acme Software LLC 
(ABCD1234)" and "Developer ID Installer: Acme Software LLC (ABCD1234)" 
certificates. You can instruct jpackage to use them in steps 3-9 by 
adding "--mac-signing-key-user-name 'Acme Software LLC (ABCD1234)'" to 
the command line.
If you want to explicitly specify certificates, you may use 
--mac-app-image-sign-identity and --mac-installer-sign-identity options.
The value of the --mac-app-image-sign-identity option should be the full 
name of the certificate for signing application bundle.
The value of the --mac-installer-sign-identity option should be the full 
name of the certificate for signing .pkg installer.

Additionally, you can specify the name of the keychain with the 
certificates with the --mac-signing-keychain option and the entitlements 
file with --mac-entitlements option.

All these options are valid only when used with "--mac-sign" option.

- Alexey

On 2/23/2026 5:53 AM, Florent MARTIN wrote:
>
> Hello,
>
> For an application, I need to create a pkg for macOS of a Java 
> application, but jpackage does not provide support for all the steps 
> required. As a reminder, here is the full workflow needed to create a 
> valid pkg that passes Gatekeeper on macOS, which requires three 
> different certificates:
>
>   * A standard signing certificate
>   * An Apple Developer ID Application certificate
>   * An Apple Developer ID Installer certificate
>
> The full workflow is:
>
>  1. Signing the native libraries inside the JAR (requires a Developer
>     ID Application certificate)
>       * Basically, this involves extracting the JAR, signing all
>         .jnilib and .dylib files, and rebuilding the JAR.
>  2. Signing the JAR itself (requires a standard certificate)
>       * Using jarsigner to pass the JVM security check.
>  3. Generating an application image (.app)
>  4. Signing the native libraries included in the image (requires a
>     Developer ID Application certificate)
>  5. Signing the main executable of the image (requires a Developer ID
>     Application certificate)
>  6. Signing the main bundle of the image (requires a Developer ID
>     Application certificate)
>  7. (Optional) Adding an entitlements.plist file to allow JNI usage
>       * Needed if using restricted features such as JNI.
>  8. Creating the installer package (.pkg)
>  9. Signing the installer package (requires a Developer ID Installer
>     certificate)
> 10. Notarizing the package (submission to Apple for verification)
> 11. Stapling the package (embedding the notarization directly into the
>     package)
>
> If we skip steps 1 and 2 for preparing the JAR (it would be better if 
> jpackage could handle this automatically), as well as steps 10 and 11, 
> then for steps 3 to 9 we need to use two different certificates, but 
> jpackage provides only a single `--mac-sign` parameter, which does not 
> support multiple certificates and would ideally be split into separate 
> parameters for the application certificate and the installer 
> certificate; as a result, when creating a pkg with jpackage, the App 
> Image inside remains unsigned, which causes Gatekeeper to block the 
> application.
>
> Best regards,
>
> *Florent MARTIN*
>
> D?veloppeur
>
> Cegid Relations Bancaires
>
> +33 (0)2 99 55 33 22
>
> flmartin at cegid.com <mailto:flmartin at cegid.com>
>
> 	
>
> 	
>
> Facebook <https://www.facebook.com/CegidGroup/>Twitter 
> <https://twitter.com/CegidGroup>LinkedIn 
> <https://fr.linkedin.com/company/cegid>
> *cegid.com* <https://www.cegid.com/>**
>
> 	
>
> Cegid <http://www.cegid.com/>
>
>
>
> Cegid est susceptible d?effectuer un traitement sur vos donn?es 
> personnelles ? des fins de gestion de notre relation commerciale. Pour 
> plus d?information, consultez https://www.cegid.com/fr/privacy-policy
> Ce message et les pi?ces jointes sont confidentiels et ?tablis ? 
> l'attention exclusive de ses destinataires. Toute utilisation ou 
> diffusion, m?me partielle, non autoris?e est interdite. Tout message 
> ?lectronique est susceptible d'alt?ration; Cegid d?cline donc toute 
> responsabilit? au titre de ce message. Si vous n'?tes pas le 
> destinataire de ce message, merci de le d?truire et d'avertir 
> l'exp?diteur.
>
> Cegid may process your personal data for the purpose of our business 
> relationship management. For more information, please visit our 
> website https://www.cegid.com/en/privacy-policy
> This message and any attachments are confidential and intended solely 
> for the addressees. Any unauthorized use or disclosure, either whole 
> or partial is prohibited. E-mails are susceptible to alteration; Cegid 
> shall therefore not be liable for the content of this message. If you 
> are not the intended recipient of this message, please delete it and 
> notify the sender. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260223/a0bbfb8e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1048 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260223/a0bbfb8e/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1264 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260223/a0bbfb8e/image002-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 1388 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260223/a0bbfb8e/image003-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 8492 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260223/a0bbfb8e/image004-0001.png>

From rriggs at openjdk.org  Mon Feb 23 16:44:02 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 23 Feb 2026 16:44:02 GMT
Subject: RFR: 8376234: Migrate java/lang/constant tests away from TestNG
 [v2]
In-Reply-To: <MobsfNg55aFe_062RkMD64eBU1IWAHZDX9kWIYqqWBc=.9c9e3409-5c1a-4029-9b80-dcc1f5aabb26@github.com>
References: <OdyavIz4EF19kdDjM05Un-d0XGg3SNisPGcF_WHvAb4=.b26f0248-eb76-47df-9505-9690c8206b2d@github.com>
 <MobsfNg55aFe_062RkMD64eBU1IWAHZDX9kWIYqqWBc=.9c9e3409-5c1a-4029-9b80-dcc1f5aabb26@github.com>
Message-ID: <NpdXWS0q6WJK8KiDMAm9ircyu2_IVT5TZ-W59dxypEE=.64da0baf-3c0f-4246-a632-8131810850f1@github.com>

On Mon, 23 Feb 2026 16:22:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Convert all TestNG tests in java/lang/constant to JUnit tests.
>
> 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:
> 
>  - Reviews
>  - Merge branch 'master' of https://github.com/openjdk/jdk into test/constant-no-testng
>  - Bugs in migration
>  - No testng in constant

Thanks for the updates.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29396#pullrequestreview-3842197965

From ogillespie at openjdk.org  Mon Feb 23 16:45:19 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Mon, 23 Feb 2026 16:45:19 GMT
Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v4]
In-Reply-To: <MqcByRYB6_RUiifVEaq1G6YlQSQc-NJWtYcc3euXdrY=.a991553d-4631-4cdc-a177-61f346de9e28@github.com>
References: <M5Kk3KWYQZ5UagIv_f-nNwN8gNby1VZP3TlFsXUkBwY=.bfb41c1f-091f-4df4-b68f-6155607db159@github.com>
 <kVAdSfhQqpvUoirf-FPTCyONo-YnIOnBdqRneppV1-8=.cc90825b-41ca-4443-bf1c-aa056b42ffc5@github.com>
 <zdlkfKNlVhjSwlM69QB8T33nQropqQY_SowxQQ0afG4=.5e09fe10-17eb-40f4-bc49-2204f94b42de@github.com>
 <I7tsrhzAwGOb5Ri_kmrnjtimgGv2GtX85MnKu9YhIJk=.76d53686-bf1c-4c45-90d6-66a49e3d45b8@github.com>
 <EdriGMb-EC4hEuUqJvyCGuvXq9GOgwelp5t0B9X9un8=.f207febf-7613-4576-901b-a90e99fd112a@github.com>
 <DHMy4lgZXGGUXs_g5dgzkldBx7VEKnzOkCsXs_6loPw=.da834dd8-7b93-42e5-a084-583f09e61680@github.com>
 <pzruiRy5OL0aqki3JEKxVAeQVybZRBvg8ksd8N2r8KI=.cb791880-795b-46d5-8b79-bda211f6bd91@github.com>
 <MqcByRYB6_RUiifVEaq1G6YlQSQc-NJWtYcc3euXdrY=.a991553d-4631-4cdc-a177-61f346de9e28@github.com>
Message-ID: <72lBM_XDXOjREMu_aw7hNXCEFKmFADi1JpuSj58obYY=.e2aff6a4-6be5-4e63-b460-371eb5e873fa@github.com>

On Mon, 23 Feb 2026 15:32:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Yes, seems you cannot create a spliterator with a lazy iterator. This is fine.
>
> Alternatively we can override `stream()` to call the `StreamSupport.stream` that takes a `Supplier<? extends Spliterator<T>>` instead.

Good point, in fact I think that's more correct. From stream():

> This method should be overridden when the spliterator() method cannot return a spliterator that is IMMUTABLE, CONCURRENT, or late-binding. (See spliterator() for details.)

I suppose ours is no longer late-binding.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28608#discussion_r2841881785

From duke at openjdk.org  Mon Feb 23 16:46:46 2026
From: duke at openjdk.org (duke)
Date: Mon, 23 Feb 2026 16:46:46 GMT
Subject: RFR: 8378118: Test tools/jimage/JImageBadFileTest.java failed on
 Windows
In-Reply-To: <osTab7bHlL02EfiBJGHxrsjqzGcRVxrS8jbWWVz_eFg=.ed9d1730-0cd6-425c-9ccf-ebd7e1e96a79@github.com>
References: <osTab7bHlL02EfiBJGHxrsjqzGcRVxrS8jbWWVz_eFg=.ed9d1730-0cd6-425c-9ccf-ebd7e1e96a79@github.com>
Message-ID: <hr8U5MOUw14Yy6k2Fm147H8e4BbWLWvpYTDndJNKmB8=.d1965c0e-7097-4bad-b074-9a177a876ae7@github.com>

On Wed, 18 Feb 2026 10:42:01 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removed the manual file tidyup on the expectation that jtreg will sort that all out.
> Switched to using Utils.createTempFile() while I was there.

@david-beaumont 
Your change (at version be66cf1d81b63bd427ba7eb23126d1b87eb530f0) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29783#issuecomment-3945925131

From rriggs at openjdk.org  Mon Feb 23 16:46:50 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 23 Feb 2026 16:46:50 GMT
Subject: RFR: 8378118: Test tools/jimage/JImageBadFileTest.java failed on
 Windows
In-Reply-To: <JmFRxrp87hpEQ43e7vqTbksprvFLTRbd0PcncYIifUs=.2d50f115-9b81-4c9f-bade-2d29eb231ae5@github.com>
References: <osTab7bHlL02EfiBJGHxrsjqzGcRVxrS8jbWWVz_eFg=.ed9d1730-0cd6-425c-9ccf-ebd7e1e96a79@github.com>
 <Oz0MYlG6I9qUbvKGncoQ0r6VMiN5B7bf_-dAdrBx2as=.25135ea0-dda5-4676-8fe2-b77da5f20d23@github.com>
 <JmFRxrp87hpEQ43e7vqTbksprvFLTRbd0PcncYIifUs=.2d50f115-9b81-4c9f-bade-2d29eb231ae5@github.com>
Message-ID: <i74hN2ijZh6evZdwtuWM-i1PsJMUa9oQyuBcYxoGeRc=.665099aa-413b-4000-8fa7-7cea00a5fcd6@github.com>

On Mon, 23 Feb 2026 15:25:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/tools/jimage/JImageBadFileTest.java line 145:
>> 
>>> 143:         // Self test that the file copying isn't itself corrupting anything.
>>> 144:         Path tempJimage = writeModifiedJimage("good_file", -1, b -> {});
>>> 145:         jimage("info", tempJimage.toString()).assertSuccess();
>> 
>> I know its a bit late to complain now, but "jimage" is not a very nor a very descriptive name of a central utility method.
>
> It's a method on JImageCliTest, the super class of the tests for the jimage tool.

Yep, I tracked it down, its still not a good name.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29783#discussion_r2841877698

From duke at openjdk.org  Mon Feb 23 16:46:53 2026
From: duke at openjdk.org (David Beaumont)
Date: Mon, 23 Feb 2026 16:46:53 GMT
Subject: RFR: 8378118: Test tools/jimage/JImageBadFileTest.java failed on
 Windows
In-Reply-To: <i74hN2ijZh6evZdwtuWM-i1PsJMUa9oQyuBcYxoGeRc=.665099aa-413b-4000-8fa7-7cea00a5fcd6@github.com>
References: <osTab7bHlL02EfiBJGHxrsjqzGcRVxrS8jbWWVz_eFg=.ed9d1730-0cd6-425c-9ccf-ebd7e1e96a79@github.com>
 <Oz0MYlG6I9qUbvKGncoQ0r6VMiN5B7bf_-dAdrBx2as=.25135ea0-dda5-4676-8fe2-b77da5f20d23@github.com>
 <JmFRxrp87hpEQ43e7vqTbksprvFLTRbd0PcncYIifUs=.2d50f115-9b81-4c9f-bade-2d29eb231ae5@github.com>
 <i74hN2ijZh6evZdwtuWM-i1PsJMUa9oQyuBcYxoGeRc=.665099aa-413b-4000-8fa7-7cea00a5fcd6@github.com>
Message-ID: <HVKhVQSBJDUKnJ2PTMqEY_qu30KFOVj1LkXKn9TiqNU=.12f23be0-9a19-4160-bf18-8166883f9b31@github.com>

On Mon, 23 Feb 2026 16:41:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> It's a method on JImageCliTest, the super class of the tests for the jimage tool.
>
> Yep, I tracked it down, its still not a good name.

I'm happy to refactor it in a followup PR if you want? Just say the word.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29783#discussion_r2841884715

From darcy at openjdk.org  Mon Feb 23 16:58:43 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 23 Feb 2026 16:58:43 GMT
Subject: RFR: 8378414: Add methods to test for representation equivalence
In-Reply-To: <0c0gdxzdx89GRTz0mEbpIndhAocsMwbpUGhvCNb8IYQ=.46355665-6ab6-455d-83e3-5947b34a6fb6@github.com>
References: <mioOgE5dVvyj1CgG7BNDyixbbwIOyRFqKs9s7-vgqCE=.825997f5-c363-4a94-a45b-499dfa255420@github.com>
 <zYuApVBaFbPz_VrCHEIctFlnpyoA8CO8XGbxncUMGrw=.c3a6b218-19e9-4e86-bc2f-a6af7d0a16a0@github.com>
 <0c0gdxzdx89GRTz0mEbpIndhAocsMwbpUGhvCNb8IYQ=.46355665-6ab6-455d-83e3-5947b34a6fb6@github.com>
Message-ID: <QhWlCa9_6lui-xc6X9H4XwyMJCRwUNOxi9U8d-Ftq8A=.462f25e8-0eb4-43f7-9a52-9cfb44490e65@github.com>

On Mon, 23 Feb 2026 02:45:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This equivalence is already covered by their `equals(Object)` methods. I would assume they are declared as `equals(double, double)` etc. similar to how instance `Double::isInfinite()` and static `Double::isInfinite(double)` are declared.
>
>> This equivalence is already covered by their `equals(Object)` methods. I would assume they are declared as `equals(double, double)` etc. similar to how instance `Double::isInfinite()` and static `Double::isInfinite(double)` are declared.
> 
> It is true that there are already multiple expressions using existing methods can be written to implement that functionality. However, conceptually, I don't think boxing up to Double should be necessary (or desirable).

> @jddarcy The `java/lang/Math` tests fail (but disregard my previous message).

All the Math and StrictMath test pass for me locally.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29870#issuecomment-3945999661

From ogillespie at openjdk.org  Mon Feb 23 17:05:27 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Mon, 23 Feb 2026 17:05:27 GMT
Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v5]
In-Reply-To: <M5Kk3KWYQZ5UagIv_f-nNwN8gNby1VZP3TlFsXUkBwY=.bfb41c1f-091f-4df4-b68f-6155607db159@github.com>
References: <M5Kk3KWYQZ5UagIv_f-nNwN8gNby1VZP3TlFsXUkBwY=.bfb41c1f-091f-4df4-b68f-6155607db159@github.com>
Message-ID: <0gXvclAjJnz5LPRXjhklSd6elcyuSRhoVxTwI6PKChE=.0385da57-1d46-450b-a817-7832e7ee19b6@github.com>

> `TreeMap` sub-maps use the default `IteratorSpliterator` implementation for `TreeMap$EntrySetView` which is slow for some operations, because `EntrySetView.size()` iterates all elements. This is most trivially shown by something like `largeTreeMap.tailMap(0L, false).entrySet().limit(1).count()` taking a long time. This showed up in my application, where it was trivial to mitigate by switching to a for loop, but I think the fix is easy enough.
> 
> `keySet()` does not have the same problem, as it provides a custom `Spliterator` implementation which is not `Spliterator.SIZED`, and returns `Long.MAX_VALUE` for `estimateSize()` (which is the recommended approach when the size is expensive to compute). I'm *assuming* this optimization was simply missed for the EntryIterator in the original implementation, but I don't know for sure.
> 
> This patch fixes the issue by using `Spliterators.spliteratorUnknownSize` for `EntrySetView`, marking the size as unknown avoids accidentally iterating the whole thing for simple operations.
> 
> 
> Basic performance test: `map.tailMap(0L, false).entrySet().stream().limit(1).count()` for a `TreeMap` with `10_000_000` entries.
> 
> Before (keySet is fast using `SubMapKeyIterator`, entrySet is slow):
> 
> class java.util.TreeMap$KeySet
>     .stream().limit(1).count() took 0.046ms
>     spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807
> class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView
>     .stream().limit(1).count() took 218ms
>     spliterator = IteratorSpliterator, estimateSize() = 9999999 
> 
> 
> After (entrySet is now fast):
> 
> class java.util.TreeMap$KeySet
> 	.stream().limit(1).count() took 0.017ms
> 	spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807
> class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView
> 	.stream().limit(1).count() took 0.115419ms
> 	spliterator = IteratorSpliterator, estimateSize() = 9223372036854775807
> 
> 
> Behaviour is tested by the test cases added in https://bugs.openjdk.org/browse/JDK-8376698.
> 
> The Set default stream() implementation uses spliterator(), and since our spliterator() implementation is no longer late-binding (it eagerly creates the iterator), we override stream() to use a late-binding wrapper.

Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:

  Make stream() late-binding

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28608/files
  - new: https://git.openjdk.org/jdk/pull/28608/files/144216ba..4ebc2526

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28608&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28608&range=03-04

  Stats: 8 lines in 2 files changed: 7 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28608.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28608/head:pull/28608

PR: https://git.openjdk.org/jdk/pull/28608

From rgiulietti at openjdk.org  Mon Feb 23 17:08:53 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 23 Feb 2026 17:08:53 GMT
Subject: RFR: 8378414: Add methods to test for representation equivalence
In-Reply-To: <mioOgE5dVvyj1CgG7BNDyixbbwIOyRFqKs9s7-vgqCE=.825997f5-c363-4a94-a45b-499dfa255420@github.com>
References: <mioOgE5dVvyj1CgG7BNDyixbbwIOyRFqKs9s7-vgqCE=.825997f5-c363-4a94-a45b-499dfa255420@github.com>
Message-ID: <5oj8CCq28RlBznzqSC0syfYejr2bBZhdFi4K9IBhLjU=.6489e629-5764-4fd6-8ef0-94b9c0c1d29a@github.com>

On Mon, 23 Feb 2026 00:48:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Floating-point values have a notion of representation equivalence distinct from the comparison done by ==. This notion of equivalence could have a method to provide the predicate directly, rather than relying on one of several expressions listed in the documentation ([JDK-8295391](https://bugs.openjdk.org/browse/JDK-8295391)).

test/jdk/java/lang/Math/Tests.java line 424:

> 422:                            float input1, int input2,
> 423:                            float result, float expected) {
> 424:         if (Float.equivalent(expected, result)) {

I think this is the cause of the tests failures I'm observing.
Suggestion:

        if (!Float.equivalent(expected, result)) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29870#discussion_r2842006526

From rgiulietti at openjdk.org  Mon Feb 23 17:12:09 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 23 Feb 2026 17:12:09 GMT
Subject: RFR: 8378414: Add methods to test for representation equivalence
In-Reply-To: <5oj8CCq28RlBznzqSC0syfYejr2bBZhdFi4K9IBhLjU=.6489e629-5764-4fd6-8ef0-94b9c0c1d29a@github.com>
References: <mioOgE5dVvyj1CgG7BNDyixbbwIOyRFqKs9s7-vgqCE=.825997f5-c363-4a94-a45b-499dfa255420@github.com>
 <5oj8CCq28RlBznzqSC0syfYejr2bBZhdFi4K9IBhLjU=.6489e629-5764-4fd6-8ef0-94b9c0c1d29a@github.com>
Message-ID: <cEL78pwjt4OgeluXgyaGPN3XiUUgZkFSEh1UL72GWhA=.d0e66649-c99d-4eef-860f-3a4cc7b6552f@github.com>

On Mon, 23 Feb 2026 17:05:29 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Floating-point values have a notion of representation equivalence distinct from the comparison done by ==. This notion of equivalence could have a method to provide the predicate directly, rather than relying on one of several expressions listed in the documentation ([JDK-8295391](https://bugs.openjdk.org/browse/JDK-8295391)).
>
> test/jdk/java/lang/Math/Tests.java line 424:
> 
>> 422:                            float input1, int input2,
>> 423:                            float result, float expected) {
>> 424:         if (Float.equivalent(expected, result)) {
> 
> I think this is the cause of the tests failures I'm observing.
> Suggestion:
> 
>         if (!Float.equivalent(expected, result)) {

Definitely this mistake.
After correcting, the tests succeed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29870#discussion_r2842026853

From darcy at openjdk.org  Mon Feb 23 17:26:48 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 23 Feb 2026 17:26:48 GMT
Subject: RFR: 8378414: Add methods to test for representation equivalence
In-Reply-To: <cEL78pwjt4OgeluXgyaGPN3XiUUgZkFSEh1UL72GWhA=.d0e66649-c99d-4eef-860f-3a4cc7b6552f@github.com>
References: <mioOgE5dVvyj1CgG7BNDyixbbwIOyRFqKs9s7-vgqCE=.825997f5-c363-4a94-a45b-499dfa255420@github.com>
 <5oj8CCq28RlBznzqSC0syfYejr2bBZhdFi4K9IBhLjU=.6489e629-5764-4fd6-8ef0-94b9c0c1d29a@github.com>
 <cEL78pwjt4OgeluXgyaGPN3XiUUgZkFSEh1UL72GWhA=.d0e66649-c99d-4eef-860f-3a4cc7b6552f@github.com>
Message-ID: <YIVTK6lcefiD39Cideh_p1sceWviFrijET2dgjBIUT8=.05314c70-2000-4da4-9da4-90ee64db6b0b@github.com>

On Mon, 23 Feb 2026 17:09:31 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Definitely this mistake. After correcting, the tests succeed.

I think I see what is going on. After clearing the JTwork and JTreport directories, I was able to reproduce the failure. At least one of the tests looks to be missing a `@build` statement to check for dependencies.

Thanks for the thorough review; I'll correct the mistake in Tests and look over the build tags.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29870#discussion_r2842104385

From asemenyuk at openjdk.org  Mon Feb 23 17:38:27 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 23 Feb 2026 17:38:27 GMT
Subject: Integrated: 8377897: jpackage: make jdk.jpackage.internal.MockUtils
 available from other packages
In-Reply-To: <OkOhOuHJ59h2vCWGp4zbAGicavnLAQqxBw9JFec2dPM=.4509f1cf-b127-4da5-ab7f-5ff80d41d72e@github.com>
References: <OkOhOuHJ59h2vCWGp4zbAGicavnLAQqxBw9JFec2dPM=.4509f1cf-b127-4da5-ab7f-5ff80d41d72e@github.com>
Message-ID: <wfEo1DWK-mtxWBPyJhgpZo9ECkoiGfGJiT8uhZJ4X6Q=.0c9ef4d7-a42c-4be3-b01e-68a6efae7723@github.com>

On Mon, 2 Feb 2026 22:18:49 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Move jdk.jpackage.internal.MockUtils to jdk.jpackage.test.stdmock.JPackageMockUtils
>  - Make ObjectFactory, ExecutorFactory, RetryExecutorFactory, and Executor accessible for creating jpackage mocks in tests outside the jdk.jpackage.internal package

This pull request has now been integrated.

Changeset: acde30e0
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/acde30e0ab9cd8fbb6d2e1193771a40fd370659a
Stats:     786 lines in 20 files changed: 467 ins; 266 del; 53 mod

8377897: jpackage: make jdk.jpackage.internal.MockUtils available from other packages

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/29536

From rriggs at openjdk.org  Mon Feb 23 17:40:12 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 23 Feb 2026 17:40:12 GMT
Subject: RFR: 8378118: Test tools/jimage/JImageBadFileTest.java failed on
 Windows
In-Reply-To: <HVKhVQSBJDUKnJ2PTMqEY_qu30KFOVj1LkXKn9TiqNU=.12f23be0-9a19-4160-bf18-8166883f9b31@github.com>
References: <osTab7bHlL02EfiBJGHxrsjqzGcRVxrS8jbWWVz_eFg=.ed9d1730-0cd6-425c-9ccf-ebd7e1e96a79@github.com>
 <Oz0MYlG6I9qUbvKGncoQ0r6VMiN5B7bf_-dAdrBx2as=.25135ea0-dda5-4676-8fe2-b77da5f20d23@github.com>
 <JmFRxrp87hpEQ43e7vqTbksprvFLTRbd0PcncYIifUs=.2d50f115-9b81-4c9f-bade-2d29eb231ae5@github.com>
 <i74hN2ijZh6evZdwtuWM-i1PsJMUa9oQyuBcYxoGeRc=.665099aa-413b-4000-8fa7-7cea00a5fcd6@github.com>
 <HVKhVQSBJDUKnJ2PTMqEY_qu30KFOVj1LkXKn9TiqNU=.12f23be0-9a19-4160-bf18-8166883f9b31@github.com>
Message-ID: <BBj3pJbqSa2RIL60hVUYMRi25dhjFo9sYffp94z68KA=.a9135295-3c38-4d99-90b1-35e76b781d7a@github.com>

On Mon, 23 Feb 2026 16:43:21 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Yep, I tracked it down, its still not a good name.
>
> I'm happy to refactor it in a followup PR if you want? Just say the word.

Leave it for now, its been stable since 2016.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29783#discussion_r2842187445

From asemenyuk at openjdk.org  Mon Feb 23 17:43:39 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 23 Feb 2026 17:43:39 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v14]
In-Reply-To: <nZz-9QE2qMkqmhVA1WNHjiAM7bQdwiAHb0gKchsYtQU=.7fcce853-137f-4a2b-9840-f38dae2e5b63@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <nZz-9QE2qMkqmhVA1WNHjiAM7bQdwiAHb0gKchsYtQU=.7fcce853-137f-4a2b-9840-f38dae2e5b63@github.com>
Message-ID: <-0YZL7vNyJnNTFYbwDmWMpbq3EqHsc8cEup-6iA6B3A=.87d95817-70d6-4a45-922f-357a9f3b2554@github.com>

On Thu, 19 Feb 2026 23:25:41 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
>> - Added test to cover added functionality.
>> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.
>
> Alexander Matveev 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 remote-tracking branch 'upstream/master' into JDK-8357404
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v11]
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v10]
>  - Merge remote-tracking branch 'upstream/master' into JDK-8357404
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v9]
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v8]
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v7]
>  - Merge remote-tracking branch 'upstream/master' into JDK-8357404
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]
>  - merge with upstream
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/ff1c42f1...1bca2865

test/jdk/tools/jpackage/share/RuntimePackageTest.java line 136:

> 134:     @Parameter(value = {"17.21.3+foo", "1.0"})
> 135:     // 27
> 136:     @Parameter(value = {"27"})

Shouldn't it convert "27" into "27.0" on Windows?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2842191442

From darcy at openjdk.org  Mon Feb 23 17:56:26 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 23 Feb 2026 17:56:26 GMT
Subject: RFR: 8378414: Add methods to test for representation equivalence
 [v2]
In-Reply-To: <mioOgE5dVvyj1CgG7BNDyixbbwIOyRFqKs9s7-vgqCE=.825997f5-c363-4a94-a45b-499dfa255420@github.com>
References: <mioOgE5dVvyj1CgG7BNDyixbbwIOyRFqKs9s7-vgqCE=.825997f5-c363-4a94-a45b-499dfa255420@github.com>
Message-ID: <e3S7wSs81cJazsd86bVIUdKJWbvIUP-nE3SDpVNj6Yg=.bb916487-0c08-4ba1-988b-52e12088c6e0@github.com>

> Floating-point values have a notion of representation equivalence distinct from the comparison done by ==. This notion of equivalence could have a method to provide the predicate directly, rather than relying on one of several expressions listed in the documentation ([JDK-8295391](https://bugs.openjdk.org/browse/JDK-8295391)).

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback; add build tags.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29870/files
  - new: https://git.openjdk.org/jdk/pull/29870/files/8f630ca0..f843a832

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29870&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29870&range=00-01

  Stats: 8 lines in 4 files changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/29870.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29870/head:pull/29870

PR: https://git.openjdk.org/jdk/pull/29870

From dl at openjdk.org  Mon Feb 23 18:32:06 2026
From: dl at openjdk.org (Doug Lea)
Date: Mon, 23 Feb 2026 18:32:06 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v42]
In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
Message-ID: <sTgavGzjw62Bp7PmwAq0uOX8XmF3p1FToXkg4jk8PIQ=.65719426-0e41-49be-8c22-68d07275a6a2@github.com>

> Changes signal filtering to avoid possible starvation

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Reduce memory traffic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28797/files
  - new: https://git.openjdk.org/jdk/pull/28797/files/821ed264..518b3c8f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=40-41

  Stats: 29 lines in 1 file changed: 15 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/28797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28797/head:pull/28797

PR: https://git.openjdk.org/jdk/pull/28797

From jlu at openjdk.org  Mon Feb 23 22:56:31 2026
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Feb 2026 22:56:31 GMT
Subject: RFR: 8378111: Migrate java/util/jar tests to JUnit [v3]
In-Reply-To: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
References: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
Message-ID: <byA5m9O6m0xMz0JVHfA6coX5fePS0EbZNHTeSfnx7kE=.dfdbe356-474c-45f4-8d2c-ac2c2cce8cfc@github.com>

> This PR migrates the java/util/jar tests to use _JUnit_.
> 
> https://github.com/openjdk/jdk/commit/afe0aeee746bccbbe4bc6c9a8cd2302228ecc2f6 includes changes for _testNG_ based tests.
> https://github.com/openjdk/jdk/commit/c5a7f75840f96fa77ec3ed7faa713990adb84de6 includes changes for `main` based tests.
> 
> Before: Framework-based tests: 125 = 125 TestNG + 0 JUnit.
> After: Framework-based tests: 174 = 0 TestNG + 174 JUnit

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  get rid of inheritance + zip -> ZIP

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29828/files
  - new: https://git.openjdk.org/jdk/pull/29828/files/c55c722d..5bd6c18e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29828&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29828&range=01-02

  Stats: 181 lines in 2 files changed: 118 ins; 45 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/29828.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29828/head:pull/29828

PR: https://git.openjdk.org/jdk/pull/29828

From mikael at openjdk.org  Tue Feb 24 00:37:24 2026
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 24 Feb 2026 00:37:24 GMT
Subject: RFR: 8377905: gcc.md included with every build
In-Reply-To: <f1qzTvHdFh3IAW1BuGx8lr-rBqRee2QNE9eX0Au9wP8=.a225fa30-7718-4194-a7c2-0a17f78f63e3@github.com>
References: <f1qzTvHdFh3IAW1BuGx8lr-rBqRee2QNE9eX0Au9wP8=.a225fa30-7718-4194-a7c2-0a17f78f63e3@github.com>
Message-ID: <t8YGQS0qt_LwhfS27bq4eq-wX7poqwVu1BmnRChKwg8=.8ac2f7fa-8608-4259-bf48-88baeb2d1000@github.com>

On Fri, 20 Feb 2026 22:38:20 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> JDK-8377509 added the gcc.md license file. Unfortunately the file is unconditionally in the built JDK regardless of the toolchain used. This change updates the build logic to only include the file when relevant.
> 
> Testing: tier1, builds-tier[2-5], manual verification to ensure the file is only included where expected.

Thank you for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29853#issuecomment-3948168728

From mikael at openjdk.org  Tue Feb 24 00:37:25 2026
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 24 Feb 2026 00:37:25 GMT
Subject: Integrated: 8377905: gcc.md included with every build
In-Reply-To: <f1qzTvHdFh3IAW1BuGx8lr-rBqRee2QNE9eX0Au9wP8=.a225fa30-7718-4194-a7c2-0a17f78f63e3@github.com>
References: <f1qzTvHdFh3IAW1BuGx8lr-rBqRee2QNE9eX0Au9wP8=.a225fa30-7718-4194-a7c2-0a17f78f63e3@github.com>
Message-ID: <lyN4uDDwfYMPc-Bjk-Btxewjlhcf0p60DBVths4DCQI=.81a12879-6c74-46dd-8bd6-c5279429ba5b@github.com>

On Fri, 20 Feb 2026 22:38:20 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> JDK-8377509 added the gcc.md license file. Unfortunately the file is unconditionally in the built JDK regardless of the toolchain used. This change updates the build logic to only include the file when relevant.
> 
> Testing: tier1, builds-tier[2-5], manual verification to ensure the file is only included where expected.

This pull request has now been integrated.

Changeset: c0c1775a
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c0c1775a2b002e82347bb0a0b1167cfe45e7006e
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8377905: gcc.md included with every build

Reviewed-by: erikj, jsjolen, prr, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/29853

From psandoz at openjdk.org  Tue Feb 24 01:12:17 2026
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 24 Feb 2026 01:12:17 GMT
Subject: RFR: 8377438: [VectorAPI] Add new carrier type to LaneType class
 [v2]
In-Reply-To: <qmSybXnaUH8CxOjqOJwhdINd_GhiWX6OlG8ABL1GScE=.fe7f9703-d35a-475f-9e85-ed9063f3648d@github.com>
References: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
 <qmSybXnaUH8CxOjqOJwhdINd_GhiWX6OlG8ABL1GScE=.fe7f9703-d35a-475f-9e85-ed9063f3648d@github.com>
Message-ID: <3kWj8D_3GGIVKmW2_KSL7GqM5bY_GV3wCPGK5a3Qjcw=.7329365f-d14a-49b6-925d-b8b5da681d2d@github.com>

On Thu, 19 Feb 2026 12:02:27 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
>> 
>> With Float16 we need to differentiate b/w vector lane element type and carrier type. while element type corresponds to exact type of lane i.e. Float16.class, carrier type corresponds to the storage type required to propagate IEEE 754 float16 values to inline expander.
>> 
>> Patch adds a new carrier type to existing LaneType structure and use it for following purpose.
>>  - To compute preferred shape of vector.
>>  - To allocate vector backing storage during dummy vector and iota array creation.
>>  - Sanity checking to ensure vector lane type is a primitive type in inline expander.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8377438
>  - 8377438: [VectorAPI] Add new carrier type to LaneType class

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LaneType.java line 70:

> 68:         this.typeChar = genericElementType.getSimpleName().charAt(0);
> 69:         this.carrierType = carrierType;
> 70:         assert("FDBSIL".indexOf(typeChar) == ordinal()) : this;

Can you move this assert statement to be directly after where `typeChar` is assigned? Then after the assignment of `carrierType` you can `assert(carrierType.isPrimitive())`, which while not full-proof does express the intent.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29629#discussion_r2843895458

From ascarpino at openjdk.org  Tue Feb 24 02:15:33 2026
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 24 Feb 2026 02:15:33 GMT
Subject: RFR: 8368841: X25519 implementation differs from the specification
 in RFC 7748 [v3]
In-Reply-To: <WcR-ShFFnhzlo9uJ0w8MVM0p67ipMeMdTcOLF4WbzWw=.951c61e5-3b19-4c4e-8c91-77a5c450dc15@github.com>
References: <c_dJLNLDU_f3_R5l-IX8FccJW6lAy6-TdzFlM_oEIJ0=.da3b9092-e3e7-4e34-84dd-178c94833a71@github.com>
 <WcR-ShFFnhzlo9uJ0w8MVM0p67ipMeMdTcOLF4WbzWw=.951c61e5-3b19-4c4e-8c91-77a5c450dc15@github.com>
Message-ID: <2N1k3PlPpZGwMY3p6pSP8o1ZnH0VDOmIMGSFs59smPY=.00d8c421-57d0-40c3-b31e-8b69f976c5d0@github.com>

On Thu, 19 Feb 2026 20:03:25 GMT, Ben Perez <bperez at openjdk.org> wrote:

>> Our implementation of X25519 does not zero the MSB of the `u` coordinate as required by RFC 7748. Currently the test `jdk/sun/security/ec/xec/TestXDH.java` zeroes the bit manually while parsing test vectors, which is likely why this went uncaught.
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed parsing functionality in TestXDH that manually clears MSB

src/java.base/share/classes/sun/security/ec/XDHPublicKeyImpl.java line 59:

> 57: 
> 58:         // RFC 7748 Section 5 requires the MSB of `u` to be zeroed for X25519
> 59:         this.u = params.getName().equals("X448") ? u.mod(params.getP()) :

I think it would cleaner to compare `NamedParameterSpec` instead of the String.  `(paramSpec == NamedParameterSpec.X448) ?`.  For here an the other constructor.

test/jdk/sun/security/ec/xec/TestXDH.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2021, Oracle and/or its affiliates. All rights reserved.

Update the year

test/jdk/sun/security/ec/xec/TestXDH.java line 369:

> 367:         PrivateKey privateKey = kf.generatePrivate(privateSpec);
> 368:         KeySpec publicSpec = new XECPublicKeySpec(paramSpec,
> 369:             Convert.hexStringToBigInteger(b_pub));

Can this be replaced with `new BigInteger(b_pub, 16)`?  If so, the Convert.java change isn't needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29750#discussion_r2844074229
PR Review Comment: https://git.openjdk.org/jdk/pull/29750#discussion_r2844082050
PR Review Comment: https://git.openjdk.org/jdk/pull/29750#discussion_r2844074580

From jpai at openjdk.org  Tue Feb 24 02:26:42 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 24 Feb 2026 02:26:42 GMT
Subject: RFR: 8378378: Remove references to obsolete
 jdk.net.usePlainDatagramSocketImpl property from tests
In-Reply-To: <u5AsYpwj5lBAVG8m4_wTbIuop804rWs7dlUWgnICNUA=.56dc3b7f-a9e9-4c65-a187-55e754b578d3@github.com>
References: <u5AsYpwj5lBAVG8m4_wTbIuop804rWs7dlUWgnICNUA=.56dc3b7f-a9e9-4c65-a187-55e754b578d3@github.com>
Message-ID: <gIF2BPUh0Ab3uNEJNwgrmiPjAgwo-03CoxjJWJOcp1A=.9c13a53f-3217-46af-b137-ca7e7dbc499a@github.com>

On Mon, 23 Feb 2026 01:14:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which removes reference to the obsolete `jdk.net.usePlainDatagramSocketImpl` property?
> 
> This property and the related fallback support was removed in https://bugs.openjdk.org/browse/JDK-8253119. The property plays no role anymore. The tests continue to pass after this change.

Thank you all for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29871#issuecomment-3948503277

From jpai at openjdk.org  Tue Feb 24 02:26:43 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 24 Feb 2026 02:26:43 GMT
Subject: Integrated: 8378378: Remove references to obsolete
 jdk.net.usePlainDatagramSocketImpl property from tests
In-Reply-To: <u5AsYpwj5lBAVG8m4_wTbIuop804rWs7dlUWgnICNUA=.56dc3b7f-a9e9-4c65-a187-55e754b578d3@github.com>
References: <u5AsYpwj5lBAVG8m4_wTbIuop804rWs7dlUWgnICNUA=.56dc3b7f-a9e9-4c65-a187-55e754b578d3@github.com>
Message-ID: <j18-0Kublj6FLu3atXkbRKrSjU-Yr7hcM3eJNvNhO3w=.33592aca-e8eb-443b-a9b7-02467b14b937@github.com>

On Mon, 23 Feb 2026 01:14:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which removes reference to the obsolete `jdk.net.usePlainDatagramSocketImpl` property?
> 
> This property and the related fallback support was removed in https://bugs.openjdk.org/browse/JDK-8253119. The property plays no role anymore. The tests continue to pass after this change.

This pull request has now been integrated.

Changeset: 171d788b
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/171d788bce176ef147840fadd5551579ac7bb9b6
Stats:     79 lines in 3 files changed: 0 ins; 50 del; 29 mod

8378378: Remove references to obsolete jdk.net.usePlainDatagramSocketImpl property from tests

Reviewed-by: alanb, vyazici, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/29871

From ascarpino at openjdk.org  Tue Feb 24 03:17:42 2026
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 24 Feb 2026 03:17:42 GMT
Subject: RFR: 8377506: Implementation of PEM Encodings of Cryptographic
 Objects [v2]
In-Reply-To: <YzPtaVvEe6dWIN5V4Nz-gdsUqza5_limqiYlggATDTE=.f46bd178-c664-48d6-99f8-7b0ae28d9617@github.com>
References: <0rUn5iExvutq4o4xi7w54wXl-gY5Q5smYAZJIz40mFo=.f717d078-f46b-4d14-8383-ee24306d88bb@github.com>
 <YzPtaVvEe6dWIN5V4Nz-gdsUqza5_limqiYlggATDTE=.f46bd178-c664-48d6-99f8-7b0ae28d9617@github.com>
Message-ID: <6YdaS7U3RNhVIAONj5jJHLjH3Z6a4YCcF6Vs8Q9e6VQ=.de4ce8b9-63b6-4b7a-a46c-ce07f507c6fc@github.com>

On Fri, 20 Feb 2026 01:32:39 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Please review the finalized PEM API at https://openjdk.org/jeps/8360563. The most significant changes from the second preview, JEP 524 (https://openjdk.org/jeps/524), include:
>> 
>> - `PEM` is changed from a record to a class, with content stored in binary form and data defensively copied.
>> - `DEREncodable` is renamed to `BinaryEncodable` to more accurately reflect the binary data stored in PEM text.
>> - In `EncryptedPrivateKeyInfo`, the `encrypt` methods now accept `BinaryEncodable`, and the `getKey()` and `getKeyPair()` methods no longer include a `Provider` parameter.
>> - A new `CryptoException` indicates failures during cryptographic processing at runtime.
>> 
>> thanks
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

/remove-label compiler
/remove-label core-libs

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29640#issuecomment-3948659120

From jbhateja at openjdk.org  Tue Feb 24 05:06:12 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 24 Feb 2026 05:06:12 GMT
Subject: RFR: 8377438: [VectorAPI] Add new carrier type to LaneType class
 [v3]
In-Reply-To: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
References: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
Message-ID: <UNPXEPP2riZD-ACHcAi4ufkMSTlYAdflswGXxYl8RLc=.2662d8f4-e034-4da2-998a-c43fe78e89f6@github.com>

> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
> 
> With Float16 we need to differentiate b/w vector lane element type and carrier type. while element type corresponds to exact type of lane i.e. Float16.class, carrier type corresponds to the storage type required to propagate IEEE 754 float16 values to inline expander.
> 
> Patch adds a new carrier type to existing LaneType structure and use it for following purpose.
>  - To compute preferred shape of vector.
>  - To allocate vector backing storage during dummy vector and iota array creation.
>  - Sanity checking to ensure vector lane type is a primitive type in inline expander.
> 
> All existing Vector API jtreg test are passing with the patch.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review comments resolution

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29629/files
  - new: https://git.openjdk.org/jdk/pull/29629/files/91889b08..4951ce37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29629&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29629&range=01-02

  Stats: 4 lines in 1 file changed: 3 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29629.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29629/head:pull/29629

PR: https://git.openjdk.org/jdk/pull/29629

From jbhateja at openjdk.org  Tue Feb 24 05:06:16 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 24 Feb 2026 05:06:16 GMT
Subject: RFR: 8377438: [VectorAPI] Add new carrier type to LaneType class
 [v2]
In-Reply-To: <3kWj8D_3GGIVKmW2_KSL7GqM5bY_GV3wCPGK5a3Qjcw=.7329365f-d14a-49b6-925d-b8b5da681d2d@github.com>
References: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
 <qmSybXnaUH8CxOjqOJwhdINd_GhiWX6OlG8ABL1GScE=.fe7f9703-d35a-475f-9e85-ed9063f3648d@github.com>
 <3kWj8D_3GGIVKmW2_KSL7GqM5bY_GV3wCPGK5a3Qjcw=.7329365f-d14a-49b6-925d-b8b5da681d2d@github.com>
Message-ID: <jF-WxOqtkWwp7mPIKV6BAi80BENkQ0JvD43CarIXwig=.53170612-a023-492a-88d2-ed62553449dd@github.com>

On Tue, 24 Feb 2026 01:09:43 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8377438
>>  - 8377438: [VectorAPI] Add new carrier type to LaneType class
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LaneType.java line 70:
> 
>> 68:         this.typeChar = genericElementType.getSimpleName().charAt(0);
>> 69:         this.carrierType = carrierType;
>> 70:         assert("FDBSIL".indexOf(typeChar) == ordinal()) : this;
> 
> Can you move this assert statement to be directly after where `typeChar` is assigned? Then after the assignment of `carrierType` you can `assert(carrierType.isPrimitive())`, which while not full-proof does express the intent.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29629#discussion_r2844518113

From duke at openjdk.org  Tue Feb 24 05:22:23 2026
From: duke at openjdk.org (David Beaumont)
Date: Tue, 24 Feb 2026 05:22:23 GMT
Subject: Integrated: 8378118: Test tools/jimage/JImageBadFileTest.java failed
 on Windows
In-Reply-To: <osTab7bHlL02EfiBJGHxrsjqzGcRVxrS8jbWWVz_eFg=.ed9d1730-0cd6-425c-9ccf-ebd7e1e96a79@github.com>
References: <osTab7bHlL02EfiBJGHxrsjqzGcRVxrS8jbWWVz_eFg=.ed9d1730-0cd6-425c-9ccf-ebd7e1e96a79@github.com>
Message-ID: <lJDeAc8Ck73xnMZqat6xTEq9T3MaCBOLYlJwMjrCBWo=.8df2868e-6ff9-4cea-bbcd-1ef7082a7013@github.com>

On Wed, 18 Feb 2026 10:42:01 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removed the manual file tidyup on the expectation that jtreg will sort that all out.
> Switched to using Utils.createTempFile() while I was there.

This pull request has now been integrated.

Changeset: 75f8f08f
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/75f8f08f3b6b4e3b211553ed78862ab03ca5d216
Stats:     46 lines in 1 file changed: 2 ins; 23 del; 21 mod

8378118: Test tools/jimage/JImageBadFileTest.java failed on Windows

Reviewed-by: rriggs, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/29783

From jbhateja at openjdk.org  Tue Feb 24 06:17:30 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 24 Feb 2026 06:17:30 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating
 broadcasted inputs [v4]
In-Reply-To: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
References: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
Message-ID: <pOF2vnq6e-ycbGs8DKIkJiCQBXHMY-O9rea_Ua-giCM=.b21d2594-2375-41cc-8ff6-8491ac332ea2@github.com>

> Hi all,
> 
> This patch optimizes SIMD kernels making heavy use of broadcasted inputs through following reassociating ideal transformations.
> 
> 
>  VectorOperation (VectorBroadcast INP1,  VectorBroadcast INP2) => 
>                             VectorBroadcast (ScalarOpration INP1, INP2)
> 
>  VectorOperation (VectorBroadcast INP1) (VectorOperation (VectorBroadcast INP2) INP3) => 
>                              VectorOperation INP3 (VectorOperation (VectorBroadcast INP1) (VectorOperation INP2))
> 
> 
> The idea is to push broadcasts across the vector operation and replace the vector with an equivalent, cheaper scalar variant.  Currently, patch handles most common vector operations.
> 
> Following are the performance number of benchmark included with this patch on latest generation x86 targets:- 
> 
> **AMD Turin (2.1GHz)**
> <img width="1122" height="355" alt="image" src="https://github.com/user-attachments/assets/3f5087bf-0e14-4c56-b0c2-3d23253bad54" />
> 
> **Intel Granite Rapids (2.1GHz)**
> <img width="1105" height="325" alt="image" src="https://github.com/user-attachments/assets/c8481f86-4db2-4c4e-bd65-51542c59fe63" />
> 
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review comments resolutions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25617/files
  - new: https://git.openjdk.org/jdk/pull/25617/files/c28e1d60..15f2d57e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25617&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25617&range=02-03

  Stats: 21 lines in 1 file changed: 7 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25617.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25617/head:pull/25617

PR: https://git.openjdk.org/jdk/pull/25617

From jbhateja at openjdk.org  Tue Feb 24 06:17:31 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 24 Feb 2026 06:17:31 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating
 broadcasted inputs [v4]
In-Reply-To: <HsWohyElLTSz6Ht7ns2eo1ftP_GP81PFRPDp74m0HjE=.ffa8f03c-dd96-4eb5-9588-31a64ef6ce76@github.com>
References: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
 <S09FWymoHUyMEhDZNodmP8jQKslTWH5pa1bilHA0I7w=.5e9af240-b87d-4b11-bcc4-8e07d3b9d00b@github.com>
 <8NV2dH7Ingzw2y7E4MEflV9bipfpei8MYIgA9ErG_AI=.ab852238-f137-4f22-8247-28758c57c1e2@github.com>
 <HsWohyElLTSz6Ht7ns2eo1ftP_GP81PFRPDp74m0HjE=.ffa8f03c-dd96-4eb5-9588-31a64ef6ce76@github.com>
Message-ID: <Y6lxdY-hryDo31_irfKJcmDuyk-iDJCz18ivMMNThAU=.834267c5-55b0-4dc8-84c1-2ff2cefea5e8@github.com>

On Mon, 23 Feb 2026 07:02:56 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Reassociation are only applicable to integral vector operation, for vector API we only use fp-fast model semantics for reductions of floating point vector, I have now added tests to cover all possible transformations so that we can include both associated transforms in same patch.
>
> I still keep my point that separating the reassociation as a separate PR for better maintain. WDYT?

Hi @XiaohongGong , Since reassociations are mainly about broadcasts will request for including them along with this patch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2844747925

From alanb at openjdk.org  Tue Feb 24 07:28:53 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Feb 2026 07:28:53 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <jXQygbK7vttEt0NTmm-QS7ZlHV3bFpsFlpZXM0_GMQ4=.f2266e7c-2f0e-4c70-b10d-efc088e3e0b6@github.com>
References: <jXQygbK7vttEt0NTmm-QS7ZlHV3bFpsFlpZXM0_GMQ4=.f2266e7c-2f0e-4c70-b10d-efc088e3e0b6@github.com>
Message-ID: <OFRRmQXTypAz1po47lYNTIMZV9k8nvAENSehyXUWfBY=.df9cd98b-272e-4411-8cb9-08dfdab42eb2@github.com>

On Sat, 21 Feb 2026 16:51:17 GMT, cdw200806 <duke at openjdk.org> wrote:

> Raise a new PR. for https://github.com/openjdk/jdk/pull/24612 is too old.
> 
> "In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red."

@cdw200806  You need to add a comment with "/integrate" so it can be sponsored.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29857#issuecomment-3949752749

From alanb at openjdk.org  Tue Feb 24 07:31:57 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Feb 2026 07:31:57 GMT
Subject: RFR: 8377102: cacerts jlink plugin
In-Reply-To: <RTLm4nVWh9omwws3G3XiedqOrrjNtozN17a-tpPnx58=.5e4bd3a9-7bf8-4989-9db1-5fab4c358092@github.com>
References: <pRqfyRXHZHI7_wpjlirukGFoiqBdiQ58hH8z7km54Aw=.0e1621b5-1851-4783-bd2e-ba6b28f1ead6@github.com>
 <KO2N_m01Am-QlnpxbvSUrHR89gvgXX0hgz_4tEaVLck=.3883963f-5c47-4ce8-8484-4e23bdfe79d6@github.com>
 <RTLm4nVWh9omwws3G3XiedqOrrjNtozN17a-tpPnx58=.5e4bd3a9-7bf8-4989-9db1-5fab4c358092@github.com>
Message-ID: <aSbvkB8_zojmu0iHsaN0DtnY6OcQPQeUOYx5qHt6sd4=.b4406fa1-9f31-44fb-9e65-59f39b209b66@github.com>

On Fri, 13 Feb 2026 18:53:38 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> However, I am curious if there is a need to support adding additional root certs (ex: by specifying a PEM file), or if the developer/admin should be required to import that into the cacerts keystore (before or after).

It might be helpful to sketch out how this might look and whether it would likely mean a new plugin or extending the current cacerts plugin. That would help with deciding on the discoverability and supportability of the current proposal.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29700#issuecomment-3949763366

From alanb at openjdk.org  Tue Feb 24 07:41:47 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Feb 2026 07:41:47 GMT
Subject: RFR: 8376483: Avoid loading java.nio.charset.StandardCharsets in
 java.util.zip.ZipCoder
In-Reply-To: <UbxQHs0hCZjsQyxXGQ7LiyFAvrDrRwfwZ3gx6lhdCzs=.e3e31eac-bc04-40c4-873e-7e278df00ee3@github.com>
References: <UbxQHs0hCZjsQyxXGQ7LiyFAvrDrRwfwZ3gx6lhdCzs=.e3e31eac-bc04-40c4-873e-7e278df00ee3@github.com>
Message-ID: <EXeQpAM2r7lg3TQmrkSEcSFod6h06oEengimtd9DqY4=.605845e7-fe9e-4cc2-8d6e-6347f6e5105c@github.com>

On Tue, 27 Jan 2026 10:44:42 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which removes a dependency on `java.nio.charset.StandardCharsets` introduced in [JDK-8365703](https://bugs.openjdk.org/browse/JDK-8365703).
> 
> We can use `UTF_8.INSTANCE` here as elsewhere in this class to prevent startup regression loading otherwise unused classes and charsets.
> 
> Verified that running `java -cp hello.jar Hello` observes the following diff in loaded classes when run with this PR:
> 
> 
> < java.nio.charset.StandardCharsets
> < sun.nio.cs.US_ASCII
> < sun.nio.cs.ISO_8859_1
> < sun.nio.cs.UTF_16BE
> < sun.nio.cs.UTF_16LE
> < sun.nio.cs.UTF_16
> < sun.nio.cs.UTF_32BE
> < sun.nio.cs.UTF_32LE
> < sun.nio.cs.UTF_32
> 
> 
> This is a strict refactoring, no tests updated, `noreg-trivial`.

There was effort a few years ago to push out the first use of StandardCharsets as its initializer loaded all the standard charsets. So this is why you will have seen usages replaced with (mostly) UTF_8.INSTANCE. This was all before Project Leyden and the recent work on AOT. It would be useful to do some measurements to see if this change shows any benefit.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29443#issuecomment-3949805217

From epeter at openjdk.org  Tue Feb 24 08:46:08 2026
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 24 Feb 2026 08:46:08 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating
 broadcasted inputs [v4]
In-Reply-To: <pOF2vnq6e-ycbGs8DKIkJiCQBXHMY-O9rea_Ua-giCM=.b21d2594-2375-41cc-8ff6-8491ac332ea2@github.com>
References: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
 <pOF2vnq6e-ycbGs8DKIkJiCQBXHMY-O9rea_Ua-giCM=.b21d2594-2375-41cc-8ff6-8491ac332ea2@github.com>
Message-ID: <_k3M5u2VvDg1uyHvIzWKJ7I9EDrYl0RijaDnvwKCYrY=.b7353580-c3ed-47b0-a56c-26e039a6c2ac@github.com>

On Tue, 24 Feb 2026 06:17:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch optimizes SIMD kernels making heavy use of broadcasted inputs through following reassociating ideal transformations.
>> 
>> 
>>  VectorOperation (VectorBroadcast INP1,  VectorBroadcast INP2) => 
>>                             VectorBroadcast (ScalarOpration INP1, INP2)
>> 
>>  VectorOperation (VectorBroadcast INP1) (VectorOperation (VectorBroadcast INP2) INP3) => 
>>                              VectorOperation INP3 (VectorOperation (VectorBroadcast INP1) (VectorOperation INP2))
>> 
>> 
>> The idea is to push broadcasts across the vector operation and replace the vector with an equivalent, cheaper scalar variant.  Currently, patch handles most common vector operations.
>> 
>> Following are the performance number of benchmark included with this patch on latest generation x86 targets:- 
>> 
>> **AMD Turin (2.1GHz)**
>> <img width="1122" height="355" alt="image" src="https://github.com/user-attachments/assets/3f5087bf-0e14-4c56-b0c2-3d23253bad54" />
>> 
>> **Intel Granite Rapids (2.1GHz)**
>> <img width="1105" height="325" alt="image" src="https://github.com/user-attachments/assets/c8481f86-4db2-4c4e-bd65-51542c59fe63" />
>> 
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions

Just scanned the PR description:

 VectorOperation (VectorBroadcast INP1) (VectorOperation (VectorBroadcast INP2) INP3) => 
                             VectorOperation INP3 (VectorOperation (VectorBroadcast INP1) (VectorOperation INP2))

I think it should be `VectorBroadcast INP2` in both cases, and not `VectorOperation INP2`, because `INP2` is scalar, right?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25617#issuecomment-3950091432

From duke at openjdk.org  Tue Feb 24 09:10:47 2026
From: duke at openjdk.org (duke)
Date: Tue, 24 Feb 2026 09:10:47 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <jXQygbK7vttEt0NTmm-QS7ZlHV3bFpsFlpZXM0_GMQ4=.f2266e7c-2f0e-4c70-b10d-efc088e3e0b6@github.com>
References: <jXQygbK7vttEt0NTmm-QS7ZlHV3bFpsFlpZXM0_GMQ4=.f2266e7c-2f0e-4c70-b10d-efc088e3e0b6@github.com>
Message-ID: <P9_7ssbX69oxPRbsrG7h72C5oOJlWYaspTfnIWa_hYU=.279d1041-5ca0-4c6d-b4eb-294ca40ea97d@github.com>

On Sat, 21 Feb 2026 16:51:17 GMT, cdw200806 <duke at openjdk.org> wrote:

> Raise a new PR. for https://github.com/openjdk/jdk/pull/24612 is too old.
> 
> "In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red."

@cdw200806 
Your change (at version 378c31e9c525e30f4dff008a9d3fbcfe64668081) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29857#issuecomment-3950200335

From duke at openjdk.org  Tue Feb 24 09:19:19 2026
From: duke at openjdk.org (cdw200806)
Date: Tue, 24 Feb 2026 09:19:19 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <OFRRmQXTypAz1po47lYNTIMZV9k8nvAENSehyXUWfBY=.df9cd98b-272e-4411-8cb9-08dfdab42eb2@github.com>
References: <jXQygbK7vttEt0NTmm-QS7ZlHV3bFpsFlpZXM0_GMQ4=.f2266e7c-2f0e-4c70-b10d-efc088e3e0b6@github.com>
 <OFRRmQXTypAz1po47lYNTIMZV9k8nvAENSehyXUWfBY=.df9cd98b-272e-4411-8cb9-08dfdab42eb2@github.com>
Message-ID: <1H-Kla8YUbB0bT9m-MA-_1XXbrnYWl4U_YRow3E_ic8=.26325b8f-df63-45ae-899b-e65c3af8d8fa@github.com>

On Tue, 24 Feb 2026 07:25:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> @cdw200806 You need to add a comment with "/integrate" so it can be sponsored.

Hi @AlanBateman , thanks for your reminding, now it is ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29857#issuecomment-3950252160

From jbhateja at openjdk.org  Tue Feb 24 10:10:17 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 24 Feb 2026 10:10:17 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v14]
In-Reply-To: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
Message-ID: <ZFFAsf3VHOHPTZc3NvS5Kq9NLUGyKL2T-Sh7RYW-_cs=.05b0d3b7-7702-488f-8e81-08c0a4086675@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:

  Review comments resolution

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24104/files
  - new: https://git.openjdk.org/jdk/pull/24104/files/1dfff558..444a3568

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=12-13

  Stats: 75 lines in 5 files changed: 67 ins; 0 del; 8 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  Tue Feb 24 10:10:22 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 24 Feb 2026 10:10:22 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v13]
In-Reply-To: <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <0kDkrpWRa2BWBVGbm4Ij5AmsbSXuOyt_lZNwxxivaWI=.1d995ff6-896f-4b31-a4d8-3b1ed4871b74@github.com>
Message-ID: <N0LTfaM_L0EmiszoB-uxxMUiGNcFleO-RGAWAZNB8Cs=.3e83dffd-fb35-4caa-9841-578b425d1cac@github.com>

On Mon, 9 Feb 2026 21:36:16 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 with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - Review comments resolutions
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - Review comments resolutions
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - Update callGenerator.hpp copyright year
>  - Review comments resolution
>  - Cleanups
>  - Review comments resolutions
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/ffb6279c...1dfff558

> I?m fine with using the more straightforward approach to intrinsify the slice API when the origin is a constant. In my view, this could also benefit other APIs and future optimizations (for example, #28520), since slice is a general vector operation. Relying on pattern matching makes the compiler implementation significantly more complex in my opinion.
> 
> Regarding inlining of the fallback implementation, I think we do need such a mechanism to handle APIs that fail to inline on the first attempt, given that the current fallback overhead is much heavier and leads to worse performance. And I agree with @merykitty that a more generic solution would be more preferable.

Hi @merykitty , @XiaohongGong , Based on the feedback received, I have modified the patch to not inline on first intrinsic failure, instead I now collect such CallGenerators and only towards the end on incremental inlining I inline expands the fallback implementation on the lines of _string_late_inlines.

This will give opportunity to create constant context for VectorSlice intrinsification and if that fails we inline the fallback implimentation to avoid any costly boxing penalties.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3950522542

From epeter at openjdk.org  Tue Feb 24 10:34:56 2026
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 24 Feb 2026 10:34:56 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating
 broadcasted inputs [v4]
In-Reply-To: <pOF2vnq6e-ycbGs8DKIkJiCQBXHMY-O9rea_Ua-giCM=.b21d2594-2375-41cc-8ff6-8491ac332ea2@github.com>
References: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
 <pOF2vnq6e-ycbGs8DKIkJiCQBXHMY-O9rea_Ua-giCM=.b21d2594-2375-41cc-8ff6-8491ac332ea2@github.com>
Message-ID: <v7k5NyQnSGV8lLiNTdBSNdkNrkPPj_XU-uXqMRcN-M4=.d136f0a8-a56a-4f3c-94b9-1e56e6db2527@github.com>

On Tue, 24 Feb 2026 06:17:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch optimizes SIMD kernels making heavy use of broadcasted inputs through following reassociating ideal transformations.
>> 
>> 
>>  VectorOperation (VectorBroadcast INP1,  VectorBroadcast INP2) => 
>>                             VectorBroadcast (ScalarOpration INP1, INP2)
>> 
>>  VectorOperation (VectorBroadcast INP1) (VectorOperation (VectorBroadcast INP2) INP3) => 
>>                              VectorOperation INP3 (VectorOperation (VectorBroadcast INP1) (VectorBroadcast INP2))
>> 
>> 
>> The idea is to push broadcasts across the vector operation and replace the vector with an equivalent, cheaper scalar variant.  Currently, patch handles most common vector operations.
>> 
>> Following are the performance number of benchmark included with this patch on latest generation x86 targets:- 
>> 
>> **AMD Turin (2.1GHz)**
>> <img width="1122" height="355" alt="image" src="https://github.com/user-attachments/assets/3f5087bf-0e14-4c56-b0c2-3d23253bad54" />
>> 
>> **Intel Granite Rapids (2.1GHz)**
>> <img width="1105" height="325" alt="image" src="https://github.com/user-attachments/assets/c8481f86-4db2-4c4e-bd65-51542c59fe63" />
>> 
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions

Interesting work, @jatin-bhateja !

Looks like a reasonable optimization.

We need to be very careful with subword types: the vector operations have truncating behavior, and the scalar operations do not. We need to test the optimization well for that. You are currently missing tests for `byte` etc, you need to add those :)

src/hotspot/share/opto/subnode.hpp line 524:

> 522:     if (c != nullptr) {
> 523:       C->add_expensive_node(this);
> 524:     }

Can you explain a bit more about this change? What is the flag used for, and why did you need to change it?

src/hotspot/share/opto/subnode.hpp line 524:

> 522:     if (c != nullptr) {
> 523:       C->add_expensive_node(this);
> 524:     }

Can you please explain why you made this change?

src/hotspot/share/opto/vectornode.cpp line 301:

> 299: // Return the scalar opcode for the specified vector opcode
> 300: // and basic type.
> 301: int VectorNode::scalar_opcode(int vopc, BasicType bt, bool enable_assertions) {

Do you really need the `enable_assertions` argument here? You always set it to `false` when calling it.
And the user could still assert if they get a `0` return.

src/hotspot/share/opto/vectornode.cpp line 301:

> 299: // Return the scalar opcode for the specified vector opcode
> 300: // and basic type.
> 301: int VectorNode::scalar_opcode(int vopc, BasicType bt, bool enable_assertions) {

`enable_assertions` is never used with `true`. You should just remove it.

src/hotspot/share/opto/vectornode.cpp line 442:

> 440:              "Vector node %s is not handled in VectorNode::scalar_opcode",
> 441:              NodeClassNames[vopc]);
> 442:       return 0; // Unimplemented

Maybe "not handled" is better here. That is also what your assert says. Because it may be that both the vector and scalar ops are implemented, we just don't handle it here.

src/hotspot/share/opto/vectornode.cpp line 442:

> 440:              "Vector node %s is not handled in VectorNode::scalar_opcode",
> 441:              NodeClassNames[vopc]);
> 442:       return 0; // Unimplemented

I would not say unimplemented, rather not handled. The scalar and vector operations may be implemented, just not handled here.

src/hotspot/share/opto/vectornode.cpp line 1194:

> 1192: 
> 1193: // Helper function to select a vector operation with all broadcasted inputs
> 1194: bool VectorNode::can_push_broadcasts_across_vector_operation(BasicType bt) {

The comment does not quite seem to match here. We don't do any "selecting" here, we just check and return a boolean, right?

src/hotspot/share/opto/vectornode.cpp line 1194:

> 1192: 
> 1193: // Helper function to select a vector operation with all broadcasted inputs
> 1194: bool VectorNode::can_push_broadcasts_across_vector_operation(BasicType bt) {

The comment does not match. The method does no selection, rather it just checks. Please fix :)

src/hotspot/share/opto/vectornode.cpp line 1213:

> 1211: }
> 1212: 
> 1213: Node* VectorNode::scalar_node_factory(Compile* c, int sopc, Node* control, Node* in1, Node* in2, Node* in3) {

I think generally, consistency with our naming scheme would be `make_scalar`, rather than "factory".

src/hotspot/share/opto/vectornode.cpp line 1213:

> 1211: }
> 1212: 
> 1213: Node* VectorNode::scalar_node_factory(Compile* c, int sopc, Node* control, Node* in1, Node* in2, Node* in3) {

I think we usually call factory methods like this: `make_scalar`.
Also: Compile is usually an upper case `C`.

src/hotspot/share/opto/vectornode.cpp line 1280:

> 1278:       return new FmaDNode(in1, in2, in3);
> 1279:     default:
> 1280:       return nullptr;

Is returning `nullptr` ok? Or should we have checked the conditions earlier?
Could we add an assert here?

src/hotspot/share/opto/vectornode.cpp line 1280:

> 1278:       return new FmaDNode(in1, in2, in3);
> 1279:     default:
> 1280:       return nullptr;

Could we add an assert?

src/hotspot/share/opto/vectornode.cpp line 1294:

> 1292:   cloned_parent->set_req(2, pinput2);
> 1293:   return cloned_parent;
> 1294: }

Can you add a comment that explains the code shape before and after?
Otherwise I'd have to reconstruct the semantics from the call site.

Also: the method is non-static, and `partent == this`. Is that on purpose?

src/hotspot/share/opto/vectornode.cpp line 1294:

> 1292:   cloned_parent->set_req(2, pinput2);
> 1293:   return cloned_parent;
> 1294: }

Multiple points:
- This method is non-static, and it seems all calls to it have `this == parent`.
- Can you please add a comment that shows the transformation using the input names?

src/hotspot/share/opto/vectornode.cpp line 1326:

> 1324:       return create_reassociated_node(this, in2, in1, in2_1, in2_2, phase);
> 1325:     } else if (in2_2->Opcode() == Op_Replicate) {
> 1326:       return create_reassociated_node(this, in2, in1, in2_2, in2_1, phase);

It looks like you made `create_reassociated_node` non-static, and still pass in `this` as the first argument. Is that on purpose?

src/hotspot/share/opto/vectornode.cpp line 1339:

> 1337: //   VectorBroadcast (ScalarOperation INP1, INP2)
> 1338: //
> 1339: Node* VectorNode::push_broadcast_across_vector_operation(PhaseGVN* phase) {

I would rename it to `push_through_broadcast`, to keep it similar to `split_thru_region/phi` and `push_thru_add` etc.

src/hotspot/share/opto/vectornode.cpp line 1339:

> 1337: //   VectorBroadcast (ScalarOperation INP1, INP2)
> 1338: //
> 1339: Node* VectorNode::push_broadcast_across_vector_operation(PhaseGVN* phase) {

I would call this method like `split_thru_phi` or `push_through_add`:
`push_through_broadcast`.

src/hotspot/share/opto/vectornode.cpp line 1361:

> 1359: 
> 1360:     Node* sop = scalar_node_factory(phase->C, scalar_opcode(Opcode(), bt, false), in(0), sinp1, sinp2, sinp3);
> 1361:     if (sop) {

Suggestion:

    if (sop != nullptr) {

Implicit null check not allowed (hotspot style guide)

src/hotspot/share/opto/vectornode.cpp line 1363:

> 1361:     if (sop) {
> 1362:       sop = phase->transform(sop);
> 1363:       return new ReplicateNode(sop, vect_type());

Suppose we have an `add` operation on a `byte` vector. The operations are truncated. But the `AddI` operation would overflow the `byte` range. Does the `Replicate` node ensure that truncation?

src/hotspot/share/opto/vectornode.cpp line 1363:

> 1361:     if (sop) {
> 1362:       sop = phase->transform(sop);
> 1363:       return new ReplicateNode(sop, vect_type());

How sure are you that the truncating vector operations are correctly optimized with the non-truncating scalar operations? Is it guaranteed that `Replicate` does the truncation?

src/hotspot/share/opto/vectornode.cpp line 2104:

> 2102:     return VectorNode::degenerate_vector_rotate(in(1), in(2), true, vlen, bt, phase);
> 2103:   }
> 2104:   return VectorNode::Ideal(phase, can_reshape);

Would it not make sense to do the `Ideal` before the possible degeneration? Just in case we can optimize away the rotation, by pushing it through the broadcast?

src/hotspot/share/opto/vectornode.cpp line 2104:

> 2102:     return VectorNode::degenerate_vector_rotate(in(1), in(2), true, vlen, bt, phase);
> 2103:   }
> 2104:   return VectorNode::Ideal(phase, can_reshape);

Similar for other cases below: why not do `Ideal` before degeneration?

src/hotspot/share/opto/vectornode.cpp line 2411:

> 2409:     }
> 2410:   }
> 2411:   return VectorNode::Ideal(phase, can_reshape);

Same question here: why not first try to do `Ideal` before resorting to degeneration?

test/hotspot/jtreg/compiler/vectorapi/TestVectorBroadcastReassociations.java line 42:

> 40: 
> 41:     public static void main(String[] args) {
> 42:         TestFramework.runWithFlags("--add-modules=jdk.incubator.vector");

This is really important: you need to test the subword types. We need to be sure that the truncated behavior of the vector operations are correctly optimized with the non-truncating scalar operations.

test/hotspot/jtreg/compiler/vectorapi/TestVectorBroadcastReassociations.java line 50:

> 48: 
> 49:     static final VectorSpecies<Integer> ISP = IntVector.SPECIES_PREFERRED;
> 50:     static int ia = 17, ib = 9;

We need to have random inputs. Because if something goes wrong, and for some reason the vector and scalar operations don't have the same semantics, we need to catch that.

Vector operations have truncation, and scalar operations do not. We need to make sure we test that behavior.

test/hotspot/jtreg/compiler/vectorapi/TestVectorBroadcastReassociations.java line 50:

> 48: 
> 49:     static final VectorSpecies<Integer> ISP = IntVector.SPECIES_PREFERRED;
> 50:     static int ia = 17, ib = 9;

You need random input values that span the whole range.

We really need to be careful to test that the vector and scalar operations do the same thing here. We've had issues with truncation behavior before. So you need to test overflows.

test/hotspot/jtreg/compiler/vectorapi/TestVectorBroadcastReassociations.java line 55:

> 53:     @IR(failOn = IRNode.ADD_VI,
> 54:         applyIfCPUFeatureOr = {"avx", "true", "asimd", "true"},
> 55:         counts = { IRNode.ADD_I, ">= 1", IRNode.REPLICATE_I, IRNode.VECTOR_SIZE_ANY, ">= 1" })

Why do you have the `VECTOR_SIZE_ANY`?

test/hotspot/jtreg/compiler/vectorapi/TestVectorBroadcastReassociations.java line 60:

> 58:                 .add(IntVector.broadcast(ISP, ib))
> 59:                 .reduceLanes(VectorOperators.ADD);
> 60:     }

Why do you have the `VECTOR_SIZE_ANY`? Do we not get a replicate with the maximal size?

I don't think it is wise to take an ADD reduction here, because that may also produce a ADD_I node. And then you're not sure if the IR rule finds that one or the one generated from the broadcast optimization.

test/hotspot/jtreg/compiler/vectorapi/TestVectorBroadcastReassociations.java line 136:

> 134:      * ======================= */
> 135: 
> 136:     static final VectorSpecies<Long> LSP = LongVector.SPECIES_PREFERRED;

Why don't you have the logical operators for long tested below?

-------------

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25617#pullrequestreview-3846137446
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845457463
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845895589
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845472407
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845898307
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845572109
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845902534
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845591368
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845909648
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845695003
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845914938
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845703712
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845916417
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845718222
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845923701
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845710822
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845772045
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845928736
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845799719
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845815077
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845936327
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845829459
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845938602
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845835099
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845891340
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845851868
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845875701
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845856355
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845869949
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845881322

From epeter at openjdk.org  Tue Feb 24 10:34:58 2026
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 24 Feb 2026 10:34:58 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating
 broadcasted inputs [v4]
In-Reply-To: <v7k5NyQnSGV8lLiNTdBSNdkNrkPPj_XU-uXqMRcN-M4=.d136f0a8-a56a-4f3c-94b9-1e56e6db2527@github.com>
References: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
 <pOF2vnq6e-ycbGs8DKIkJiCQBXHMY-O9rea_Ua-giCM=.b21d2594-2375-41cc-8ff6-8491ac332ea2@github.com>
 <v7k5NyQnSGV8lLiNTdBSNdkNrkPPj_XU-uXqMRcN-M4=.d136f0a8-a56a-4f3c-94b9-1e56e6db2527@github.com>
Message-ID: <IuPKcR_st0htD5rlY4i7uGJnkObqrb1Y9bD-xSh7GJ0=.876a2753-eea4-40bf-aa3a-bfd932d8d66a@github.com>

On Tue, 24 Feb 2026 09:27:56 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions
>
> src/hotspot/share/opto/vectornode.cpp line 1194:
> 
>> 1192: 
>> 1193: // Helper function to select a vector operation with all broadcasted inputs
>> 1194: bool VectorNode::can_push_broadcasts_across_vector_operation(BasicType bt) {
> 
> The comment does not quite seem to match here. We don't do any "selecting" here, we just check and return a boolean, right?

This reminds me of `push through phi` operations. Why not call it:
`can_push_through_broadcast`

Because I struggle to understand how one can push a broadcast "across" a vector operation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2845682132

From duke at openjdk.org  Tue Feb 24 10:54:12 2026
From: duke at openjdk.org (cdw200806)
Date: Tue, 24 Feb 2026 10:54:12 GMT
Subject: Integrated: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <jXQygbK7vttEt0NTmm-QS7ZlHV3bFpsFlpZXM0_GMQ4=.f2266e7c-2f0e-4c70-b10d-efc088e3e0b6@github.com>
References: <jXQygbK7vttEt0NTmm-QS7ZlHV3bFpsFlpZXM0_GMQ4=.f2266e7c-2f0e-4c70-b10d-efc088e3e0b6@github.com>
Message-ID: <ofYnMTuG4DJpFVBh8GZ45V3W7JTkLdfxaMzkhenfk_E=.3564a503-f020-4a9c-9a19-21c1917b9504@github.com>

On Sat, 21 Feb 2026 16:51:17 GMT, cdw200806 <duke at openjdk.org> wrote:

> Raise a new PR. for https://github.com/openjdk/jdk/pull/24612 is too old.
> 
> "In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red."

This pull request has now been integrated.

Changeset: b99d1f0a
Author:    cdw200806 <56459974+cdw200806 at users.noreply.github.com>
Committer: Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b99d1f0a1723261718d68ffafbdb9efb315ccfc7
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8378354: Faulty assertion in checkInvariants method of ConcurrentHashMap

Reviewed-by: alanb, vklang

-------------

PR: https://git.openjdk.org/jdk/pull/29857

From duke at openjdk.org  Tue Feb 24 11:05:08 2026
From: duke at openjdk.org (cdw200806)
Date: Tue, 24 Feb 2026 11:05:08 GMT
Subject: RFR: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
References: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
Message-ID: <560QxWY_iOeEgasqF5pDHIuh1YdLgEqo5e7vE6ftA9s=.8731f48e-7dba-49de-b8d4-0a0df3bff29b@github.com>

On Sun, 13 Apr 2025 10:31:34 GMT, cdw200806 <duke at openjdk.org> wrote:

> "In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red."

Since PR(https://github.com/openjdk/jdk/pull/29857 ) has been merged, then I close this PR now.

Since PR(https://github.com/openjdk/jdk/pull/29857 ) has been merged, then I close this PR now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3950883298
PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3950884225

From duke at openjdk.org  Tue Feb 24 11:05:09 2026
From: duke at openjdk.org (cdw200806)
Date: Tue, 24 Feb 2026 11:05:09 GMT
Subject: Withdrawn: 8378354: Faulty assertion in checkInvariants method of
 ConcurrentHashMap
In-Reply-To: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
References: <BqRxYkmfbCs8jDSlD8rgUkb6TNSHync-LD5PSuW5kbc=.0349cd55-d66d-4065-82a9-dadcb04b95fe@github.com>
Message-ID: <ZCadDjQR07eSuM0UcOmjQPfU5j1-2I69SaVEE9TwlW0=.06fe0ecd-0c17-4ebb-86f2-104bf58dcc5f@github.com>

On Sun, 13 Apr 2025 10:31:34 GMT, cdw200806 <duke at openjdk.org> wrote:

> "In Red-Black Trees, a red node cannot have any red children; this rule is violated even if only one child is red, not just when both children are red."

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24612

From duke at openjdk.org  Tue Feb 24 12:18:31 2026
From: duke at openjdk.org (duke)
Date: Tue, 24 Feb 2026 12:18:31 GMT
Subject: Withdrawn: 8373186: Improve readability of core reflection toString
 specifications
In-Reply-To: <sVTxj2pBoYFntQlqQTJe06qjR6CbcNXCZmVs3j_r3a8=.e2b61e45-9fca-4b53-bf66-7e58eba6e2f4@github.com>
References: <sVTxj2pBoYFntQlqQTJe06qjR6CbcNXCZmVs3j_r3a8=.e2b61e45-9fca-4b53-bf66-7e58eba6e2f4@github.com>
Message-ID: <3zgajnkpwHu17m5Ck_8OzEYV24HNZs1PZx0OEx1ciIk=.fb0a71d6-ff85-4f2c-a142-17c17b03bf56@github.com>

On Sat, 6 Dec 2025 21:35:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Partial implementation of a spec refactoring to get some feedback before writing similar changes for other core reflection types.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/28688

From eirbjo at openjdk.org  Tue Feb 24 14:05:49 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 24 Feb 2026 14:05:49 GMT
Subject: RFR: 8376483: Avoid loading java.nio.charset.StandardCharsets in
 java.util.zip.ZipCoder
In-Reply-To: <EXeQpAM2r7lg3TQmrkSEcSFod6h06oEengimtd9DqY4=.605845e7-fe9e-4cc2-8d6e-6347f6e5105c@github.com>
References: <UbxQHs0hCZjsQyxXGQ7LiyFAvrDrRwfwZ3gx6lhdCzs=.e3e31eac-bc04-40c4-873e-7e278df00ee3@github.com>
 <EXeQpAM2r7lg3TQmrkSEcSFod6h06oEengimtd9DqY4=.605845e7-fe9e-4cc2-8d6e-6347f6e5105c@github.com>
Message-ID: <BK7jp5uEMZI80x72blA--TrcpXOzmD9SS4a27qmI6t0=.e74ff0a8-727d-4b32-830c-554e25c05e8f@github.com>

On Tue, 24 Feb 2026 07:39:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There was effort a few years ago to push out the first use of StandardCharsets as its initializer loaded all the standard charsets. So this is why you will have seen usages replaced with (mostly) UTF_8.INSTANCE. This was all before Project Leyden and the recent work on AOT. It would be useful to do some measurements to see if this change shows any benefit.

We could certainly do measurements.  However; the use of `StandardCharsets` was introduced last August via #26822. Before that change `ZipCoder` used strictly `UTF_8.INSTANCE`. That PR did not mention `StandardCharsets` or any motivation for introducing it. To me, this looked like a simple oversight.

I don't have strong opinions of whether we should use `UTF_8.INSTANCE` or `StandardCharsets`, but would prefer if we can be consistent in this class/area and that any choice is deliberate and not just something slipped in sideways.

In other words, I think the burden of proof should be on #26822 for introducing `StandardCharsets.UTF_8.INSTANCE` in a class that otherwise uses `UTF_8.INSTANCE`, not for this PR reestablishing consistency and long time practise.

But again, opinions loosely help, I can surely withdraw this PR if that's consenus, even if I don't quite understand why :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29443#issuecomment-3952119241

From aefimov at openjdk.org  Tue Feb 24 14:48:51 2026
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 24 Feb 2026 14:48:51 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v5]
In-Reply-To: <39nXLnFR2Kl257ljgwgsenJDyFCuL6EegMWXeeSZGI0=.3c3c2250-2ff9-44e1-8647-c23bf643a14b@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
 <39nXLnFR2Kl257ljgwgsenJDyFCuL6EegMWXeeSZGI0=.3c3c2250-2ff9-44e1-8647-c23bf643a14b@github.com>
Message-ID: <xx2oFpEbx5Uzl52izApRKClHEz_bUZ5AkDq4k-ZG_aY=.4b19d4d4-662b-467f-8779-c12e32a6a087@github.com>

On Mon, 23 Feb 2026 01:46:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?
>> 
>> The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.
>> 
>> When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.
>> 
>> When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.
>> 
>> Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `Outp...
>
> 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 11 additional commits since the last revision:
> 
>  - merge latest from master branch
>  - Daniel's review - recheck while holding the lock
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - add comment
>  - copyright years
>  - alternate fix
>  - rename test
>  - 8362268: NPE thrown from SASL GSSAPI impl when  TLS is  used with QOP auth-int against Active Directory
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f999ed16...fa582f62

The fix looks good to me. And the writeup for the root-cause and the code-flow is very good, thank you!

-------------

Marked as reviewed by aefimov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29638#pullrequestreview-3848412077

From duke at openjdk.org  Tue Feb 24 15:03:46 2026
From: duke at openjdk.org (Michael Osipov)
Date: Tue, 24 Feb 2026 15:03:46 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v5]
In-Reply-To: <39nXLnFR2Kl257ljgwgsenJDyFCuL6EegMWXeeSZGI0=.3c3c2250-2ff9-44e1-8647-c23bf643a14b@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
 <39nXLnFR2Kl257ljgwgsenJDyFCuL6EegMWXeeSZGI0=.3c3c2250-2ff9-44e1-8647-c23bf643a14b@github.com>
Message-ID: <C2rKLscFsqkd3D2KGEwCBO0hNgD_8kbqhLF9Jqd0GE0=.96d9048a-20dd-4599-8145-996cc1c3657d@github.com>

On Mon, 23 Feb 2026 01:46:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?
>> 
>> The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.
>> 
>> When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.
>> 
>> When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.
>> 
>> Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `Outp...
>
> 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 11 additional commits since the last revision:
> 
>  - merge latest from master branch
>  - Daniel's review - recheck while holding the lock
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - add comment
>  - copyright years
>  - alternate fix
>  - rename test
>  - 8362268: NPE thrown from SASL GSSAPI impl when  TLS is  used with QOP auth-int against Active Directory
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/0f39a0b7...fa582f62

Will this be backported to older LTS versions?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29638#issuecomment-3952658852

From jpai at openjdk.org  Tue Feb 24 15:26:41 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 24 Feb 2026 15:26:41 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v5]
In-Reply-To: <39nXLnFR2Kl257ljgwgsenJDyFCuL6EegMWXeeSZGI0=.3c3c2250-2ff9-44e1-8647-c23bf643a14b@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
 <39nXLnFR2Kl257ljgwgsenJDyFCuL6EegMWXeeSZGI0=.3c3c2250-2ff9-44e1-8647-c23bf643a14b@github.com>
Message-ID: <Q6Id8PZpd2NY9uH1BaSU-h-XPNKl5IQUfUqHHE8Q_P8=.e4278613-7896-495f-802b-82e7c5975116@github.com>

On Mon, 23 Feb 2026 01:46:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?
>> 
>> The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.
>> 
>> When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.
>> 
>> When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.
>> 
>> Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `Outp...
>
> 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 11 additional commits since the last revision:
> 
>  - merge latest from master branch
>  - Daniel's review - recheck while holding the lock
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - add comment
>  - copyright years
>  - alternate fix
>  - rename test
>  - 8362268: NPE thrown from SASL GSSAPI impl when  TLS is  used with QOP auth-int against Active Directory
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/3d37fbcc...fa582f62

Hello Michael,

> Will this be backported to older LTS versions?

The project leads of each of the jdk-update projects make that decision https://openjdk.org/projects/jdk-updates/. Typically for bug fixes like these, the general suggestion is that the backport should only be done after the fix in mainline has seen a few months of usage once the mainline version is released. That allows any unforeseen issues to be noticed in mainline before it makes it into (more stable) update releases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29638#issuecomment-3952904333

From eirbjo at gmail.com  Tue Feb 24 15:50:48 2026
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Tue, 24 Feb 2026 16:50:48 +0100
Subject: [External] : Re: RFD: ArrayDeque bulk adds and lambda
In-Reply-To: <SJ2PR10MB766946AA5F069D6178FBC5A4A277A@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CA+pBWhuBF0gJVLnVvCDsAgoPMDTDVoVJ4mAG366PHAsiuX+59g@mail.gmail.com>
 <CA+pBWhvCxgKqtFi_H9BuB4X7=V6exkaBS=KCdba-4vUoR9xOaQ@mail.gmail.com>
 <SJ2PR10MB766946AA5F069D6178FBC5A4A277A@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <CA+pBWhsMZyJsDnGrT1OHd7xKSW1weck8N8OUFmjXK--jnbR3zg@mail.gmail.com>

On Mon, Feb 23, 2026 at 5:02?PM Chen Liang <chen.l.liang at oracle.com> wrote:

> But given that collections are used in early bootstrap in general, I think
> being bootstrap-proof might be a good idea.
>

Good, seems replacing this with a simple loop may be worthwhile to bring it
in alignment with ArrayList which does not invoke lambdas.

See PR https://github.com/openjdk/jdk/pull/29894 for this simple
replacement.

Thanks,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260224/cbf1d990/attachment.htm>

From eirbjo at openjdk.org  Tue Feb 24 15:53:13 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 24 Feb 2026 15:53:13 GMT
Subject: RFR: 8378580: Make ArrayDeque bulk add methods bootstrap-proof
Message-ID: <1kb6CFkmXak276xjDMUt-npvgMmmawwO99gdynhy2kI=.9ff74f03-a7a5-4d8d-a3f0-1ea40004f8fa@github.com>

Please review this small change to avoid loading lambda machinery in `ArrayDeque.addAll` and `ArrayDeque(Collection)`.

Core collections like these may be useful in early bootstrap where we want to avoid eager loading of lambda machinery.  JDK-8375580 recently showed one example where `URLClassPath` was avoiding these bulk-adding methods exactly to avoid triggering lambdas.

This PR replaces the use of `Collection.forEach` with a plain old for loop.

This was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2026-February/159362.html

Cleanup, low risk enhancement, `noreg-cleanup`.

-------------

Commit messages:
 - Use simple loop instead of lambda in ArrayDeque bulk adds

Changes: https://git.openjdk.org/jdk/pull/29894/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29894&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378580
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29894/head:pull/29894

PR: https://git.openjdk.org/jdk/pull/29894

From jbhateja at openjdk.org  Tue Feb 24 17:26:22 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 24 Feb 2026 17:26:22 GMT
Subject: RFR: 8377438: [VectorAPI] Add new carrier type to LaneType class
 [v3]
In-Reply-To: <UNPXEPP2riZD-ACHcAi4ufkMSTlYAdflswGXxYl8RLc=.2662d8f4-e034-4da2-998a-c43fe78e89f6@github.com>
References: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
 <UNPXEPP2riZD-ACHcAi4ufkMSTlYAdflswGXxYl8RLc=.2662d8f4-e034-4da2-998a-c43fe78e89f6@github.com>
Message-ID: <xUWOOCF2mMZc6UJ2B-xdB5i9nQB0X5ur87kPKURu0Kg=.d2e86a82-0b26-4f2d-a59e-9693a945c7c3@github.com>

On Tue, 24 Feb 2026 05:06:12 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
>> 
>> With Float16 we need to differentiate b/w vector lane element type and carrier type. while element type corresponds to exact type of lane i.e. Float16.class, carrier type corresponds to the storage type required to propagate IEEE 754 float16 values to inline expander.
>> 
>> Patch adds a new carrier type to existing LaneType structure and use it for following purpose.
>>  - To compute preferred shape of vector.
>>  - To allocate vector backing storage during dummy vector and iota array creation.
>>  - Sanity checking to ensure vector lane type is a primitive type in inline expander.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolution

Hi @PaulSandoz , Your comment have been addressed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29629#issuecomment-3953604584

From duke at openjdk.org  Tue Feb 24 17:28:25 2026
From: duke at openjdk.org (ExE Boss)
Date: Tue, 24 Feb 2026 17:28:25 GMT
Subject: RFR: 8378414: Add methods to test for representation equivalence
 [v2]
In-Reply-To: <e3S7wSs81cJazsd86bVIUdKJWbvIUP-nE3SDpVNj6Yg=.bb916487-0c08-4ba1-988b-52e12088c6e0@github.com>
References: <mioOgE5dVvyj1CgG7BNDyixbbwIOyRFqKs9s7-vgqCE=.825997f5-c363-4a94-a45b-499dfa255420@github.com>
 <e3S7wSs81cJazsd86bVIUdKJWbvIUP-nE3SDpVNj6Yg=.bb916487-0c08-4ba1-988b-52e12088c6e0@github.com>
Message-ID: <f4qzg5MLZnkQrAwGG6NOGZr6vF0XskzbW4MSPubYgSk=.6912d97e-2696-4aa6-9a79-dc4bbe8fdf96@github.com>

On Mon, 23 Feb 2026 17:56:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Floating-point values have a notion of representation equivalence distinct from the comparison done by ==. This notion of equivalence could have a method to provide the predicate directly, rather than relying on one of several expressions listed in the documentation ([JDK-8295391](https://bugs.openjdk.org/browse/JDK-8295391)).
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback; add build tags.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 1075:

> 1073:      */
> 1074:     public static boolean equivalent(Float16 f1, Float16 f2) {
> 1075:         return Float.equivalent(f1.floatValue(), f2.floatValue());

Maybe?use `Float16.float16ToShortBits(?)` instead, matching?`Float16?::equals(?)`, which?avoids the?`Float16` to?`float`?conversion:
https://github.com/openjdk/jdk/blob/49f14eb9fca155319d5475019715189e9f65dffd/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java#L936-L939

Suggestion:

        return float16ToShortBits(f1) == float16ToShortBits(f2);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29870#discussion_r2848529085

From bperez at openjdk.org  Tue Feb 24 18:10:51 2026
From: bperez at openjdk.org (Ben Perez)
Date: Tue, 24 Feb 2026 18:10:51 GMT
Subject: RFR: 8368841: X25519 implementation differs from the specification
 in RFC 7748 [v3]
In-Reply-To: <2N1k3PlPpZGwMY3p6pSP8o1ZnH0VDOmIMGSFs59smPY=.00d8c421-57d0-40c3-b31e-8b69f976c5d0@github.com>
References: <c_dJLNLDU_f3_R5l-IX8FccJW6lAy6-TdzFlM_oEIJ0=.da3b9092-e3e7-4e34-84dd-178c94833a71@github.com>
 <WcR-ShFFnhzlo9uJ0w8MVM0p67ipMeMdTcOLF4WbzWw=.951c61e5-3b19-4c4e-8c91-77a5c450dc15@github.com>
 <2N1k3PlPpZGwMY3p6pSP8o1ZnH0VDOmIMGSFs59smPY=.00d8c421-57d0-40c3-b31e-8b69f976c5d0@github.com>
Message-ID: <UVj-sVmTNK1io_eOVsv3IuwOnULAuIab7zX4oOILRRc=.48c8ee68-c6de-451a-b563-a07f4d2947e7@github.com>

On Tue, 24 Feb 2026 02:10:42 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed parsing functionality in TestXDH that manually clears MSB
>
> test/jdk/sun/security/ec/xec/TestXDH.java line 369:
> 
>> 367:         PrivateKey privateKey = kf.generatePrivate(privateSpec);
>> 368:         KeySpec publicSpec = new XECPublicKeySpec(paramSpec,
>> 369:             Convert.hexStringToBigInteger(b_pub));
> 
> Can this be replaced with `new BigInteger(b_pub, 16)`?  If so, the Convert.java change isn't needed.

That would work. It does seem like this is the only place `hexStringToBigInteger` is used though, so keeping that functionality might be confusing or unnecessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29750#discussion_r2848776210

From ascarpino at openjdk.org  Tue Feb 24 18:19:34 2026
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 24 Feb 2026 18:19:34 GMT
Subject: RFR: 8368841: X25519 implementation differs from the specification
 in RFC 7748 [v3]
In-Reply-To: <UVj-sVmTNK1io_eOVsv3IuwOnULAuIab7zX4oOILRRc=.48c8ee68-c6de-451a-b563-a07f4d2947e7@github.com>
References: <c_dJLNLDU_f3_R5l-IX8FccJW6lAy6-TdzFlM_oEIJ0=.da3b9092-e3e7-4e34-84dd-178c94833a71@github.com>
 <WcR-ShFFnhzlo9uJ0w8MVM0p67ipMeMdTcOLF4WbzWw=.951c61e5-3b19-4c4e-8c91-77a5c450dc15@github.com>
 <2N1k3PlPpZGwMY3p6pSP8o1ZnH0VDOmIMGSFs59smPY=.00d8c421-57d0-40c3-b31e-8b69f976c5d0@github.com>
 <UVj-sVmTNK1io_eOVsv3IuwOnULAuIab7zX4oOILRRc=.48c8ee68-c6de-451a-b563-a07f4d2947e7@github.com>
Message-ID: <9gYUXpvxlyFbf8IwpbTX4z1e_KnQfneHrwASdR7-CSA=.45659a47-7ff2-40c4-9990-1566ac2fb834@github.com>

On Tue, 24 Feb 2026 18:07:26 GMT, Ben Perez <bperez at openjdk.org> wrote:

>> test/jdk/sun/security/ec/xec/TestXDH.java line 369:
>> 
>>> 367:         PrivateKey privateKey = kf.generatePrivate(privateSpec);
>>> 368:         KeySpec publicSpec = new XECPublicKeySpec(paramSpec,
>>> 369:             Convert.hexStringToBigInteger(b_pub));
>> 
>> Can this be replaced with `new BigInteger(b_pub, 16)`?  If so, the Convert.java change isn't needed.
>
> That would work. It does seem like this is the only place `hexStringToBigInteger` is used though, so keeping that functionality might be confusing or unnecessary.

You may consider removing the method from `Convert.java`.  This appears to be the only caller.  That means Convert usage can be cleaned up from `@build` and `import` on this test too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29750#discussion_r2848811608

From duke at openjdk.org  Tue Feb 24 18:48:09 2026
From: duke at openjdk.org (Jason Mehrens)
Date: Tue, 24 Feb 2026 18:48:09 GMT
Subject: RFR: 8378580: Make ArrayDeque bulk add methods bootstrap-proof
In-Reply-To: <1kb6CFkmXak276xjDMUt-npvgMmmawwO99gdynhy2kI=.9ff74f03-a7a5-4d8d-a3f0-1ea40004f8fa@github.com>
References: <1kb6CFkmXak276xjDMUt-npvgMmmawwO99gdynhy2kI=.9ff74f03-a7a5-4d8d-a3f0-1ea40004f8fa@github.com>
Message-ID: <2CLKAYHzZCo0RhZKcLsVNzOPY8mH4tjwb3pJ0TpP4hY=.380fa513-e8f7-4c10-b472-4cd20e21e93c@github.com>

On Tue, 24 Feb 2026 15:23:18 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this small change to avoid loading lambda machinery in `ArrayDeque.addAll` and `ArrayDeque(Collection)`.
> 
> Core collections like these may be useful in early bootstrap where we want to avoid eager loading of lambda machinery.  JDK-8375580 recently showed one example where `URLClassPath` was avoiding these bulk-adding methods exactly to avoid triggering lambdas.
> 
> This PR replaces the use of `Collection.forEach` with a plain old for loop.
> 
> This was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2026-February/159362.html
> 
> Cleanup, low risk enhancement, `noreg-cleanup`.

If the given collection 'c' is Collections.synchronziedXXX, then simple loop doesn't lock correctly. ForEach and toArray work correctly with that wrapper class.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29894#issuecomment-3954022125

From eirbjo at openjdk.org  Tue Feb 24 20:44:36 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 24 Feb 2026 20:44:36 GMT
Subject: RFR: 8378580: Make ArrayDeque bulk add methods bootstrap-proof
In-Reply-To: <2CLKAYHzZCo0RhZKcLsVNzOPY8mH4tjwb3pJ0TpP4hY=.380fa513-e8f7-4c10-b472-4cd20e21e93c@github.com>
References: <1kb6CFkmXak276xjDMUt-npvgMmmawwO99gdynhy2kI=.9ff74f03-a7a5-4d8d-a3f0-1ea40004f8fa@github.com>
 <2CLKAYHzZCo0RhZKcLsVNzOPY8mH4tjwb3pJ0TpP4hY=.380fa513-e8f7-4c10-b472-4cd20e21e93c@github.com>
Message-ID: <ppBZZoV2PBXB340SSrsD3RGWz1DPqcgtO0ERqFDIgx8=.24614c35-0c35-4827-9477-071f2928cffd@github.com>

On Tue, 24 Feb 2026 18:45:29 GMT, Jason Mehrens <duke at openjdk.org> wrote:

> If the given collection 'c' is Collections.synchronziedXXX, then simple loop doesn't lock correctly. ForEach and toArray work correctly with that wrapper class.

The synchronized wrapper collections clearly specify that the user is responsible for synchronizing any iteration or stream operations on those collections. Then, who is the user in this case? The one creating and passing synchronzed collections around, or do we include any collection in the collections framework?

To avoid further headscratching about this, perhaps a good old anonymous class would be less risky?


c.forEach(new Consumer<E>() {
    @Override
    public void accept(E e) {
        addLast(e);
    }
});

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29894#issuecomment-3954620028

From syan at openjdk.org  Wed Feb 25 11:01:40 2026
From: syan at openjdk.org (SendaoYan)
Date: Wed, 25 Feb 2026 11:01:40 GMT
Subject: RFR: 8378111: Migrate java/util/jar tests to JUnit [v3]
In-Reply-To: <byA5m9O6m0xMz0JVHfA6coX5fePS0EbZNHTeSfnx7kE=.dfdbe356-474c-45f4-8d2c-ac2c2cce8cfc@github.com>
References: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
 <byA5m9O6m0xMz0JVHfA6coX5fePS0EbZNHTeSfnx7kE=.dfdbe356-474c-45f4-8d2c-ac2c2cce8cfc@github.com>
Message-ID: <l8LrnqR8DzOC_3hwGEl44Xvu9-PDhw-eGnTvYDlZkEA=.ac98b22f-e5e2-42f9-a673-c91fcfd35923@github.com>

On Mon, 23 Feb 2026 22:56:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR migrates the java/util/jar tests to use _JUnit_.
>> 
>> https://github.com/openjdk/jdk/commit/afe0aeee746bccbbe4bc6c9a8cd2302228ecc2f6 includes changes for _testNG_ based tests.
>> https://github.com/openjdk/jdk/commit/c5a7f75840f96fa77ec3ed7faa713990adb84de6 includes changes for `main` based tests.
>> 
>> Before: Framework-based tests: 125 = 125 TestNG + 0 JUnit.
>> After: Framework-based tests: 174 = 0 TestNG + 174 JUnit
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get rid of inheritance + zip -> ZIP

test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarHttpProperties.java line 72:

> 70: 
> 71:     @BeforeAll
> 72:     public void initialize() throws Exception {

Maybe we should add `static` modifier for @BeforeAll and @AfterAll method

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2851500968

From eirbjo at openjdk.org  Wed Feb 25 11:04:33 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 25 Feb 2026 11:04:33 GMT
Subject: RFR: 8378580: Make ArrayDeque bulk add methods bootstrap-proof
 [v2]
In-Reply-To: <1kb6CFkmXak276xjDMUt-npvgMmmawwO99gdynhy2kI=.9ff74f03-a7a5-4d8d-a3f0-1ea40004f8fa@github.com>
References: <1kb6CFkmXak276xjDMUt-npvgMmmawwO99gdynhy2kI=.9ff74f03-a7a5-4d8d-a3f0-1ea40004f8fa@github.com>
Message-ID: <JL56Da3muL654I4b-UOddY0gajSaSx3KfRhR4VdGrDo=.a1204fc9-4a73-4258-bcbb-b653bd0fd75a@github.com>

> Please review this small change to avoid loading lambda machinery in `ArrayDeque.addAll` and `ArrayDeque(Collection)`.
> 
> Core collections like these may be useful in early bootstrap where we want to avoid eager loading of lambda machinery.  JDK-8375580 recently showed one example where `URLClassPath` was avoiding these bulk-adding methods exactly to avoid triggering lambdas.
> 
> This PR replaces the use of `Collection.forEach` with a plain old for loop.
> 
> This was initially discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2026-February/159362.html
> 
> Cleanup, low risk enhancement, `noreg-cleanup`.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Use anonymous class to avoid external/synchronized iteration of passed collection

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29894/files
  - new: https://git.openjdk.org/jdk/pull/29894/files/aa97fb6b..d8d6296f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29894&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29894&range=00-01

  Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/29894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29894/head:pull/29894

PR: https://git.openjdk.org/jdk/pull/29894

From duke at openjdk.org  Wed Feb 25 11:04:36 2026
From: duke at openjdk.org (Jason Mehrens)
Date: Wed, 25 Feb 2026 11:04:36 GMT
Subject: RFR: 8378580: Make ArrayDeque bulk add methods bootstrap-proof
In-Reply-To: <ppBZZoV2PBXB340SSrsD3RGWz1DPqcgtO0ERqFDIgx8=.24614c35-0c35-4827-9477-071f2928cffd@github.com>
References: <1kb6CFkmXak276xjDMUt-npvgMmmawwO99gdynhy2kI=.9ff74f03-a7a5-4d8d-a3f0-1ea40004f8fa@github.com>
 <2CLKAYHzZCo0RhZKcLsVNzOPY8mH4tjwb3pJ0TpP4hY=.380fa513-e8f7-4c10-b472-4cd20e21e93c@github.com>
 <ppBZZoV2PBXB340SSrsD3RGWz1DPqcgtO0ERqFDIgx8=.24614c35-0c35-4827-9477-071f2928cffd@github.com>
Message-ID: <IQCYbKHwcz6UNGhMCiqeKGAx1CN_Jukvv7aMs4GP7eU=.f0be2821-692f-48a2-b435-e1aeb64f9340@github.com>

On Tue, 24 Feb 2026 20:42:03 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> The synchronized wrapper collections clearly specify that the user is responsible for synchronizing any iteration or stream operations on those collections. Then, who is the user in this case? The one creating and passing synchronzed collections around, or do we include any collection in the collections framework?

Using iterator to perform copying has a history of problems. See:
https://bugs.openjdk.org/browse/JDK-6347106 and linked tickets.

My advice is to not undo that ticket.

> 
> To avoid further headscratching about this, perhaps a good old anonymous class would be less risky?
> 
> ```java
> c.forEach(new Consumer<E>() {
>     @Override
>     public void accept(E e) {
>         addLast(e);
>     }
> });
> ```

Yes. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29894#issuecomment-3955982977

From ysuenaga at openjdk.org  Wed Feb 25 11:05:50 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 25 Feb 2026 11:05:50 GMT
Subject: RFR: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to
 intrinsify [v4]
In-Reply-To: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
References: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
Message-ID: <3Cj-8Ae4bGQs6soTjbPTNeOK1p6owLuGAVk72PySAZk=.a1527cf4-bf4d-4e02-89aa-81a578ca2dbb@github.com>

> I ran following code with `-Djdk.incubator.vector.DEBUG=true`, however it was not intrinsified.
> 
> 
>   public static void cos(){
>     var rand = new Random();
>     for(int i = 0; i < 1_000_000; i++){
>       var vec = DoubleVector.fromArray(DoubleVector.SPECIES_256, rand.doubles().limit(4).toArray(), 0);
> 
>       vec.lanewise(VectorOperators.COS);
>     }
>   }
> 
> 
> I knew `__jsvml_cos4_ha_l9()` in libjsvml.so should be called in this case (via vector debug log), but it was not hitted even though I set breakpoint in it.
> 
> `LaneType` has been introduced in [JDK-8376187](https://bugs.openjdk.org/browse/JDK-8376187), and `LibraryCallKit::inline_vector_call()` was updated to handle lane type rather than class of element type. However `VectorMathLibrary` wasn't modified.
> 
> I confirmed `__jsvml_cos4_ha_l9()` is called with this fix, and also all jdk/jdk/incubator/vector jtreg tests passed on Linux AMD64.

Yasumasa Suenaga has updated the pull request incrementally with three additional commits since the last revision:

 - Remove unnecesary file
 - Update testcase
 - Add comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29835/files
  - new: https://git.openjdk.org/jdk/pull/29835/files/dd007253..f7a533bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29835&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29835&range=02-03

  Stats: 125 lines in 3 files changed: 63 ins; 62 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29835.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29835/head:pull/29835

PR: https://git.openjdk.org/jdk/pull/29835

From psandoz at openjdk.org  Wed Feb 25 11:06:03 2026
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 25 Feb 2026 11:06:03 GMT
Subject: RFR: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to
 intrinsify [v3]
In-Reply-To: <2ZETD5VINau9XPTgVsTq6Z7aJovNUKrKhVuA3AeKsyM=.051f07e5-215f-4a4d-8102-095649760085@github.com>
References: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
 <2ZETD5VINau9XPTgVsTq6Z7aJovNUKrKhVuA3AeKsyM=.051f07e5-215f-4a4d-8102-095649760085@github.com>
Message-ID: <6h87vaAV6Yz-E_Fy9t2UAk6Vm2ZgFxIU0ZiTf2w-Xfg=.a503ed9b-a1e5-42b6-94b5-23aff0c3892c@github.com>

On Sat, 21 Feb 2026 07:55:02 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I ran following code with `-Djdk.incubator.vector.DEBUG=true`, however it was not intrinsified.
>> 
>> 
>>   public static void cos(){
>>     var rand = new Random();
>>     for(int i = 0; i < 1_000_000; i++){
>>       var vec = DoubleVector.fromArray(DoubleVector.SPECIES_256, rand.doubles().limit(4).toArray(), 0);
>> 
>>       vec.lanewise(VectorOperators.COS);
>>     }
>>   }
>> 
>> 
>> I knew `__jsvml_cos4_ha_l9()` in libjsvml.so should be called in this case (via vector debug log), but it was not hitted even though I set breakpoint in it.
>> 
>> `LaneType` has been introduced in [JDK-8376187](https://bugs.openjdk.org/browse/JDK-8376187), and `LibraryCallKit::inline_vector_call()` was updated to handle lane type rather than class of element type. However `VectorMathLibrary` wasn't modified.
>> 
>> I confirmed `__jsvml_cos4_ha_l9()` is called with this fix, and also all jdk/jdk/incubator/vector jtreg tests passed on Linux AMD64.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

Can you move the test to `test/hotspot/jtreg/compiler/vectorapi`? Also I believe we can expand to include coverage on neon/sve (which will use the SLEEF) library.

test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java line 1481:

> 1479:     }
> 1480: 
> 1481:     public static final String CALL_LEAF_VECTOR = PREFIX + "CALL_LEAF_VECTOR" + POSTFIX;

Recommend you add a comment above say something like:

// Can only be used if libjsvml or libsleef is available

-------------

PR Review: https://git.openjdk.org/jdk/pull/29835#pullrequestreview-3851219488
PR Review Comment: https://git.openjdk.org/jdk/pull/29835#discussion_r2850204608

From alanb at openjdk.org  Wed Feb 25 11:05:33 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 25 Feb 2026 11:05:33 GMT
Subject: RFR: 8378268: Thread.join can wait on Thread,
 allows joinNanos to be removed
Message-ID: <-ckkcXUkmMzpwb4p_Bc6rx_e25gD-5OhGuG6Uw8JYwg=.d8d7e10c-2218-41af-8167-9446684ace09@github.com>

Thread.join was historically implemented with a loop of Object.wait conditioned on isAlive. We couldn't for this virtual threads because it would pin a virtual thread invoking join to it carrier.  Now that Object.wait preempts, it means the special implementation of join for virtual threads can be removed. Where possible, the notifyAll is elided as it adds to the cost of termination.

The implNote of the join methods is restored (this is implNote text, not spec, so no CSR required).

-------------

Commit messages:
 - Avoid notifyAll if no join
 - Merge branch 'master' into JDK-8378268
 - Merge branch 'master' into JDK-8378268
 - Remove joinNanos

Changes: https://git.openjdk.org/jdk/pull/29839/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29839&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378268
  Stats: 85 lines in 2 files changed: 10 ins; 63 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/29839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29839/head:pull/29839

PR: https://git.openjdk.org/jdk/pull/29839

From psandoz at openjdk.org  Wed Feb 25 11:06:05 2026
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 25 Feb 2026 11:06:05 GMT
Subject: RFR: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to
 intrinsify [v3]
In-Reply-To: <6h87vaAV6Yz-E_Fy9t2UAk6Vm2ZgFxIU0ZiTf2w-Xfg=.a503ed9b-a1e5-42b6-94b5-23aff0c3892c@github.com>
References: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
 <2ZETD5VINau9XPTgVsTq6Z7aJovNUKrKhVuA3AeKsyM=.051f07e5-215f-4a4d-8102-095649760085@github.com>
 <6h87vaAV6Yz-E_Fy9t2UAk6Vm2ZgFxIU0ZiTf2w-Xfg=.a503ed9b-a1e5-42b6-94b5-23aff0c3892c@github.com>
Message-ID: <KH63JseiRclhEIfFIzKLvjgmWAp7hOQwVk9vK5J7yqA=.100777ae-017a-4957-bf71-657470dd2cb6@github.com>

On Wed, 25 Feb 2026 00:34:12 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test
>
> Can you move the test to `test/hotspot/jtreg/compiler/vectorapi`? Also I believe we can expand to include coverage on neon/sve (which will use the SLEEF) library.

> @PaulSandoz I found the test which uses IR Test Framework. So I added the test with it. It works on my Linux AMD64. Is this what you intended?

Yes, very good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29835#issuecomment-3955590086

From psandoz at openjdk.org  Wed Feb 25 11:06:12 2026
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 25 Feb 2026 11:06:12 GMT
Subject: RFR: 8377438: [VectorAPI] Add new carrier type to LaneType class
 [v3]
In-Reply-To: <UNPXEPP2riZD-ACHcAi4ufkMSTlYAdflswGXxYl8RLc=.2662d8f4-e034-4da2-998a-c43fe78e89f6@github.com>
References: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
 <UNPXEPP2riZD-ACHcAi4ufkMSTlYAdflswGXxYl8RLc=.2662d8f4-e034-4da2-998a-c43fe78e89f6@github.com>
Message-ID: <cxWM_VZx6dC7aaymt6Tb3vTUs8XK-VoDDbRkE9Th0fI=.c3c55e51-13b7-4736-ba32-96be4c20a272@github.com>

On Tue, 24 Feb 2026 05:06:12 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
>> 
>> With Float16 we need to differentiate b/w vector lane element type and carrier type. while element type corresponds to exact type of lane i.e. Float16.class, carrier type corresponds to the storage type required to propagate IEEE 754 float16 values to inline expander.
>> 
>> Patch adds a new carrier type to existing LaneType structure and use it for following purpose.
>>  - To compute preferred shape of vector.
>>  - To allocate vector backing storage during dummy vector and iota array creation.
>>  - Sanity checking to ensure vector lane type is a primitive type in inline expander.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolution

Looks good. We shall run it though tier 1 to 3 tests. Needs another HotSpot reviewer.

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29629#pullrequestreview-3851228834

From vklang at openjdk.org  Wed Feb 25 11:05:36 2026
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 25 Feb 2026 11:05:36 GMT
Subject: RFR: 8378268: Thread.join can wait on Thread,
 allows joinNanos to be removed
In-Reply-To: <-ckkcXUkmMzpwb4p_Bc6rx_e25gD-5OhGuG6Uw8JYwg=.d8d7e10c-2218-41af-8167-9446684ace09@github.com>
References: <-ckkcXUkmMzpwb4p_Bc6rx_e25gD-5OhGuG6Uw8JYwg=.d8d7e10c-2218-41af-8167-9446684ace09@github.com>
Message-ID: <v4myKGUfelMU1NuZXqZ4iPYubFVEjp0h0MFBVH5kf20=.a7939689-b98e-4f34-8ee5-3b239fa72206@github.com>

On Fri, 20 Feb 2026 09:26:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.join was historically implemented with a loop of Object.wait conditioned on isAlive. We couldn't for this virtual threads because it would pin a virtual thread invoking join to it carrier.  Now that Object.wait preempts, it means the special implementation of join for virtual threads can be removed. Where possible, the notifyAll is elided as it adds to the cost of termination.
> 
> The implNote of the join methods is restored (this is implNote text, not spec, so no CSR required).

Great reduction in complexity, Alan ?

src/java.base/share/classes/java/lang/Thread.java line 1909:

> 1907:         // ensure there is a notifyAll to wake up waiters when this thread terminates
> 1908:         if (this instanceof VirtualThread vthread) {
> 1909:             vthread.beforeJoin();

If deemed valuable, we might be able to do something more sophisticated as the proposed solution will trigger notifyAll even if all joiners bailed out due to timeout.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29839#issuecomment-3941069215
PR Review Comment: https://git.openjdk.org/jdk/pull/29839#discussion_r2837890985

From alanb at openjdk.org  Wed Feb 25 11:05:41 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 25 Feb 2026 11:05:41 GMT
Subject: RFR: 8378268: Thread.join can wait on Thread,
 allows joinNanos to be removed
In-Reply-To: <v4myKGUfelMU1NuZXqZ4iPYubFVEjp0h0MFBVH5kf20=.a7939689-b98e-4f34-8ee5-3b239fa72206@github.com>
References: <-ckkcXUkmMzpwb4p_Bc6rx_e25gD-5OhGuG6Uw8JYwg=.d8d7e10c-2218-41af-8167-9446684ace09@github.com>
 <v4myKGUfelMU1NuZXqZ4iPYubFVEjp0h0MFBVH5kf20=.a7939689-b98e-4f34-8ee5-3b239fa72206@github.com>
Message-ID: <vHBgmkYJdnN49PJdFgYsPaO2LdXZC9843cLsGYxT02E=.87c35692-8bb0-40c6-aba1-e77b86d99efc@github.com>

On Sun, 22 Feb 2026 14:07:49 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Thread.join was historically implemented with a loop of Object.wait conditioned on isAlive. We couldn't for this virtual threads because it would pin a virtual thread invoking join to it carrier.  Now that Object.wait preempts, it means the special implementation of join for virtual threads can be removed. Where possible, the notifyAll is elided as it adds to the cost of termination.
>> 
>> The implNote of the join methods is restored (this is implNote text, not spec, so no CSR required).
>
> src/java.base/share/classes/java/lang/Thread.java line 1909:
> 
>> 1907:         // ensure there is a notifyAll to wake up waiters when this thread terminates
>> 1908:         if (this instanceof VirtualThread vthread) {
>> 1909:             vthread.beforeJoin();
> 
> If deemed valuable, we might be able to do something more sophisticated as the proposed solution will trigger notifyAll even if all joiners bailed out due to timeout.

I think it's best to keep it as simple as possible. It's not wrong to notifyAll if there are no waiters so okay if a joiner bails. My concern with doing anything more sophisticated is that it would add counters or other book keeping. It's enough to just avoid the notifyAll when the thread terminates before anyone calls join.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29839#discussion_r2845582926

From ysuenaga at openjdk.org  Wed Feb 25 11:06:07 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 25 Feb 2026 11:06:07 GMT
Subject: RFR: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to
 intrinsify [v3]
In-Reply-To: <KH63JseiRclhEIfFIzKLvjgmWAp7hOQwVk9vK5J7yqA=.100777ae-017a-4957-bf71-657470dd2cb6@github.com>
References: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
 <2ZETD5VINau9XPTgVsTq6Z7aJovNUKrKhVuA3AeKsyM=.051f07e5-215f-4a4d-8102-095649760085@github.com>
 <6h87vaAV6Yz-E_Fy9t2UAk6Vm2ZgFxIU0ZiTf2w-Xfg=.a503ed9b-a1e5-42b6-94b5-23aff0c3892c@github.com>
 <KH63JseiRclhEIfFIzKLvjgmWAp7hOQwVk9vK5J7yqA=.100777ae-017a-4957-bf71-657470dd2cb6@github.com>
Message-ID: <TVrTpdo6WGrxdjxfUzm-4aYYfrXy2sgZ4Q_7h1Hgga8=.1ee00059-b188-4d7a-812d-7e3badc9bd55@github.com>

On Wed, 25 Feb 2026 00:34:17 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Can you move the test to `test/hotspot/jtreg/compiler/vectorapi`? Also I believe we can expand to include coverage on neon/sve (which will use the SLEEF) library.
>
>> @PaulSandoz I found the test which uses IR Test Framework. So I added the test with it. It works on my Linux AMD64. Is this what you intended?
> 
> Yes, very good.

@PaulSandoz I added a comment and updated testcase to run AArch64. Could you review?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29835#issuecomment-3957043419

From vklang at openjdk.org  Wed Feb 25 11:05:44 2026
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 25 Feb 2026 11:05:44 GMT
Subject: RFR: 8378268: Thread.join can wait on Thread,
 allows joinNanos to be removed
In-Reply-To: <vHBgmkYJdnN49PJdFgYsPaO2LdXZC9843cLsGYxT02E=.87c35692-8bb0-40c6-aba1-e77b86d99efc@github.com>
References: <-ckkcXUkmMzpwb4p_Bc6rx_e25gD-5OhGuG6Uw8JYwg=.d8d7e10c-2218-41af-8167-9446684ace09@github.com>
 <v4myKGUfelMU1NuZXqZ4iPYubFVEjp0h0MFBVH5kf20=.a7939689-b98e-4f34-8ee5-3b239fa72206@github.com>
 <vHBgmkYJdnN49PJdFgYsPaO2LdXZC9843cLsGYxT02E=.87c35692-8bb0-40c6-aba1-e77b86d99efc@github.com>
Message-ID: <cw9B6R6i1ReMw3ePFbqjedVgsRiGVZwIr7qni7yod3I=.e198d1d8-29c2-43f5-9723-832a74130c00@github.com>

On Tue, 24 Feb 2026 09:26:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Thread.java line 1909:
>> 
>>> 1907:         // ensure there is a notifyAll to wake up waiters when this thread terminates
>>> 1908:         if (this instanceof VirtualThread vthread) {
>>> 1909:             vthread.beforeJoin();
>> 
>> If deemed valuable, we might be able to do something more sophisticated as the proposed solution will trigger notifyAll even if all joiners bailed out due to timeout.
>
> I think it's best to keep it as simple as possible. It's not wrong to notifyAll if there are no waiters so okay if a joiner bails. My concern with doing anything more sophisticated is that it would add counters or other book keeping. It's enough to just avoid the notifyAll when the thread terminates before anyone calls join.

I 100% agree.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29839#discussion_r2846268901

From jbhateja at openjdk.org  Wed Feb 25 11:06:16 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 25 Feb 2026 11:06:16 GMT
Subject: RFR: 8377438: [VectorAPI] Add new carrier type to LaneType class
 [v3]
In-Reply-To: <UNPXEPP2riZD-ACHcAi4ufkMSTlYAdflswGXxYl8RLc=.2662d8f4-e034-4da2-998a-c43fe78e89f6@github.com>
References: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
 <UNPXEPP2riZD-ACHcAi4ufkMSTlYAdflswGXxYl8RLc=.2662d8f4-e034-4da2-998a-c43fe78e89f6@github.com>
Message-ID: <DeKYvM1kzUm4lGxsYQF8EgoJSVUk-24do3-QmvoCXyE=.cb028b49-3bcf-43f6-bbb2-79c153d04001@github.com>

On Tue, 24 Feb 2026 05:06:12 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
>> 
>> With Float16 we need to differentiate b/w vector lane element type and carrier type. while element type corresponds to exact type of lane i.e. Float16.class, carrier type corresponds to the storage type required to propagate IEEE 754 float16 values to inline expander.
>> 
>> Patch adds a new carrier type to existing LaneType structure and use it for following purpose.
>>  - To compute preferred shape of vector.
>>  - To allocate vector backing storage during dummy vector and iota array creation.
>>  - Sanity checking to ensure vector lane type is a primitive type in inline expander.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolution

Hi @liach ,  There are some minor changes in hotspot code. Please review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29629#issuecomment-3957883114

From mullan at openjdk.org  Wed Feb 25 11:08:35 2026
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 25 Feb 2026 11:08:35 GMT
Subject: RFR: 8364182: Add jcmd VM.security_properties command [v12]
In-Reply-To: <BnVM8xCJjyxW_R-8qx3qa620rNPw63CBm6xHtphbxP4=.80aff2ea-8a45-4fe7-976a-87f65ead42ab@github.com>
References: <gL32zJh7GjJx_gf_50dAPTkZH2_lADOB_qh_qa8K4Lk=.b933b2c9-985b-468d-9e39-aaf94097480c@github.com>
 <AT2ERqnvfTQ0vrwUNr0Csuz9DkT1VcfwTJHlJOvHtOY=.ab98e8f9-ed77-466a-b0a6-b7029d8d648b@github.com>
 <BnVM8xCJjyxW_R-8qx3qa620rNPw63CBm6xHtphbxP4=.80aff2ea-8a45-4fe7-976a-87f65ead42ab@github.com>
Message-ID: <cehU8LD6fuEj_3iVDrIIQqHYJN0bnVIrYUbW0qOSphk=.21f0ec89-16ef-4ef1-b0aa-df0a01a2ea7c@github.com>

On Fri, 20 Feb 2026 11:14:01 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update bugid
>
> LGTM. Thanks for pushing ahead with this.

FYI - I'm fine with @coffeys being the main reviewer for the security team. I don't plan to review it any further but haven't reviewed enough of it to add my name.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3954816146

From asemenyuk at openjdk.org  Wed Feb 25 11:10:00 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 25 Feb 2026 11:10:00 GMT
Subject: RFR: 8374222: jpackage will exit with error if it fails to clean
 the temp directory [v2]
In-Reply-To: <slkcuguuN_dOz_pjLZs_xVDEy0aGeTjk6BiBs5fawzU=.245d6070-5d05-4d4a-a923-414b4cbe515d@github.com>
References: <slkcuguuN_dOz_pjLZs_xVDEy0aGeTjk6BiBs5fawzU=.245d6070-5d05-4d4a-a923-414b4cbe515d@github.com>
Message-ID: <bAt83NpwaaTyBYE6c6LycvZHFkrGm67_OzWt7de5qyg=.7d2dd84a-a523-42e4-b828-da2616684fa0@github.com>

> jpackage will attempt to delete the temp directory a few times. If all attempts fail, it will print remaining files and empty directories (100 entries at most) to the console and continue. It will not exit with an error status as previously, as this is not a critical error.

Alexey Semenyuk 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/29664/files
  - new: https://git.openjdk.org/jdk/pull/29664/files/d2ca4156..7cabdb22

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29664&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29664&range=00-01

  Stats: 6 lines in 2 files changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/29664.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29664/head:pull/29664

PR: https://git.openjdk.org/jdk/pull/29664

From duke at openjdk.org  Wed Feb 25 11:09:57 2026
From: duke at openjdk.org (ExE Boss)
Date: Wed, 25 Feb 2026 11:09:57 GMT
Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document
 its characteristics [v3]
In-Reply-To: <hP7YJKiJ6S-KjpCYNIbTtf_xlagH6uPEJezg6KZJOZg=.3fc734c3-885e-4f43-b3eb-692f504c9bb0@github.com>
References: <a_E82GfueEQWcSqqCG0UUbX7DbSlSygjf7an5e1zA8c=.0a46927d-5ead-4592-babc-36a65fb96536@github.com>
 <c-LUroJnGBEJKp49Z578-SN60WqCNiW-3ga6I0Pw8ZI=.190cf8c9-42bd-4568-b2a0-72fab09ea2f3@github.com>
 <edChsljJWJN36b1kN6GG1C58dfao2fwTcQjqq_8yHjw=.de1db304-f164-48cd-b61d-b29537c1a130@github.com>
 <hP7YJKiJ6S-KjpCYNIbTtf_xlagH6uPEJezg6KZJOZg=.3fc734c3-885e-4f43-b3eb-692f504c9bb0@github.com>
Message-ID: <KosEyN1jgpzGKwxcTZVhUCF_juVM9aBkVrMtx-bET3A=.328c93fc-966e-463a-b6c5-9919ca08dd7a@github.com>

On Tue, 27 Jan 2026 15:45:38 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/EnumSet.java line 524:
>> 
>>> 522:      */
>>> 523:     @Override
>>> 524:     public final Spliterator<E> spliterator() {
>> 
>> Maybe?keep this?method non?`final` so?that?specialised implementations may?be?provided by?`SimpleEnumSet` or?`JumboEnumSet` in?the?future without?needing to?remove the?`final`?modifier.
>> Suggestion:
>> 
>>     public Spliterator<E> spliterator() {
>
> On the contrary, I think adding `final` here serves as a good indicator to anyone possibly wanting to override spliterator() that they need to consider the behavior of the superclass' implementation. AS EnumSet is `sealed` there is no risk to non-jdk code and dropping the `final`-modifier later is trivial.

Changing?`final`ness of?a?public?method on?a?**JDK**?`sealed`?hierarchy still?requires a?**CSR**, since?it?s?considered a?part of?the?**JavaSE API**?specification.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28696#discussion_r2851083060

From almatvee at openjdk.org  Wed Feb 25 11:10:01 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 25 Feb 2026 11:10:01 GMT
Subject: RFR: 8374222: jpackage will exit with error if it fails to clean
 the temp directory [v2]
In-Reply-To: <bAt83NpwaaTyBYE6c6LycvZHFkrGm67_OzWt7de5qyg=.7d2dd84a-a523-42e4-b828-da2616684fa0@github.com>
References: <slkcuguuN_dOz_pjLZs_xVDEy0aGeTjk6BiBs5fawzU=.245d6070-5d05-4d4a-a923-414b4cbe515d@github.com>
 <bAt83NpwaaTyBYE6c6LycvZHFkrGm67_OzWt7de5qyg=.7d2dd84a-a523-42e4-b828-da2616684fa0@github.com>
Message-ID: <h0f6jihvXA2uAfRt5r4j9HtIquEqV_CjazEoCVR8MQs=.74f643ad-e029-411d-9612-25b64b7e8ad3@github.com>

On Tue, 24 Feb 2026 22:41:08 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> jpackage will attempt to delete the temp directory a few times. If all attempts fail, it will print remaining files and empty directories (100 entries at most) to the console and continue. It will not exit with an error status as previously, as this is not a critical error.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29664#pullrequestreview-3850905325

From asemenyuk at openjdk.org  Wed Feb 25 11:10:08 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 25 Feb 2026 11:10:08 GMT
Subject: RFR: 8374222: jpackage will exit with error if it fails to clean
 the temp directory [v2]
In-Reply-To: <xA519FvvpqQYmj68SxQ7NJ6zx0S7_FzmXzye2cfY2m0=.0b361498-3aab-4d1b-80e7-1c0b1f845d32@github.com>
References: <slkcuguuN_dOz_pjLZs_xVDEy0aGeTjk6BiBs5fawzU=.245d6070-5d05-4d4a-a923-414b4cbe515d@github.com>
 <xA519FvvpqQYmj68SxQ7NJ6zx0S7_FzmXzye2cfY2m0=.0b361498-3aab-4d1b-80e7-1c0b1f845d32@github.com>
Message-ID: <7CMIom_roARGg1j-mgoXxkc_-uIr0geQosWuTB2ZYrU=.c0618d89-2231-423f-b407-5c3b6fd5def5@github.com>

On Wed, 18 Feb 2026 01:58:16 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/TempDirectoryTest.java line 123:
> 
>> 121: 
>> 122:     @ParameterizedTest
>> 123:     @CsvSource({"100", "0"})
> 
> Do we need to test other limits like 101 or 1?

Added 101 and 1

> test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/TempDirectoryTest.java line 292:
> 
>> 290: 
>> 291:         boolean isSuccess() {
>> 292:             return this ==  SUCCEED;
> 
> Extra space.

Extra whitespace removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29664#discussion_r2849883356
PR Review Comment: https://git.openjdk.org/jdk/pull/29664#discussion_r2849884476

From dl at openjdk.org  Wed Feb 25 11:10:20 2026
From: dl at openjdk.org (Doug Lea)
Date: Wed, 25 Feb 2026 11:10:20 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v43]
In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
Message-ID: <C_2MgtlUGjAsF4LPjMaRO8sT0oXxaQ3F4JA8dLEBcbQ=.47415a71-b987-49f1-b202-2bb0ce5eb85c@github.com>

> Changes signal filtering to avoid possible starvation

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Less memory traffic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28797/files
  - new: https://git.openjdk.org/jdk/pull/28797/files/518b3c8f..7e1ad28d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=42
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=41-42

  Stats: 138 lines in 1 file changed: 48 ins; 52 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/28797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28797/head:pull/28797

PR: https://git.openjdk.org/jdk/pull/28797

From asemenyuk at openjdk.org  Wed Feb 25 11:12:09 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 25 Feb 2026 11:12:09 GMT
Subject: RFR: 8371438: jpackage should handle the case when "--mac-sign" is
 specified without signing identity options
Message-ID: <YfEBGJapqfeJcsFueUI8LP5xT6cc9Kk0eIc6tvCtvRc=.bfb229eb-a0cf-443f-b7b1-162cb7e2eaac@github.com>

Restore the logic of how jpackage handles cases when the "--mac-sign" option is specified without the "--mac-signing-key-user-name" or "--mac-app-image-sign-identity" option. 

Make it work as it did prior to the [JDK-8333664](https://bugs.openjdk.org/browse/JDK-8333664) patch, which caused jpackage to silently ignore the "--mac-sign" option and not sign the output bundle.

The restored behavior is as follows:

If the "--mac-sign" option is specified, jpackage will always attempt to sign the output bundle.

If none of the signing identity options ("--mac-signing-key-user-name", "--mac-app-image-sign-identity", or "--mac-installer-sign-identity") is specified, jpackage will look up for a signing identity (or signing identities in case of PKG bundling) in the keychain specified with the "--mac-signing-keychain", or in the default keychain of the current user if the "--mac-signing-keychain" option is not specified.

If the keychain contains exactly one signing certificate of a specific type (a certificate for signing an app image or a certificate for signing a PKG installer), jpackage will use it for signing. Otherwise, jpackage will exit with an error.

Added tests to cover the cases when the "--mac-sign" option is specified and the keychain has/doesn't have signing certificates.

-------------

Commit messages:
 - Use jdk.test.lib.security.CertificateBuilder to create signing certificates instead of static sign-env.xml
 - ErrorTest: better coverage for signing without explicit signing identity on the command line
 - Support signing mocks. So far "/usr/bin/security" mock is supported.
 - test.mock: enhance CommandAction.Context; MockIllegalStateException: add null check to the ctor
 - MacSign: expose some API, support keychain mocks
 - Add negative tests; Fix bug in MacFromOptions.createMacApplicationInternal() uncovered with the negative tests
 - SigningAppImageTwoStepsTest: remove redundant test cases
 - MacHelper: Support testing of SHA1 digests with the "--mac-signing-key-user-name" option; reduce number of test cases in th tests derived from the SigningPackageTest test; SigningPackageTest: remove redundant test cases
 - SigningAppImageTwoStepsTest: add missing MacSign.withKeychain() call. Without the call, the test may randomly fail with cryptic "SigningAppImageTwoStepsTest/test.4fc29fd2/appimage-5/SigningAppImageTwoStepsTest.app/Contents/MacOS/testAL: errSecInternalComponent" error message if the keychain happens to be locked. "security unlock-keychain" command unlocks a keychain, but it gets automatically locked after some duration of time. To avoid interrupts, signing tests should call the "security unlock-keychain" command a keychain before running any signing operations using this keychain.
 - MacFromOptions: fix ServiceTest failure
 - ... and 1 more: https://git.openjdk.org/jdk/compare/6b576235...3744639e

Changes: https://git.openjdk.org/jdk/pull/29290/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29290&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371438
  Stats: 1429 lines in 20 files changed: 1295 ins; 35 del; 99 mod
  Patch: https://git.openjdk.org/jdk/pull/29290.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29290/head:pull/29290

PR: https://git.openjdk.org/jdk/pull/29290

From asemenyuk at openjdk.org  Wed Feb 25 11:12:12 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 25 Feb 2026 11:12:12 GMT
Subject: RFR: 8371438: jpackage should handle the case when "--mac-sign" is
 specified without signing identity options
In-Reply-To: <YfEBGJapqfeJcsFueUI8LP5xT6cc9Kk0eIc6tvCtvRc=.bfb229eb-a0cf-443f-b7b1-162cb7e2eaac@github.com>
References: <YfEBGJapqfeJcsFueUI8LP5xT6cc9Kk0eIc6tvCtvRc=.bfb229eb-a0cf-443f-b7b1-162cb7e2eaac@github.com>
Message-ID: <XF4HaqasugWoBl_wHn_Td2HsKSNOUc9lB6D4Pv0oFbI=.51e0ae8a-c75d-4d24-a92c-1ea470e17ba8@github.com>

On Sun, 18 Jan 2026 07:34:45 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Restore the logic of how jpackage handles cases when the "--mac-sign" option is specified without the "--mac-signing-key-user-name" or "--mac-app-image-sign-identity" option. 
> 
> Make it work as it did prior to the [JDK-8333664](https://bugs.openjdk.org/browse/JDK-8333664) patch, which caused jpackage to silently ignore the "--mac-sign" option and not sign the output bundle.
> 
> The restored behavior is as follows:
> 
> If the "--mac-sign" option is specified, jpackage will always attempt to sign the output bundle.
> 
> If none of the signing identity options ("--mac-signing-key-user-name", "--mac-app-image-sign-identity", or "--mac-installer-sign-identity") is specified, jpackage will look up for a signing identity (or signing identities in case of PKG bundling) in the keychain specified with the "--mac-signing-keychain", or in the default keychain of the current user if the "--mac-signing-keychain" option is not specified.
> 
> If the keychain contains exactly one signing certificate of a specific type (a certificate for signing an app image or a certificate for signing a PKG installer), jpackage will use it for signing. Otherwise, jpackage will exit with an error.
> 
> Added tests to cover the cases when the "--mac-sign" option is specified and the keychain has/doesn't have signing certificates.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29290#issuecomment-3955089840

From almatvee at openjdk.org  Wed Feb 25 11:12:32 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 25 Feb 2026 11:12:32 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v15]
In-Reply-To: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
Message-ID: <yGv4AnmpMaiKQTeNT0hxS8wAnzuq0PaBJNnU8cOW0EM=.d79194f9-577d-4386-8566-065599f13056@github.com>

> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
> - Added test to cover added functionality.
> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v12]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29260/files
  - new: https://git.openjdk.org/jdk/pull/29260/files/1bca2865..f398add7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=13-14

  Stats: 190 lines in 5 files changed: 98 ins; 34 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/29260.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29260/head:pull/29260

PR: https://git.openjdk.org/jdk/pull/29260

From almatvee at openjdk.org  Wed Feb 25 11:12:45 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 25 Feb 2026 11:12:45 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v14]
In-Reply-To: <nZz-9QE2qMkqmhVA1WNHjiAM7bQdwiAHb0gKchsYtQU=.7fcce853-137f-4a2b-9840-f38dae2e5b63@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <nZz-9QE2qMkqmhVA1WNHjiAM7bQdwiAHb0gKchsYtQU=.7fcce853-137f-4a2b-9840-f38dae2e5b63@github.com>
Message-ID: <Mqc02ibdBd-i50dX_NNTxvOPe0UjMxJDPBA7Lmm3enA=.86452e4d-8eb1-4159-9dad-f3f0a3f4c978@github.com>

On Thu, 19 Feb 2026 23:25:41 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Version will be read from JDK's release file if not provided via `--version` for runtime installer.
>> - Added test to cover added functionality.
>> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements.
>
> Alexander Matveev 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 remote-tracking branch 'upstream/master' into JDK-8357404
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v11]
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v10]
>  - Merge remote-tracking branch 'upstream/master' into JDK-8357404
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v9]
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v8]
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v7]
>  - Merge remote-tracking branch 'upstream/master' into JDK-8357404
>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]
>  - merge with upstream
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/ff1c42f1...1bca2865

8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v12]
- Rework `RuntimePackageTest` to improve test coverage.
- Minor code/comments cleanup.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29260#issuecomment-3955270410

From almatvee at openjdk.org  Wed Feb 25 11:12:58 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 25 Feb 2026 11:12:58 GMT
Subject: RFR: 8357404: jpackage should attempt to get a package version
 from the JDK's release file if the --version option is not specified [v14]
In-Reply-To: <-0YZL7vNyJnNTFYbwDmWMpbq3EqHsc8cEup-6iA6B3A=.87d95817-70d6-4a45-922f-357a9f3b2554@github.com>
References: <bUEuLaspgNZ9orVWqz0uuSvZq0uqz_UcY7mdhJBlhhU=.4110cf43-7e6b-4954-88ff-0a3b5e8e4760@github.com>
 <nZz-9QE2qMkqmhVA1WNHjiAM7bQdwiAHb0gKchsYtQU=.7fcce853-137f-4a2b-9840-f38dae2e5b63@github.com>
 <-0YZL7vNyJnNTFYbwDmWMpbq3EqHsc8cEup-6iA6B3A=.87d95817-70d6-4a45-922f-357a9f3b2554@github.com>
Message-ID: <Pe1T0ZvUwqvNGfrbC6oMX5qJrgSQW9V-2fk-4d2XNe4=.f50b550e-13e9-47c0-b269-8f0f8546aa31@github.com>

On Mon, 23 Feb 2026 17:37:46 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 pull request now contains 15 commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8357404
>>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v11]
>>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v10]
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8357404
>>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v9]
>>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v8]
>>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v7]
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8357404
>>  - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6]
>>  - merge with upstream
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/ff1c42f1...1bca2865
>
> test/jdk/tools/jpackage/share/RuntimePackageTest.java line 136:
> 
>> 134:     @Parameter(value = {"17.21.3+foo", "1.0"})
>> 135:     // 27
>> 136:     @Parameter(value = {"27"})
> 
> Shouldn't it convert "27" into "27.0" on Windows?

Yes, we should. I will fix it in upcoming test update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2849595872

From erfang at openjdk.org  Wed Feb 25 11:15:33 2026
From: erfang at openjdk.org (Eric Fang)
Date: Wed, 25 Feb 2026 11:15:33 GMT
Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in
 specific patterns [v11]
In-Reply-To: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
References: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
Message-ID: <7_MkAbcoypxV-8B1u-Gx_LytLa8EbFQCbVUWBE63vI4=.eade482e-7420-42a6-9804-07029309a0db@github.com>

> `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common.
> 
> If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example:
> 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)`
> 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`.
> 
> In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast.
> 
> The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`.
> 
> The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain.
> 
> Current optimizations related to `VectorMaskCastNode` include:
> 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760.
> 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242.
> 
> This PR does the following optimizations:
> 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct.
> 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vector, it remains unchanged as long as th...

Eric Fang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Improve the code comment and tests
 - Merge branch 'master' into JDK-8370863-mask-cast-opt
 - Refine the JTReg tests
 - Add clearer comments to VectorMaskCastIdentityTest.java
 - Update copyright year to 2026
 - Merge branch 'master' into JDK-8370863-mask-cast-opt
 - Convert the check condition for vector length into an assertion
   
   Also refined the tests.
 - Refine code comments
 - Merge branch 'master' into JDK-8370863-mask-cast-opt
 - Merge branch 'master' into JDK-8370863-mask-cast-opt
 - ... and 6 more: https://git.openjdk.org/jdk/compare/c0c1775a...dcd64ad1

-------------

Changes: https://git.openjdk.org/jdk/pull/28313/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28313&range=10
  Stats: 665 lines in 8 files changed: 551 ins; 13 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/28313.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28313/head:pull/28313

PR: https://git.openjdk.org/jdk/pull/28313

From erfang at openjdk.org  Wed Feb 25 11:16:08 2026
From: erfang at openjdk.org (Eric Fang)
Date: Wed, 25 Feb 2026 11:16:08 GMT
Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in
 specific patterns [v6]
In-Reply-To: <K1Xi_2R4-KEK8T_geJNRn-vjTk3L88k0_pY4idYr5-4=.6f7d9b04-47eb-44c4-8eb4-25dc2213ea4d@github.com>
References: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
 <XKmmrJ8kRojhN4livA28SuX0XZsQSsQACBFXXDz3j6M=.2403d747-78e3-423c-a5da-3b94ab3826c3@github.com>
 <K1Xi_2R4-KEK8T_geJNRn-vjTk3L88k0_pY4idYr5-4=.6f7d9b04-47eb-44c4-8eb4-25dc2213ea4d@github.com>
Message-ID: <SYb-XrnBhEGzJsw9VDYSTmKWUwYvmoGQa4HlUirp9mc=.d39a54cd-9189-4588-b526-473b2fbf37e8@github.com>

On Fri, 26 Dec 2025 11:10:07 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Eric Fang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refine code comments
>
> I'll review this again in early January, once I'm back from Christnas/New Year break ;)

Hi @eme64 I have addressed your comments, thanks for your review ! And now could you help me run an internal test, thanks~

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28313#issuecomment-3956345853

From epeter at openjdk.org  Wed Feb 25 11:16:37 2026
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 25 Feb 2026 11:16:37 GMT
Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in
 specific patterns [v10]
In-Reply-To: <_quPIapU_CUjz2J3W-s_3qOjV37ikujROE-CHeEcSZY=.ee511f07-d3dd-4b43-998f-1898167d9297@github.com>
References: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
 <_quPIapU_CUjz2J3W-s_3qOjV37ikujROE-CHeEcSZY=.ee511f07-d3dd-4b43-998f-1898167d9297@github.com>
Message-ID: <-6lvNUQhUompQMZ5O1o3_wnHg1dPKjHCUQW0FNaY0rA=.2da2c922-5edb-4f4d-b69a-38cf37e9f8d6@github.com>

On Thu, 5 Feb 2026 09:08:53 GMT, Eric Fang <erfang at openjdk.org> wrote:

>> `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common.
>> 
>> If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example:
>> 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)`
>> 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`.
>> 
>> In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast.
>> 
>> The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`.
>> 
>> The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain.
>> 
>> Current optimizations related to `VectorMaskCastNode` include:
>> 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760.
>> 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242.
>> 
>> This PR does the following optimizations:
>> 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct.
>> 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vect...
>
> Eric Fang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine the JTReg tests

Ok, I think I'm happy with the code now, I'll run some internal testing :) ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28313#issuecomment-3957514004

From xgong at openjdk.org  Wed Feb 25 11:16:37 2026
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 25 Feb 2026 11:16:37 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v14]
In-Reply-To: <ZFFAsf3VHOHPTZc3NvS5Kq9NLUGyKL2T-Sh7RYW-_cs=.05b0d3b7-7702-488f-8e81-08c0a4086675@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <ZFFAsf3VHOHPTZc3NvS5Kq9NLUGyKL2T-Sh7RYW-_cs=.05b0d3b7-7702-488f-8e81-08c0a4086675@github.com>
Message-ID: <HcMzc0JEWmkpKIySeUPbp3UNBCVQcz_qWCpGxlgTfhI=.3d6e0847-7adb-4b4b-8045-56c326f3cdb0@github.com>

On Tue, 24 Feb 2026 10:10:17 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:
> 
>   Review comments resolution

There are regression for these two cases. Do you know the root cause?

Before:
VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6204.489          ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2   1651.334          ops/ms

After:
VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   5626.367          ops/ms
VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2    960.958          ops/ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3957448681

From erfang at openjdk.org  Wed Feb 25 11:16:54 2026
From: erfang at openjdk.org (Eric Fang)
Date: Wed, 25 Feb 2026 11:16:54 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v14]
In-Reply-To: <ZFFAsf3VHOHPTZc3NvS5Kq9NLUGyKL2T-Sh7RYW-_cs=.05b0d3b7-7702-488f-8e81-08c0a4086675@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <ZFFAsf3VHOHPTZc3NvS5Kq9NLUGyKL2T-Sh7RYW-_cs=.05b0d3b7-7702-488f-8e81-08c0a4086675@github.com>
Message-ID: <f7cpJTUpgGmh1np9qOinFg6YCmBK0qAE7xw-iJTtslI=.448a855b-9ad5-429b-a040-c24cec993661@github.com>

On Tue, 24 Feb 2026 10:10:17 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:
> 
>   Review comments resolution

src/hotspot/share/opto/compile.cpp line 2065:

> 2063:     igvn_worklist()->ensure_empty(); // should be done with igvn
> 2064: 
> 2065:     while (inline_incrementally_one()) {

Is it possible to generate `_vector_late_inlines` candidate again in `inline_incrementally_one`?

src/hotspot/share/opto/compile.hpp line 480:

> 478: 
> 479:   GrowableArray<CallGenerator*> _vector_reboxing_late_inlines; // same but for vector reboxing operations
> 480:   GrowableArray<CallGenerator*> _vector_late_inlines; // inline fallback implimentation for failed intrinsics

implementation

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2850961256
PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2850934430

From jpai at openjdk.org  Wed Feb 25 11:18:49 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Feb 2026 11:18:49 GMT
Subject: RFR: 8362268: NPE thrown from SASL GSSAPI impl when TLS is used
 with QOP auth-int against Active Directory [v5]
In-Reply-To: <39nXLnFR2Kl257ljgwgsenJDyFCuL6EegMWXeeSZGI0=.3c3c2250-2ff9-44e1-8647-c23bf643a14b@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
 <39nXLnFR2Kl257ljgwgsenJDyFCuL6EegMWXeeSZGI0=.3c3c2250-2ff9-44e1-8647-c23bf643a14b@github.com>
Message-ID: <Kz0CFzS9A1-lmbtV4YrUBntv0WR-rrbZSpUluq3OsrY=.8c74f073-0f48-4882-9566-a91a19e59fdf@github.com>

On Mon, 23 Feb 2026 01:46:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?
>> 
>> The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.
>> 
>> When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.
>> 
>> When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.
>> 
>> Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `Outp...
>
> 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 11 additional commits since the last revision:
> 
>  - merge latest from master branch
>  - Daniel's review - recheck while holding the lock
>  - merge latest from master branch
>  - merge latest from master branch
>  - merge latest from master branch
>  - add comment
>  - copyright years
>  - alternate fix
>  - rename test
>  - 8362268: NPE thrown from SASL GSSAPI impl when  TLS is  used with QOP auth-int against Active Directory
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/1b86e9df...fa582f62

Thank you all for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29638#issuecomment-3955773365

From jpai at openjdk.org  Wed Feb 25 11:18:57 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Feb 2026 11:18:57 GMT
Subject: Integrated: 8362268: NPE thrown from SASL GSSAPI impl when  TLS is
 used with QOP auth-int against Active Directory
In-Reply-To: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
References: <ta-FEyqFVlHYxx_oeVq3dKhJy2RzpUFXvForl8ET0hM=.b77d2523-6da7-4662-8e3d-7d26ad262ed1@github.com>
Message-ID: <5EMcYCZpzUiRLcnz1Cf0OpL0BrxLESkgSavLy9Q9fqY=.c68d9259-9b90-46cc-b851-8c8f61025bc9@github.com>

On Mon, 9 Feb 2026 14:47:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8362268?
> 
> The underlying issue here is simple - A `javax.naming.Context` for LDAP is backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. Each `Connection` instance uses a `Socket` and the socket's `InputStream` and `OutputStream` to read/write LDAP messages from/to a LDAP server. Each `Connection` instance spawns a `Thread` to read (over the InputStream) and queue incoming messages from the LDAP server.
> 
> When a LDAP backed `javax.naming.Context` initiates an operation, for example a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request over the Connection's `OutputStream` and then waits for a LDAP response to arrive. In the issue reported here, it so happens that while reading over the `Connection`'s `InputStream`, the `InputStream.read()` raises an `IOException` (for whatever reason). That `IOException` rightly initiates the close of the `Connection` instance. Closing a `Connection` instance involves queuing a marker response for all waiting thread(s) to notice and raise an IOException, which they can ulimately propagate as a `NamingException` to the application. Additionally, the closing of the `Connection` also closes the `InputStream` and `OutputStream` of that `Connection`.
> 
> When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due to an IOException, it attempts to send a "abandon request" LDAP message over the `Connection`, so that the server knows that the client has abandoned the request. Since the Connection and its Input/OutputStream(s) are already closed, trying to write a message over the OutputStream can/will lead to an exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, Control[] reqCtls)` which is where this code resides, guards against such exceptions by catching and ignoring an `IOException` from an `OutputStream.write(...)/flush()` call.
> 
> Although `OutputStream.write(...)` is specified to throw an IOException if that stream is already closed, not all implementations adhere to that specification. For example, `java.io.BufferedOutputStream` does not throw any exception when `write(...)` is invoked on a closed `OutputStream`. Incidentally, the `Connection` instance's `OutputStream` is a `Bu...

This pull request has now been integrated.

Changeset: a890dd1f
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a890dd1fcd992ad744c3b26a6203f98d41161fb0
Stats:     306 lines in 3 files changed: 294 ins; 0 del; 12 mod

8362268: NPE thrown from SASL GSSAPI impl when  TLS is  used with QOP auth-int against Active Directory

Reviewed-by: dfuchs, aefimov

-------------

PR: https://git.openjdk.org/jdk/pull/29638

From jbhateja at openjdk.org  Wed Feb 25 11:24:00 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 25 Feb 2026 11:24:00 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating
 broadcasted inputs [v4]
In-Reply-To: <v7k5NyQnSGV8lLiNTdBSNdkNrkPPj_XU-uXqMRcN-M4=.d136f0a8-a56a-4f3c-94b9-1e56e6db2527@github.com>
References: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
 <pOF2vnq6e-ycbGs8DKIkJiCQBXHMY-O9rea_Ua-giCM=.b21d2594-2375-41cc-8ff6-8491ac332ea2@github.com>
 <v7k5NyQnSGV8lLiNTdBSNdkNrkPPj_XU-uXqMRcN-M4=.d136f0a8-a56a-4f3c-94b9-1e56e6db2527@github.com>
Message-ID: <snf8wJ9MExMuHIatK7gTtPmZjzZ33i0B4gXBjg4FjjU=.ccaf8cc6-79f7-4f26-852a-3767a057c38d@github.com>

On Tue, 24 Feb 2026 08:59:27 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions
>
> src/hotspot/share/opto/subnode.hpp line 524:
> 
>> 522:     if (c != nullptr) {
>> 523:       C->add_expensive_node(this);
>> 524:     }
> 
> Can you explain a bit more about this change? What is the flag used for, and why did you need to change it?

Comment above it mentions the reason, We don't attach control inputs while creating SqrtVD node in VectorNode::make, similar check is added for SqrtF before calling add_expensive_node.
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/subnode.hpp#L539

While converting SqrtVD with broadcasted input to SqrtD we don't receive any control input. is_expensive called from add_expensive_node expects a control input.

> src/hotspot/share/opto/vectornode.cpp line 1363:
> 
>> 1361:     if (sop) {
>> 1362:       sop = phase->transform(sop);
>> 1363:       return new ReplicateNode(sop, vect_type());
> 
> Suppose we have an `add` operation on a `byte` vector. The operations are truncated. But the `AddI` operation would overflow the `byte` range. Does the `Replicate` node ensure that truncation?

Yes, replicate will only read lower 8 / 16 bits of integral result.

> src/hotspot/share/opto/vectornode.cpp line 1363:
> 
>> 1361:     if (sop) {
>> 1362:       sop = phase->transform(sop);
>> 1363:       return new ReplicateNode(sop, vect_type());
> 
> How sure are you that the truncating vector operations are correctly optimized with the non-truncating scalar operations? Is it guaranteed that `Replicate` does the truncation?

Replicate will always pick exact sized value.

> src/hotspot/share/opto/vectornode.cpp line 2104:
> 
>> 2102:     return VectorNode::degenerate_vector_rotate(in(1), in(2), true, vlen, bt, phase);
>> 2103:   }
>> 2104:   return VectorNode::Ideal(phase, can_reshape);
> 
> Would it not make sense to do the `Ideal` before the possible degeneration? Just in case we can optimize away the rotation, by pushing it through the broadcast?

Reverting for now, we are not handling Rotates currently.

> test/hotspot/jtreg/compiler/vectorapi/TestVectorBroadcastReassociations.java line 60:
> 
>> 58:                 .add(IntVector.broadcast(ISP, ib))
>> 59:                 .reduceLanes(VectorOperators.ADD);
>> 60:     }
> 
> Why do you have the `VECTOR_SIZE_ANY`? Do we not get a replicate with the maximal size?
> 
> I don't think it is wise to take an ADD reduction here, because that may also produce a ADD_I node. And then you're not sure if the IR rule finds that one or the one generated from the broadcast optimization.

Since I am using SPECIES_PREFERRED" Double and Float vector lane wise operations are 128-bit wide at UseAVX=1 for sake of lane size compatibility with integral vector.

> test/hotspot/jtreg/compiler/vectorapi/TestVectorBroadcastReassociations.java line 136:
> 
>> 134:      * ======================= */
>> 135: 
>> 136:     static final VectorSpecies<Long> LSP = LongVector.SPECIES_PREFERRED;
> 
> Why don't you have the logical operators for long tested below?

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2851743023
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2851743785
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2851746255
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2851743928
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2851744539
PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r2851745355

From jbhateja at openjdk.org  Wed Feb 25 11:23:45 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 25 Feb 2026 11:23:45 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating
 broadcasted inputs [v5]
In-Reply-To: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
References: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
Message-ID: <5vQ1GssolkSOsam9RtC3KFrvaQOFxA4738kOVWmymTA=.a1586a18-ea4a-478f-b4e2-62bf5c00175a@github.com>

> Hi all,
> 
> This patch optimizes SIMD kernels making heavy use of broadcasted inputs through following reassociating ideal transformations.
> 
> 
>  VectorOperation (VectorBroadcast INP1,  VectorBroadcast INP2) => 
>                             VectorBroadcast (ScalarOpration INP1, INP2)
> 
>  VectorOperation (VectorBroadcast INP1) (VectorOperation (VectorBroadcast INP2) INP3) => 
>                              VectorOperation INP3 (VectorOperation (VectorBroadcast INP1) (VectorBroadcast INP2))
> 
> 
> The idea is to push broadcasts across the vector operation and replace the vector with an equivalent, cheaper scalar variant.  Currently, patch handles most common vector operations.
> 
> Following are the performance number of benchmark included with this patch on latest generation x86 targets:- 
> 
> **AMD Turin (2.1GHz)**
> <img width="1122" height="355" alt="image" src="https://github.com/user-attachments/assets/3f5087bf-0e14-4c56-b0c2-3d23253bad54" />
> 
> **Intel Granite Rapids (2.1GHz)**
> <img width="1105" height="325" alt="image" src="https://github.com/user-attachments/assets/c8481f86-4db2-4c4e-bd65-51542c59fe63" />
> 
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review comments resolutions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25617/files
  - new: https://git.openjdk.org/jdk/pull/25617/files/15f2d57e..673a7acb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25617&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25617&range=03-04

  Stats: 866 lines in 5 files changed: 761 ins; 13 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/25617.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25617/head:pull/25617

PR: https://git.openjdk.org/jdk/pull/25617

From vklang at openjdk.org  Wed Feb 25 11:35:19 2026
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 25 Feb 2026 11:35:19 GMT
Subject: RFR: 8378268: Thread.join can wait on Thread,
 allows joinNanos to be removed
In-Reply-To: <-ckkcXUkmMzpwb4p_Bc6rx_e25gD-5OhGuG6Uw8JYwg=.d8d7e10c-2218-41af-8167-9446684ace09@github.com>
References: <-ckkcXUkmMzpwb4p_Bc6rx_e25gD-5OhGuG6Uw8JYwg=.d8d7e10c-2218-41af-8167-9446684ace09@github.com>
Message-ID: <3PK3kWnbBsdjt9BzSnjjJlSVdiy3XU5NBpDLPYLATpY=.d63d333a-b769-4fb8-a9b3-f75ffc744dc1@github.com>

On Fri, 20 Feb 2026 09:26:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.join was historically implemented with a loop of Object.wait conditioned on isAlive. We couldn't for this virtual threads because it would pin a virtual thread invoking join to it carrier.  Now that Object.wait preempts, it means the special implementation of join for virtual threads can be removed. Where possible, the notifyAll is elided as it adds to the cost of termination.
> 
> The implNote of the join methods is restored (this is implNote text, not spec, so no CSR required).

Nice work, Alan

-------------

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29839#pullrequestreview-3853630914

From shaojin.wensj at alibaba-inc.com  Wed Feb 25 12:45:20 2026
From: shaojin.wensj at alibaba-inc.com (wenshao)
Date: Wed, 25 Feb 2026 20:45:20 +0800
Subject: [External] : [RFR] C2 optimization for String.format()
Message-ID: <08ea8a4a-dd35-45b1-a507-73325ca5b94a.shaojin.wensj@alibaba-inc.com>

Hi,
I'd like to request a review for a C2 optimization for String.format()
and String.formatted() with simple format strings:
https://github.com/openjdk/jdk/pull/29915 <https://github.com/openjdk/jdk/pull/29915 >
Summary
-------
When String.format() or formatted() is called with a compile-time constant format string containing simple specifiers (%s, %d, %x, %X), this optimization
bypasses the java.util.Formatter overhead and directly builds the result string.
The C2 compiler recognizes these calls during the Parse phase and redirects them to specialized fast-path methods in java.lang.String.
Performance
-----------
Benchmarks show 2.6x - 4.3x speedup for common patterns:
 "Hello %s".formatted(name) -> 3.75x faster
 "%s: %d".formatted(key, value) -> 2.62x faster
 "%s %s %s %s".formatted(...) -> 2.68x faster
Fallback
--------
The optimization only applies to simple cases. Complex format strings (width > 9, precision, most flags, non-constant format) fall back to the existing Formatter implementation.
Testing
-------
- JMH microbenchmarks verify performance improvement
- jtreg functional tests cover optimized and fallback paths
- IR tests verify correct C2 code generation
I would appreciate any feedback on the approach or implementation.
Thanks,
Wenshao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260225/9513252d/attachment.htm>

From jpai at openjdk.org  Wed Feb 25 13:08:57 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Feb 2026 13:08:57 GMT
Subject: RFR: 8378631: Update Zlib Data Compression Library to Version 1.3.2
Message-ID: <3ciJz-gZK5MjQx6SSiAgbf4qmBFUYPT-fMjx9mISCEU=.416de52a-c7a3-4ba3-a282-d9130fd6483c@github.com>

Can I please get a review of this change which upgrades JDK's in-tree zlib code from 1.3.1 to the recently released zlib 1.3.2 version?

As noted in https://bugs.openjdk.org/browse/JDK-8378631, then changes between the upstream zlib 1.3.1 and 1.3.2 are available here https://github.com/madler/zlib/compare/v1.3.1...v1.3.2.

-------------

Commit messages:
 - zlib bundled, set HAVE_UNISTD_H and HAVE_STDARG_H to 1
 - 8378631: Update Zlib Data Compression Library to Version 1.3.2

Changes: https://git.openjdk.org/jdk/pull/29916/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29916&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378631
  Stats: 1810 lines in 26 files changed: 795 ins; 368 del; 647 mod
  Patch: https://git.openjdk.org/jdk/pull/29916.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29916/head:pull/29916

PR: https://git.openjdk.org/jdk/pull/29916

From epeter at openjdk.org  Wed Feb 25 13:14:15 2026
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 25 Feb 2026 13:14:15 GMT
Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in
 specific patterns [v11]
In-Reply-To: <7_MkAbcoypxV-8B1u-Gx_LytLa8EbFQCbVUWBE63vI4=.eade482e-7420-42a6-9804-07029309a0db@github.com>
References: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
 <7_MkAbcoypxV-8B1u-Gx_LytLa8EbFQCbVUWBE63vI4=.eade482e-7420-42a6-9804-07029309a0db@github.com>
Message-ID: <pnZJvIEVLj9G0x376kpsgd01o7kZX5XJW-xjZOP143g=.775b8168-8726-48d5-9f01-571656e36510@github.com>

On Wed, 25 Feb 2026 11:15:33 GMT, Eric Fang <erfang at openjdk.org> wrote:

>> `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common.
>> 
>> If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example:
>> 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)`
>> 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`.
>> 
>> In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast.
>> 
>> The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`.
>> 
>> The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain.
>> 
>> Current optimizations related to `VectorMaskCastNode` include:
>> 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760.
>> 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242.
>> 
>> This PR does the following optimizations:
>> 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct.
>> 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vect...
>
> Eric Fang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Improve the code comment and tests
>  - Merge branch 'master' into JDK-8370863-mask-cast-opt
>  - Refine the JTReg tests
>  - Add clearer comments to VectorMaskCastIdentityTest.java
>  - Update copyright year to 2026
>  - Merge branch 'master' into JDK-8370863-mask-cast-opt
>  - Convert the check condition for vector length into an assertion
>    
>    Also refined the tests.
>  - Refine code comments
>  - Merge branch 'master' into JDK-8370863-mask-cast-opt
>  - Merge branch 'master' into JDK-8370863-mask-cast-opt
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/c0c1775a...dcd64ad1

I'm getting some failures with your new test:


Failed IR Rules (1) of Methods (1)
----------------------------------
1) Method "compiler.vectorapi.VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityFloat256" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"sve", "true", "avx2", "true"}, counts={"_#V#LOAD_VECTOR_Z#_", "_ at 4", ">= 3", "_#VECTOR_LOAD_MASK#_", "= 0", "_#VECTOR_STORE_MASK#_", "= 0", "_#VECTOR_MASK_CAST#_", "= 0"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={"MaxVectorSize", "> 16"}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - counts: Graph contains wrong number of nodes:
         * Constraint 2: "(\\d+(\\s){2}(VectorLoadMask.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 1 = 0 [given]
             - Matched node:
               * 277  VectorLoadMask  === _ 106  [[ 275 ]]  #vectormask<F,4> !jvms: VectorMask::fromArray @ bci:47 (line 209) VectorStoreMaskIdentityTest::testTwoCastsKernel @ bci:5 (line 75) VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityFloat256 @ bci:29 (line 271)
         * Constraint 3: "(\\d+(\\s){2}(VectorStoreMask.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 1 = 0 [given]
             - Matched node:
               * 254  VectorStoreMask  === _ 271 272  [[ 216 ]]  #vectors<Z,4> !jvms: AbstractMask::intoArray @ bci:50 (line 75) VectorStoreMaskIdentityTest::testTwoCastsKernel @ bci:20 (line 77) VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityFloat256 @ bci:29 (line 271)
         * Constraint 4: "(\\d+(\\s){2}(VectorMaskCast.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 2 = 0 [given]
             - Matched nodes (2):
               * 271  VectorMaskCast  === _ 275  [[ 254 ]]  #vectormask<J,4> !jvms: ShortVector64$ShortMask64::cast @ bci:54 (line 665) VectorStoreMaskIdentityTest::testTwoCastsKernel @ bci:13 (line 77) VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityFloat256 @ bci:29 (line 271)
               * 275  VectorMaskCast  === _ 277  [[ 271 ]]  #vectormask<S,4> !orig=[5222],[2038] !jvms: FloatVector128$FloatMask128::cast @ bci:54 (line 654) VectorStoreMaskIdentityTest::testTwoCastsKernel @ bci:9 (line 76) VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityFloat256 @ bci:29 (line 271)


This was run on an x64 machine with extra flags:
`-ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation`

And with the same flags, I get a failure on an aarch64 machine:

Failed IR Rules (1) of Methods (1)
----------------------------------
1) Method "compiler.vectorapi.VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityLong" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"asimd", "true"}, counts={"_#V#LOAD_VECTOR_Z#_", "_ at 2", ">= 3", "_#VECTOR_LOAD_MASK#_", "= 0", "_#VECTOR_STORE_MASK#_", "= 0", "_#VECTOR_MASK_CAST#_", "= 0"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={"MaxVectorSize", ">= 16"}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - counts: Graph contains wrong number of nodes:
         * Constraint 2: "(\\d+(\\s){2}(VectorLoadMask.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 1 = 0 [given]
             - Matched node:
               * 278  VectorLoadMask  === _ 101  [[ 277 ]]  #vectorx<J,2> !jvms: VectorMask::fromArray @ bci:47 (line 209) VectorStoreMaskIdentityTest::testThreeCastsKernel @ bci:5 (line 85) VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityLong @ bci:55 (line 220)
         * Constraint 3: "(\\d+(\\s){2}(VectorStoreMask.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 1 = 0 [given]
             - Matched node:
               * 238  VectorStoreMask  === _ 263 264  [[ 194 ]]  #vectord<Z,2> !jvms: AbstractMask::intoArray @ bci:50 (line 75) VectorStoreMaskIdentityTest::testThreeCastsKernel @ bci:24 (line 88) VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityLong @ bci:55 (line 220)
         * Constraint 4: "(\\d+(\\s){2}(VectorMaskCast.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 3 = 0 [given]
             - Matched nodes (3):
               * 263  VectorMaskCast  === _ 275  [[ 238 ]]  #vectord<I,2> !jvms: DoubleVector128$DoubleMask128::cast @ bci:54 (line 650) VectorStoreMaskIdentityTest::testThreeCastsKernel @ bci:17 (line 88) VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityLong @ bci:55 (line 220)
               * 275  VectorMaskCast  === _ 277  [[ 263 ]]  #vectorx<D,2> !orig=[3350] !jvms: IntVector64$IntMask64::cast @ bci:54 (line 661) VectorStoreMaskIdentityTest::testThreeCastsKernel @ bci:13 (line 87) VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityLong @ bci:55 (line 220)
               * 277  VectorMaskCast  === _ 278  [[ 275 ]]  #vectord<I,2> !jvms: LongVector128$LongMask128::cast @ bci:54 (line 651) VectorStoreMaskIdentityTest::testThreeCastsKernel @ bci:9 (line 86) VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityLong @ bci:55 (line 220)


And with other flags, also on aarch64, I get:
`-XX:-TieredCompilation -XX:VerifyIterativeGVN=1110`


Failed IR Rules (1) of Methods (1)
----------------------------------
1) Method "compiler.vectorapi.VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityInt" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"asimd", "true", "avx", "true"}, counts={"_#V#LOAD_VECTOR_Z#_", "_ at 4", ">= 3", "_#VECTOR_LOAD_MASK#_", "= 0", "_#VECTOR_STORE_MASK#_", "= 0", "_#VECTOR_MASK_CAST#_", "= 0"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={"MaxVectorSize", ">= 16"}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - counts: Graph contains wrong number of nodes:
         * Constraint 2: "(\\d+(\\s){2}(VectorLoadMask.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 1 = 0 [given]
             - Matched node:
               * 278  VectorLoadMask  === _ 118  [[ 277 ]]  #vectorx<I,4> !jvms: VectorMask::fromArray @ bci:47 (line 209) VectorStoreMaskIdentityTest::testThreeCastsKernel @ bci:5 (line 85) VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityInt @ bci:55 (line 184)
         * Constraint 3: "(\\d+(\\s){2}(VectorStoreMask.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 1 = 0 [given]
             - Matched node:
               * 220  VectorStoreMask  === _ 256 257  [[ 168 ]]  #vectord<Z,4> !jvms: AbstractMask::intoArray @ bci:50 (line 75) VectorStoreMaskIdentityTest::testThreeCastsKernel @ bci:24 (line 88) VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityInt @ bci:55 (line 184)
         * Constraint 4: "(\\d+(\\s){2}(VectorMaskCast.*)+(\\s){2}===.*)"
           - Failed comparison: [found] 3 = 0 [given]
             - Matched nodes (3):
               * 256  VectorMaskCast  === _ 274  [[ 220 ]]  #vectord<S,4> !jvms: FloatVector128$FloatMask128::cast @ bci:54 (line 654) VectorStoreMaskIdentityTest::testThreeCastsKernel @ bci:17 (line 88) VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityInt @ bci:55 (line 184)
               * 274  VectorMaskCast  === _ 277  [[ 256 ]]  #vectorx<F,4> !orig=5368,[4300] !jvms: ShortVector64$ShortMask64::cast @ bci:54 (line 665) VectorStoreMaskIdentityTest::testThreeCastsKernel @ bci:13 (line 87) VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityInt @ bci:55 (line 184)
               * 277  VectorMaskCast  === _ 278  [[ 274 ]]  #vectord<S,4> !orig=[5231] !jvms: IntVector128$IntMask128::cast @ bci:54 (line 665) VectorStoreMaskIdentityTest::testThreeCastsKernel @ bci:9 (line 86) VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityInt @ bci:55 (line 184)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28313#issuecomment-3959167455

From alanb at openjdk.org  Wed Feb 25 13:30:26 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 25 Feb 2026 13:30:26 GMT
Subject: RFR: 8378631: Update Zlib Data Compression Library to Version
 1.3.2
In-Reply-To: <3ciJz-gZK5MjQx6SSiAgbf4qmBFUYPT-fMjx9mISCEU=.416de52a-c7a3-4ba3-a282-d9130fd6483c@github.com>
References: <3ciJz-gZK5MjQx6SSiAgbf4qmBFUYPT-fMjx9mISCEU=.416de52a-c7a3-4ba3-a282-d9130fd6483c@github.com>
Message-ID: <WUHKAEBCPZKNbyBH11R3vbCIu9ylrK9cuOTZmW2Z29g=.31133f9d-79be-4b69-82a8-ef4f6d660863@github.com>

On Wed, 25 Feb 2026 12:56:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which upgrades JDK's in-tree zlib code from 1.3.1 to the recently released zlib 1.3.2 version?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8378631, then changes between the upstream zlib 1.3.1 and 1.3.2 are available here https://github.com/madler/zlib/compare/v1.3.1...v1.3.2.

@jaikiran No changes from upstream, right? (ignoring the make file update to compile with -DHAVE_STDARG_H=1). Also would be possible to update the PR description to say what testing has been done as the defaults only use the in-tree version on Windows.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29916#issuecomment-3959256218

From liach at openjdk.org  Wed Feb 25 13:38:54 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Feb 2026 13:38:54 GMT
Subject: RFR: 8377438: [VectorAPI] Add new carrier type to LaneType class
 [v3]
In-Reply-To: <UNPXEPP2riZD-ACHcAi4ufkMSTlYAdflswGXxYl8RLc=.2662d8f4-e034-4da2-998a-c43fe78e89f6@github.com>
References: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
 <UNPXEPP2riZD-ACHcAi4ufkMSTlYAdflswGXxYl8RLc=.2662d8f4-e034-4da2-998a-c43fe78e89f6@github.com>
Message-ID: <tliN-EYvaMYLnS7BXo4UqE1-ExxcOXVK2tQp9cxCfys=.9b7b2397-5b26-46b2-98f8-4f8b2c46492f@github.com>

On Tue, 24 Feb 2026 05:06:12 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
>> 
>> With Float16 we need to differentiate b/w vector lane element type and carrier type. while element type corresponds to exact type of lane i.e. Float16.class, carrier type corresponds to the storage type required to propagate IEEE 754 float16 values to inline expander.
>> 
>> Patch adds a new carrier type to existing LaneType structure and use it for following purpose.
>>  - To compute preferred shape of vector.
>>  - To allocate vector backing storage during dummy vector and iota array creation.
>>  - Sanity checking to ensure vector lane type is a primitive type in inline expander.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolution

Changes requested by liach (Reviewer).

Sure, the C++ code changes look trivially fine.

src/hotspot/share/opto/vectorIntrinsics.cpp line 46:

> 44: 
> 45:   ciField* fd1 = ik->get_field_by_name(ciSymbols::CTYPE_name(), ciSymbols::class_signature(), /* is_static */ true);
> 46:   assert(fd1 != nullptr, "element type info is missing");

We probably need separate asserts for CTYPE and ETYPE now, given these asserts test all fields. Below assert comment should get an update too.

-------------

PR Review: https://git.openjdk.org/jdk/pull/29629#pullrequestreview-3854316943
PR Comment: https://git.openjdk.org/jdk/pull/29629#issuecomment-3959290124
PR Review Comment: https://git.openjdk.org/jdk/pull/29629#discussion_r2853092193

From jpai at openjdk.org  Wed Feb 25 13:50:14 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Feb 2026 13:50:14 GMT
Subject: RFR: 8378631: Update Zlib Data Compression Library to Version
 1.3.2
In-Reply-To: <WUHKAEBCPZKNbyBH11R3vbCIu9ylrK9cuOTZmW2Z29g=.31133f9d-79be-4b69-82a8-ef4f6d660863@github.com>
References: <3ciJz-gZK5MjQx6SSiAgbf4qmBFUYPT-fMjx9mISCEU=.416de52a-c7a3-4ba3-a282-d9130fd6483c@github.com>
 <WUHKAEBCPZKNbyBH11R3vbCIu9ylrK9cuOTZmW2Z29g=.31133f9d-79be-4b69-82a8-ef4f6d660863@github.com>
Message-ID: <OQLRFIM_hSxc-VjHhCOf6124ZH2IWfkHmp5ThqXpXXM=.e25334c6-1a64-47df-8665-ff66493f8272@github.com>

On Wed, 25 Feb 2026 13:28:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> @jaikiran No changes from upstream, right? (ignoring the make file update to compile with -DHAVE_STDARG_H=1). 

That's correct - no changes compared to upstream other than the make file change. The trivial make file changes, in our JDK build, were necessitated due to a change in the upstream code which now relies on these macro values to be 1 for it to include certain functionality from zlib https://github.com/madler/zlib/commit/7108497fda9d4536a1afade7f42266e06dca4488

> Also would be possible to update the PR description to say what testing has been done as the defaults only use the in-tree version on Windows.

I was planning to add that detail when I opened the PR, but I hesitated a bit. I have tested tier1, tier2, tier3 on all platforms in our CI and they all passed fine. But that testing was done a few days back, so I didn't include that detail and instead triggered a new run. I should have the results soon and I'll update here once I have them.

> as the defaults only use the in-tree version on Windows.

The in-tree version also gets used on macosx-aarch64. We were forced to do that because of an extremely hard to debug intermittent failures in zlib that was shipped in macos. Details in https://bugs.openjdk.org/browse/JDK-8286623. So right now, even macosx-aarch64 uses bundled https://github.com/openjdk/jdk/blob/master/make/autoconf/lib-bundled.m4#L219. The original issue that we reported to Apple https://bugs.openjdk.org/browse/JDK-8282954 has reportedly been addressed in macosx 13.x and higher, but we haven't yet decided if we want to go back to that using "system" on that platform.

I also plan to run higher tier tests before integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29916#issuecomment-3959366274

From mark.reinhold at oracle.com  Wed Feb 25 14:03:12 2026
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Wed, 25 Feb 2026 14:03:12 +0000
Subject: New candidate JEP: 531: Lazy Constants (Third Preview)
Message-ID: <20260225140309.74846486@naskeag.niobe.net>

https://openjdk.org/jeps/531

  Summary: Introduce an API for lazy constants, which are objects that
  hold unmodifiable data.  Lazy constants are treated as true constants
  by the JVM, enabling the same performance optimizations that are
  enabled by declaring a field final.  Compared to final fields, however,
  lazy constants offer greater flexibility as to the timing of their
  initialization.  This is a preview API.

- Mark

From alanb at openjdk.org  Wed Feb 25 14:11:36 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 25 Feb 2026 14:11:36 GMT
Subject: RFR: 8378631: Update Zlib Data Compression Library to Version
 1.3.2
In-Reply-To: <3ciJz-gZK5MjQx6SSiAgbf4qmBFUYPT-fMjx9mISCEU=.416de52a-c7a3-4ba3-a282-d9130fd6483c@github.com>
References: <3ciJz-gZK5MjQx6SSiAgbf4qmBFUYPT-fMjx9mISCEU=.416de52a-c7a3-4ba3-a282-d9130fd6483c@github.com>
Message-ID: <PBKgeSbZlmFcG5v79WFKgNfSeu1FxzF4nqZdCOVVKng=.ef3e80e8-61ec-4071-b5d2-5ed808484591@github.com>

On Wed, 25 Feb 2026 12:56:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which upgrades JDK's in-tree zlib code from 1.3.1 to the recently released zlib 1.3.2 version?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8378631, then changes between the upstream zlib 1.3.1 and 1.3.2 are available here https://github.com/madler/zlib/compare/v1.3.1...v1.3.2.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29916#pullrequestreview-3854500706

From alanb at openjdk.org  Wed Feb 25 14:11:38 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 25 Feb 2026 14:11:38 GMT
Subject: RFR: 8378631: Update Zlib Data Compression Library to Version
 1.3.2
In-Reply-To: <OQLRFIM_hSxc-VjHhCOf6124ZH2IWfkHmp5ThqXpXXM=.e25334c6-1a64-47df-8665-ff66493f8272@github.com>
References: <3ciJz-gZK5MjQx6SSiAgbf4qmBFUYPT-fMjx9mISCEU=.416de52a-c7a3-4ba3-a282-d9130fd6483c@github.com>
 <WUHKAEBCPZKNbyBH11R3vbCIu9ylrK9cuOTZmW2Z29g=.31133f9d-79be-4b69-82a8-ef4f6d660863@github.com>
 <OQLRFIM_hSxc-VjHhCOf6124ZH2IWfkHmp5ThqXpXXM=.e25334c6-1a64-47df-8665-ff66493f8272@github.com>
Message-ID: <LSxsa4GcDEAEa8aEuweg5L7-_K4Sq3bCtu9jCbrGeR8=.72b3167f-1c23-4730-8031-29e756d74621@github.com>

On Wed, 25 Feb 2026 13:47:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The in-tree version also gets used on macosx-aarch64. 

Ah okay, I thought we had reverted that when Apple fixed the bug. In that case it is at least compiled with VC++ and clang.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29916#issuecomment-3959493808

From erikj at openjdk.org  Wed Feb 25 14:30:35 2026
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 25 Feb 2026 14:30:35 GMT
Subject: RFR: 8378631: Update Zlib Data Compression Library to Version
 1.3.2
In-Reply-To: <3ciJz-gZK5MjQx6SSiAgbf4qmBFUYPT-fMjx9mISCEU=.416de52a-c7a3-4ba3-a282-d9130fd6483c@github.com>
References: <3ciJz-gZK5MjQx6SSiAgbf4qmBFUYPT-fMjx9mISCEU=.416de52a-c7a3-4ba3-a282-d9130fd6483c@github.com>
Message-ID: <00W_Ke7AYJBRJmdcZksveYrQtsXn4YyjiruqLoMqaYQ=.b21c52da-033a-492e-aa76-9d7aa7c1253f@github.com>

On Wed, 25 Feb 2026 12:56:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which upgrades JDK's in-tree zlib code from 1.3.1 to the recently released zlib 1.3.2 version?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8378631, then changes between the upstream zlib 1.3.1 and 1.3.2 are available here https://github.com/madler/zlib/compare/v1.3.1...v1.3.2.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29916#pullrequestreview-3854620932

From eirbjo at gmail.com  Wed Feb 25 15:08:57 2026
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Wed, 25 Feb 2026 16:08:57 +0100
Subject: [External] : RFD: Specializing ArrayDeque copy constructor for
 ArrayDeque (and possibly ArrayList)
Message-ID: <CA+pBWhu23tXCpFqWxBoUf4XzATobtQxVjMkdZ_1KWDmeZ+v5Tw@mail.gmail.com>

Hi,

While looking into ArrayDeque::addElements recently, I noticed that the
copy constructor ArrayDeque(Collection) does not specialize for an
ArrayDeque being passed in a similar fashion to what ArrayList does.

By utilizing the ArrayListBulkOpsBenchmark and adopting it for ArrayDeque,
I was able to test the performance impact of specializing
ArrayDeque(Collection) for ArrayDeque.

Results show a reduction in time/op ranging from 30% (1 element) to 75% (75
elements).

I also experimented with a similar specialization for ArrayList which shows
promising results, up to 50% faster for lists of size 75.

However, there are many collections in the JDK and which combinations to
specialize for is not obvious. Is further exploration here worthwhile?

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260225/77d73806/attachment-0001.htm>

From chen.l.liang at oracle.com  Wed Feb 25 15:31:46 2026
From: chen.l.liang at oracle.com (Chen Liang)
Date: Wed, 25 Feb 2026 15:31:46 +0000
Subject: [External] : RFD: Specializing ArrayDeque copy constructor for
 ArrayDeque (and possibly ArrayList)
In-Reply-To: <CA+pBWhu23tXCpFqWxBoUf4XzATobtQxVjMkdZ_1KWDmeZ+v5Tw@mail.gmail.com>
References: <CA+pBWhu23tXCpFqWxBoUf4XzATobtQxVjMkdZ_1KWDmeZ+v5Tw@mail.gmail.com>
Message-ID: <SJ2PR10MB7669EEAE654CA30CC89BE1FDA275A@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hello Eirik, this is a general problem caused by type profile pollution in bytecode of these constructors so that virtual calls become slow, fully virtual calls. I do not think this site is used frequent enough that warrants a monkey patch like that in ArrayList; such monkey patches will be removed in the future shall the JVM provide a better specialization solution.

If you want to learn more about how type profile pollution works, feel free to check out the patch for https://bugs.openjdk.org/browse/JDK-8366424, where there's a benchmark that explains how all these pollutions happen.

Regards,
Chen Liang
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Eirik Bj?rsn?s <eirbjo at gmail.com>
Sent: Wednesday, February 25, 2026 9:08 AM
To: core-libs-dev <core-libs-dev at openjdk.org>
Subject: [External] : RFD: Specializing ArrayDeque copy constructor for ArrayDeque (and possibly ArrayList)

Hi, While looking into ArrayDeque:?:?addElements recently, I noticed that the copy constructor ArrayDeque(Collection) does not specialize for an ArrayDeque being passed in a similar fashion to what ArrayList does. By utilizing the ArrayListBulkOpsBenchmark
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/ACWV5N9M2RV99hQ!Op20OCpm1CSlHTAAv166s1TUpoWxmKY80Fp0sfkRpwj3IiVbBFywyh2YCoQcpFBR61255FrMKi3x_VMgCQbiIMhr3epTsIh7u6f_8RvkbTHciw10cvaXUBuMqLQ0-59vRQ$>
Report Suspicious

ZjQcmQRYFpfptBannerEnd
Hi,

While looking into ArrayDeque::addElements recently, I noticed that the copy constructor ArrayDeque(Collection) does not specialize for an ArrayDeque being passed in a similar fashion to what ArrayList does.

By utilizing the ArrayListBulkOpsBenchmark and adopting it for ArrayDeque, I was able to test the performance impact of specializing ArrayDeque(Collection) for ArrayDeque.

Results show a reduction in time/op ranging from 30% (1 element) to 75% (75 elements).

I also experimented with a similar specialization for ArrayList which shows promising results, up to 50% faster for lists of size 75.

However, there are many collections in the JDK and which combinations to specialize for is not obvious. Is further exploration here worthwhile?

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260225/703b8ef9/attachment.htm>

From jbhateja at openjdk.org  Wed Feb 25 15:35:49 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 25 Feb 2026 15:35:49 GMT
Subject: RFR: 8377438: [VectorAPI] Add new carrier type to LaneType class
 [v3]
In-Reply-To: <tliN-EYvaMYLnS7BXo4UqE1-ExxcOXVK2tQp9cxCfys=.9b7b2397-5b26-46b2-98f8-4f8b2c46492f@github.com>
References: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
 <UNPXEPP2riZD-ACHcAi4ufkMSTlYAdflswGXxYl8RLc=.2662d8f4-e034-4da2-998a-c43fe78e89f6@github.com>
 <tliN-EYvaMYLnS7BXo4UqE1-ExxcOXVK2tQp9cxCfys=.9b7b2397-5b26-46b2-98f8-4f8b2c46492f@github.com>
Message-ID: <qNIYBz46IjJYSTkoZkvVioiVM-s40hUcpR-nf1VGWrM=.14474012-1514-4643-a366-bc5d79903089@github.com>

On Wed, 25 Feb 2026 13:36:00 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolution
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 46:
> 
>> 44: 
>> 45:   ciField* fd1 = ik->get_field_by_name(ciSymbols::CTYPE_name(), ciSymbols::class_signature(), /* is_static */ true);
>> 46:   assert(fd1 != nullptr, "element type info is missing");
> 
> We probably need separate asserts for CTYPE and ETYPE now, given these asserts test all fields. Below assert comment should get an update too.

CTYPE is carrier type and it must be a java primitive type, In addition we have replaced ETYPE field with CTYPE from all concrete shuffle and mask classes. Thus CTYPE field primarily exists in all concrete mask / shuffle and vector classes and its type is being checked here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29629#discussion_r2853747571

From liach at openjdk.org  Wed Feb 25 15:44:10 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Feb 2026 15:44:10 GMT
Subject: RFR: 8377438: [VectorAPI] Add new carrier type to LaneType class
 [v3]
In-Reply-To: <UNPXEPP2riZD-ACHcAi4ufkMSTlYAdflswGXxYl8RLc=.2662d8f4-e034-4da2-998a-c43fe78e89f6@github.com>
References: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
 <UNPXEPP2riZD-ACHcAi4ufkMSTlYAdflswGXxYl8RLc=.2662d8f4-e034-4da2-998a-c43fe78e89f6@github.com>
Message-ID: <_TBg2G8GD_60cgGiiC_7mF--ca0Jhle-qrjQVYzrQcU=.c1faf013-6e06-41df-a73f-6f448357b87b@github.com>

On Tue, 24 Feb 2026 05:06:12 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
>> 
>> With Float16 we need to differentiate b/w vector lane element type and carrier type. while element type corresponds to exact type of lane i.e. Float16.class, carrier type corresponds to the storage type required to propagate IEEE 754 float16 values to inline expander.
>> 
>> Patch adds a new carrier type to existing LaneType structure and use it for following purpose.
>>  - To compute preferred shape of vector.
>>  - To allocate vector backing storage during dummy vector and iota array creation.
>>  - Sanity checking to ensure vector lane type is a primitive type in inline expander.
>> 
>> All existing Vector API jtreg test are passing with the patch.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolution

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29629#pullrequestreview-3855100781

From liach at openjdk.org  Wed Feb 25 15:44:12 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Feb 2026 15:44:12 GMT
Subject: RFR: 8377438: [VectorAPI] Add new carrier type to LaneType class
 [v3]
In-Reply-To: <qNIYBz46IjJYSTkoZkvVioiVM-s40hUcpR-nf1VGWrM=.14474012-1514-4643-a366-bc5d79903089@github.com>
References: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
 <UNPXEPP2riZD-ACHcAi4ufkMSTlYAdflswGXxYl8RLc=.2662d8f4-e034-4da2-998a-c43fe78e89f6@github.com>
 <tliN-EYvaMYLnS7BXo4UqE1-ExxcOXVK2tQp9cxCfys=.9b7b2397-5b26-46b2-98f8-4f8b2c46492f@github.com>
 <qNIYBz46IjJYSTkoZkvVioiVM-s40hUcpR-nf1VGWrM=.14474012-1514-4643-a366-bc5d79903089@github.com>
Message-ID: <Eqbz8JSeC3emBAtbwynuRDpWQYy5JSjaWY0gYe7WZ4s=.4ed2d571-28ab-444b-ad3e-3af6e11fd0b6@github.com>

On Wed, 25 Feb 2026 15:31:15 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 46:
>> 
>>> 44: 
>>> 45:   ciField* fd1 = ik->get_field_by_name(ciSymbols::CTYPE_name(), ciSymbols::class_signature(), /* is_static */ true);
>>> 46:   assert(fd1 != nullptr, "element type info is missing");
>> 
>> We probably need separate asserts for CTYPE and ETYPE now, given these asserts test all fields. Below assert comment should get an update too.
>
> CTYPE is carrier type and it must be a java primitive type, In addition we have replaced ETYPE field with CTYPE from all concrete shuffle and mask classes. Thus CTYPE field primarily exists in all concrete mask / shuffle and vector classes and its type is being checked here.

Indeed you are right. My bad.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29629#discussion_r2853810084

From duke at openjdk.org  Wed Feb 25 15:44:47 2026
From: duke at openjdk.org (Patrick Strawderman)
Date: Wed, 25 Feb 2026 15:44:47 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString
Message-ID: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>

Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes

-------------

Commit messages:
 - 8378698: Optimize Base64.Encoder#encodeToString

Changes: https://git.openjdk.org/jdk/pull/29920/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29920&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378698
  Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29920.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29920/head:pull/29920

PR: https://git.openjdk.org/jdk/pull/29920

From liach at openjdk.org  Wed Feb 25 15:50:22 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Feb 2026 15:50:22 GMT
Subject: RFR: 8376234: Migrate java/lang/constant tests away from TestNG
 [v2]
In-Reply-To: <MobsfNg55aFe_062RkMD64eBU1IWAHZDX9kWIYqqWBc=.9c9e3409-5c1a-4029-9b80-dcc1f5aabb26@github.com>
References: <OdyavIz4EF19kdDjM05Un-d0XGg3SNisPGcF_WHvAb4=.b26f0248-eb76-47df-9505-9690c8206b2d@github.com>
 <MobsfNg55aFe_062RkMD64eBU1IWAHZDX9kWIYqqWBc=.9c9e3409-5c1a-4029-9b80-dcc1f5aabb26@github.com>
Message-ID: <-Gn4XZ55nx7_6PFioD3Opfu_fQb78ItHyUlOC4MGVPg=.89c5abdf-d732-41fe-bee6-76735af2d5f7@github.com>

On Mon, 23 Feb 2026 16:22:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Convert all TestNG tests in java/lang/constant to JUnit tests.
>
> 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:
> 
>  - Reviews
>  - Merge branch 'master' of https://github.com/openjdk/jdk into test/constant-no-testng
>  - Bugs in migration
>  - No testng in constant

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29396#issuecomment-3960204059

From liach at openjdk.org  Wed Feb 25 15:50:24 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Feb 2026 15:50:24 GMT
Subject: Integrated: 8376234: Migrate java/lang/constant tests away from TestNG
In-Reply-To: <OdyavIz4EF19kdDjM05Un-d0XGg3SNisPGcF_WHvAb4=.b26f0248-eb76-47df-9505-9690c8206b2d@github.com>
References: <OdyavIz4EF19kdDjM05Un-d0XGg3SNisPGcF_WHvAb4=.b26f0248-eb76-47df-9505-9690c8206b2d@github.com>
Message-ID: <J_2nr-yoPhT9FJ7Aoi77uy1wV4aU-UnlFi7q0padP6A=.71697d75-1515-4244-ab1a-273907ce7f65@github.com>

On Fri, 23 Jan 2026 22:10:06 GMT, Chen Liang <liach at openjdk.org> wrote:

> Convert all TestNG tests in java/lang/constant to JUnit tests.

This pull request has now been integrated.

Changeset: 5a59ed68
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a59ed68f973b74a5bc19bf6babd4c20ecc39b04
Stats:     734 lines in 15 files changed: 138 ins; 316 del; 280 mod

8376234: Migrate java/lang/constant tests away from TestNG

Reviewed-by: rriggs, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/29396

From liach at openjdk.org  Wed Feb 25 16:04:17 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Feb 2026 16:04:17 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString
In-Reply-To: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
Message-ID: <3YXAU80lmhvhAl0zwwAijFhx78u1bAq7vPRv5qvioTk=.97e51d4e-9f0c-4662-882b-3b1277a8184f@github.com>

On Wed, 25 Feb 2026 15:37:02 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes

Hmm, I checked the code of that deprecated constructor. If the compiler can recognize `count == ascii.length` then it should be able to fold this code; maybe the compiler is too stupid. Have you verified the performance results in a benchmark?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29920#issuecomment-3960288227

From jbhateja at openjdk.org  Wed Feb 25 16:05:27 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 25 Feb 2026 16:05:27 GMT
Subject: RFR: 8377438: [VectorAPI] Add new carrier type to LaneType class
 [v3]
In-Reply-To: <cxWM_VZx6dC7aaymt6Tb3vTUs8XK-VoDDbRkE9Th0fI=.c3c55e51-13b7-4736-ba32-96be4c20a272@github.com>
References: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
 <UNPXEPP2riZD-ACHcAi4ufkMSTlYAdflswGXxYl8RLc=.2662d8f4-e034-4da2-998a-c43fe78e89f6@github.com>
 <cxWM_VZx6dC7aaymt6Tb3vTUs8XK-VoDDbRkE9Th0fI=.c3c55e51-13b7-4736-ba32-96be4c20a272@github.com>
Message-ID: <yL0qk04WRH6auNsH6LvhzJ3SKfIICcPZXLq8Gj3c0W4=.9e1e9433-67a2-48d6-8df1-e4ff65c6567c@github.com>

On Wed, 25 Feb 2026 00:37:02 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolution
>
> Looks good. We shall run it though tier 1 to 3 tests. Needs another HotSpot reviewer.

Thanks @PaulSandoz and @liach for review and approvals.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29629#issuecomment-3960274986

From jbhateja at openjdk.org  Wed Feb 25 16:05:29 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 25 Feb 2026 16:05:29 GMT
Subject: Integrated: 8377438: [VectorAPI] Add new carrier type to LaneType
 class
In-Reply-To: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
References: <XkFOX-CVGvzGxQ1Yv6EwbE8TLJui2kLVH7qoprUGggs=.3b0cd5f1-0e15-47cf-aaf4-086fe4bd370b@github.com>
Message-ID: <EIUD4sCx9SOrsBbxht9VrSashaUjo85EDM983ZpIlKM=.6eeeda0b-cbdb-42f5-a663-b66c7884c29e@github.com>

On Mon, 9 Feb 2026 07:37:03 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch.
> 
> With Float16 we need to differentiate b/w vector lane element type and carrier type. while element type corresponds to exact type of lane i.e. Float16.class, carrier type corresponds to the storage type required to propagate IEEE 754 float16 values to inline expander.
> 
> Patch adds a new carrier type to existing LaneType structure and use it for following purpose.
>  - To compute preferred shape of vector.
>  - To allocate vector backing storage during dummy vector and iota array creation.
>  - Sanity checking to ensure vector lane type is a primitive type in inline expander.
> 
> All existing Vector API jtreg test are passing with the patch.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

This pull request has now been integrated.

Changeset: 8af95879
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8af95879f3a74e1b6e419305e1db85e9c14972db
Stats:     320 lines in 38 files changed: 235 ins; 1 del; 84 mod

8377438: [VectorAPI] Add new carrier type to LaneType class

Reviewed-by: psandoz, liach

-------------

PR: https://git.openjdk.org/jdk/pull/29629

From lancea at openjdk.org  Wed Feb 25 16:07:36 2026
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 25 Feb 2026 16:07:36 GMT
Subject: RFR: 8378631: Update Zlib Data Compression Library to Version
 1.3.2
In-Reply-To: <3ciJz-gZK5MjQx6SSiAgbf4qmBFUYPT-fMjx9mISCEU=.416de52a-c7a3-4ba3-a282-d9130fd6483c@github.com>
References: <3ciJz-gZK5MjQx6SSiAgbf4qmBFUYPT-fMjx9mISCEU=.416de52a-c7a3-4ba3-a282-d9130fd6483c@github.com>
Message-ID: <0e6nLFfo6zj7_8FQxdKLq2sJsVHOmVi_otinCSClgQI=.f9dd8776-3a0b-4528-b237-fd912e2cf960@github.com>

On Wed, 25 Feb 2026 12:56:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which upgrades JDK's in-tree zlib code from 1.3.1 to the recently released zlib 1.3.2 version?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8378631, then changes between the upstream zlib 1.3.1 and 1.3.2 are available here https://github.com/madler/zlib/compare/v1.3.1...v1.3.2.

Thank you Jai.  The changes look good and are in sync with the zlib repository.

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29916#pullrequestreview-3855237924

From liach at openjdk.org  Wed Feb 25 16:17:27 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Feb 2026 16:17:27 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString
In-Reply-To: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
Message-ID: <UkOcou398k_8luofRJvXMMk9Lz0WR_SkvFBcjQVOd84=.f4378155-8884-4ea8-bd55-c2002d66281f@github.com>

On Wed, 25 Feb 2026 15:37:02 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes

Turns out this is necessary per https://bugs.openjdk.org/browse/JDK-8364418

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29920#pullrequestreview-3855286622

From liach at openjdk.org  Wed Feb 25 16:22:11 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Feb 2026 16:22:11 GMT
Subject: RFR: 8378700: Migrate lang/annotation tests away from TestNG
Message-ID: <nd3ZXsCVX5cWNzCYZ6NeBDnLospTyTNe14pvKkX3924=.41b64c29-a895-42e1-ad78-21cd25b2b0fd@github.com>

Remove the use of TestNG from java/lang/annotation tests.
Interesting that JUnit scans annotations on member classes, so we can't put malformed annotations on classes nested in the test class; we can put them on package-private classes in the same source file instead.
Also refactored LoaderLeakTest to perform GC more reliably within our test framework.

-------------

Commit messages:
 - Remove testng from annotation package

Changes: https://git.openjdk.org/jdk/pull/29921/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29921&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378700
  Stats: 309 lines in 7 files changed: 88 ins; 119 del; 102 mod
  Patch: https://git.openjdk.org/jdk/pull/29921.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29921/head:pull/29921

PR: https://git.openjdk.org/jdk/pull/29921

From rriggs at openjdk.org  Wed Feb 25 16:43:06 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 25 Feb 2026 16:43:06 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
Message-ID: <Hi52ETH_emxWdjA51Ld1PtTTW6HXFpAhzB37VFJnJFI=.051397c8-9346-4554-b603-00ae2f2afdc1@github.com>

On Fri, 30 Jan 2026 15:56:20 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background.
>> 
>> ---
>> 
>> 
>> Benchmark                              (encoding)  (stringLength)   Mode  Cnt          Score          Error  Units
>> StringLoopJmhBenchmark.getBytes             ASCII              10  thrpt    5  406782650.595 ? 16960032.852  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII             100  thrpt    5  172936926.189 ?  4532029.201  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII            1000  thrpt    5   38830681.232 ?  2413274.766  ops/s
>> StringLoopJmhBenchmark.getBytes             ASCII          100000  thrpt    5     458881.155 ?    12818.317  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1              10  thrpt    5   37193762.990 ?  3962947.391  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1             100  thrpt    5   55400876.236 ?  1267331.434  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1            1000  thrpt    5   11104514.001 ?    41718.545  ops/s
>> StringLoopJmhBenchmark.getBytes            LATIN1          100000  thrpt    5     182535.414 ?    10296.120  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16              10  thrpt    5  113474681.457 ?  8326589.199  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16             100  thrpt    5   37854103.127 ?  4808526.773  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16            1000  thrpt    5    4139833.009 ?    70636.784  ops/s
>> StringLoopJmhBenchmark.getBytes             UTF16          100000  thrpt    5      57644.637 ?     1887.112  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII              10  thrpt    5  946701647.247 ? 76938927.141  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII             100  thrpt    5  396615374.479 ? 15167234.884  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII            1000  thrpt    5  100464784.979 ?   794027.897  ops/s
>> StringLoopJmhBenchmark.getBytesLength       ASCII          100000  thrpt    5    1215487.689 ?     1916.468  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1              10  thrpt    5  221265102.323 ? 17013983.056  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1             100  thrpt    5  137617873.887 ?  5842185.781  ops/s
>> StringLoopJmhBenchmark.getBytesLength      LATIN1            1000  thrpt    5   92540259.1...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename getBytesLength to getByteLength

Changes requested by rriggs (Reviewer).

src/java.base/share/classes/java/lang/String.java line 2119:

> 2117:      * @since 27
> 2118:      */
> 2119:     public int getByteLength(Charset cs) {

`getEncodedLength(Charset cs)` is a stronger name, more evocative of the value being computed.
The name should not rely on the argument to hint at its primary function.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28454#pullrequestreview-3855437273
PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2854125849

From liach at openjdk.org  Wed Feb 25 16:59:36 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Feb 2026 16:59:36 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <Hi52ETH_emxWdjA51Ld1PtTTW6HXFpAhzB37VFJnJFI=.051397c8-9346-4554-b603-00ae2f2afdc1@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
 <Hi52ETH_emxWdjA51Ld1PtTTW6HXFpAhzB37VFJnJFI=.051397c8-9346-4554-b603-00ae2f2afdc1@github.com>
Message-ID: <hJuPAEwfqZFHSDS77TKsB-IHC49LgC1FV9H04TYRjDM=.cd10b45f-26b2-48dd-8194-8d6f3710c9c8@github.com>

On Wed, 25 Feb 2026 16:39:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename getBytesLength to getByteLength
>
> src/java.base/share/classes/java/lang/String.java line 2119:
> 
>> 2117:      * @since 27
>> 2118:      */
>> 2119:     public int getByteLength(Charset cs) {
> 
> `getEncodedLength(Charset cs)` is a stronger name, more evocative of the value being computed.
> The name should not rely on the argument to hint at its primary function.

Or `encodedLength` to be consistent with the other queries.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2854220759

From cushon at openjdk.org  Wed Feb 25 17:04:40 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 25 Feb 2026 17:04:40 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v18]
In-Reply-To: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
Message-ID: <ym74y7FXQ1La5DL8f07fNNjWMwR9u0hDAfunkOfvAiw=.1d8b7e18-4ccc-4769-a5d2-8039723943b5@github.com>

> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background.
> 
> ---
> 
> 
> Benchmark                              (encoding)  (stringLength)   Mode  Cnt          Score          Error  Units
> StringLoopJmhBenchmark.getBytes             ASCII              10  thrpt    5  406782650.595 ? 16960032.852  ops/s
> StringLoopJmhBenchmark.getBytes             ASCII             100  thrpt    5  172936926.189 ?  4532029.201  ops/s
> StringLoopJmhBenchmark.getBytes             ASCII            1000  thrpt    5   38830681.232 ?  2413274.766  ops/s
> StringLoopJmhBenchmark.getBytes             ASCII          100000  thrpt    5     458881.155 ?    12818.317  ops/s
> StringLoopJmhBenchmark.getBytes            LATIN1              10  thrpt    5   37193762.990 ?  3962947.391  ops/s
> StringLoopJmhBenchmark.getBytes            LATIN1             100  thrpt    5   55400876.236 ?  1267331.434  ops/s
> StringLoopJmhBenchmark.getBytes            LATIN1            1000  thrpt    5   11104514.001 ?    41718.545  ops/s
> StringLoopJmhBenchmark.getBytes            LATIN1          100000  thrpt    5     182535.414 ?    10296.120  ops/s
> StringLoopJmhBenchmark.getBytes             UTF16              10  thrpt    5  113474681.457 ?  8326589.199  ops/s
> StringLoopJmhBenchmark.getBytes             UTF16             100  thrpt    5   37854103.127 ?  4808526.773  ops/s
> StringLoopJmhBenchmark.getBytes             UTF16            1000  thrpt    5    4139833.009 ?    70636.784  ops/s
> StringLoopJmhBenchmark.getBytes             UTF16          100000  thrpt    5      57644.637 ?     1887.112  ops/s
> StringLoopJmhBenchmark.getBytesLength       ASCII              10  thrpt    5  946701647.247 ? 76938927.141  ops/s
> StringLoopJmhBenchmark.getBytesLength       ASCII             100  thrpt    5  396615374.479 ? 15167234.884  ops/s
> StringLoopJmhBenchmark.getBytesLength       ASCII            1000  thrpt    5  100464784.979 ?   794027.897  ops/s
> StringLoopJmhBenchmark.getBytesLength       ASCII          100000  thrpt    5    1215487.689 ?     1916.468  ops/s
> StringLoopJmhBenchmark.getBytesLength      LATIN1              10  thrpt    5  221265102.323 ? 17013983.056  ops/s
> StringLoopJmhBenchmark.getBytesLength      LATIN1             100  thrpt    5  137617873.887 ?  5842185.781  ops/s
> StringLoopJmhBenchmark.getBytesLength      LATIN1            1000  thrpt    5   92540259.130 ?  3839233.582  ops/s
> StringLoopJmhBenchmark.ge...

Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:

 - Rename to getEncodedLength
 - Merge remote-tracking branch 'origin/master' into strlen
 - Rename getBytesLength to getByteLength
 - Update javadoc to refer to 'this {@code String}', not 'the given String'
 - Clarify that "It" in the javadoc means "This method"
 - Remove paragraph break
 - Add a note about malformed-input and unmappable-character sequences
 - Merge and optimize latin1 and ascii paths
 - Switch to @apiNote
 - implNote
 - ... and 11 more: https://git.openjdk.org/jdk/compare/530d1875...e04a5c1a

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28454/files
  - new: https://git.openjdk.org/jdk/pull/28454/files/f23b5c24..e04a5c1a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=16-17

  Stats: 598371 lines in 2888 files changed: 302559 ins; 263341 del; 32471 mod
  Patch: https://git.openjdk.org/jdk/pull/28454.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454

PR: https://git.openjdk.org/jdk/pull/28454

From cushon at openjdk.org  Wed Feb 25 17:04:44 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 25 Feb 2026 17:04:44 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <Hi52ETH_emxWdjA51Ld1PtTTW6HXFpAhzB37VFJnJFI=.051397c8-9346-4554-b603-00ae2f2afdc1@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
 <Hi52ETH_emxWdjA51Ld1PtTTW6HXFpAhzB37VFJnJFI=.051397c8-9346-4554-b603-00ae2f2afdc1@github.com>
Message-ID: <BIkw3JGC7fibl-1YYxgksnYE1HLFknQx77OZjbHaZco=.60a431ea-ce00-46eb-a1bf-2fda0416a868@github.com>

On Wed, 25 Feb 2026 16:39:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename getBytesLength to getByteLength
>
> src/java.base/share/classes/java/lang/String.java line 2119:
> 
>> 2117:      * @since 27
>> 2118:      */
>> 2119:     public int getByteLength(Charset cs) {
> 
> `getEncodedLength(Charset cs)` is a stronger name, more evocative of the value being computed.
> The name should not rely on the argument to hint at its primary function.

Thanks @RogerRiggs and @liach, I've started updating the CSR and will make the changes in the PR to rename it from `getByteLength`.

I wasn't sure what the overall approach is for JDK APIs of when to include a `get` prefix. I think that either `getEncodedLength(Charset cs)` or `encodedLength(Charset cs)` are good options, happy to go with whichever the Core Libraries team thinks is best :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2854242033

From rriggs at openjdk.org  Wed Feb 25 17:24:19 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 25 Feb 2026 17:24:19 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <BIkw3JGC7fibl-1YYxgksnYE1HLFknQx77OZjbHaZco=.60a431ea-ce00-46eb-a1bf-2fda0416a868@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
 <Hi52ETH_emxWdjA51Ld1PtTTW6HXFpAhzB37VFJnJFI=.051397c8-9346-4554-b603-00ae2f2afdc1@github.com>
 <BIkw3JGC7fibl-1YYxgksnYE1HLFknQx77OZjbHaZco=.60a431ea-ce00-46eb-a1bf-2fda0416a868@github.com>
Message-ID: <dOyUIFCE04DB5tyzxCz6O-V93DowK53CPFky7_VmNlo=.8944c08e-8efd-47c8-b9fc-e91310456bf3@github.com>

On Wed, 25 Feb 2026 17:00:39 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 2119:
>> 
>>> 2117:      * @since 27
>>> 2118:      */
>>> 2119:     public int getByteLength(Charset cs) {
>> 
>> `getEncodedLength(Charset cs)` is a stronger name, more evocative of the value being computed.
>> The name should not rely on the argument to hint at its primary function.
>
> Thanks @RogerRiggs and @liach, I've started updating the CSR and will make the changes in the PR to rename it from `getByteLength`.
> 
> I wasn't sure what the overall approach is for JDK APIs of when to include a `get` prefix. I think that either `getEncodedLength(Charset cs)` or `encodedLength(Charset cs)` are good options, happy to go with whichever the Core Libraries team thinks is best :)

I agree that `encodedLength(cs)` is a cleaner name and consistent with more of the String API.
The `get` was a carry over from the original method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2854340559

From psandoz at openjdk.org  Wed Feb 25 17:33:39 2026
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 25 Feb 2026 17:33:39 GMT
Subject: RFR: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to
 intrinsify [v4]
In-Reply-To: <3Cj-8Ae4bGQs6soTjbPTNeOK1p6owLuGAVk72PySAZk=.a1527cf4-bf4d-4e02-89aa-81a578ca2dbb@github.com>
References: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
 <3Cj-8Ae4bGQs6soTjbPTNeOK1p6owLuGAVk72PySAZk=.a1527cf4-bf4d-4e02-89aa-81a578ca2dbb@github.com>
Message-ID: <CQ22AZNHubAeRj_PJcRJP0q1WgEeSKTni3PpioadWfQ=.1a6eee46-d737-4950-8304-d5ff18abae12@github.com>

On Wed, 25 Feb 2026 11:05:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I ran following code with `-Djdk.incubator.vector.DEBUG=true`, however it was not intrinsified.
>> 
>> 
>>   public static void cos(){
>>     var rand = new Random();
>>     for(int i = 0; i < 1_000_000; i++){
>>       var vec = DoubleVector.fromArray(DoubleVector.SPECIES_256, rand.doubles().limit(4).toArray(), 0);
>> 
>>       vec.lanewise(VectorOperators.COS);
>>     }
>>   }
>> 
>> 
>> I knew `__jsvml_cos4_ha_l9()` in libjsvml.so should be called in this case (via vector debug log), but it was not hitted even though I set breakpoint in it.
>> 
>> `LaneType` has been introduced in [JDK-8376187](https://bugs.openjdk.org/browse/JDK-8376187), and `LibraryCallKit::inline_vector_call()` was updated to handle lane type rather than class of element type. However `VectorMathLibrary` wasn't modified.
>> 
>> I confirmed `__jsvml_cos4_ha_l9()` is called with this fix, and also all jdk/jdk/incubator/vector jtreg tests passed on Linux AMD64.
>
> Yasumasa Suenaga has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unnecesary file
>  - Update testcase
>  - Add comment

This looks good. Before integrating we will run that test through our system. It will need a HostSpot reviewer.

-------------

PR Review: https://git.openjdk.org/jdk/pull/29835#pullrequestreview-3855714108

From cushon at openjdk.org  Wed Feb 25 17:34:09 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 25 Feb 2026 17:34:09 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v19]
In-Reply-To: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
Message-ID: <iPwchbShqcIQKN0G2BmJfsSbhHSa8grHTYbjBeek2j4=.2a05ac81-74f7-45e7-83c2-2f00908b9c3f@github.com>

> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background.
> 
> ---
> 
> 
> Benchmark                              (encoding)  (stringLength)   Mode  Cnt          Score          Error  Units
> StringLoopJmhBenchmark.getBytes             ASCII              10  thrpt    5  406782650.595 ? 16960032.852  ops/s
> StringLoopJmhBenchmark.getBytes             ASCII             100  thrpt    5  172936926.189 ?  4532029.201  ops/s
> StringLoopJmhBenchmark.getBytes             ASCII            1000  thrpt    5   38830681.232 ?  2413274.766  ops/s
> StringLoopJmhBenchmark.getBytes             ASCII          100000  thrpt    5     458881.155 ?    12818.317  ops/s
> StringLoopJmhBenchmark.getBytes            LATIN1              10  thrpt    5   37193762.990 ?  3962947.391  ops/s
> StringLoopJmhBenchmark.getBytes            LATIN1             100  thrpt    5   55400876.236 ?  1267331.434  ops/s
> StringLoopJmhBenchmark.getBytes            LATIN1            1000  thrpt    5   11104514.001 ?    41718.545  ops/s
> StringLoopJmhBenchmark.getBytes            LATIN1          100000  thrpt    5     182535.414 ?    10296.120  ops/s
> StringLoopJmhBenchmark.getBytes             UTF16              10  thrpt    5  113474681.457 ?  8326589.199  ops/s
> StringLoopJmhBenchmark.getBytes             UTF16             100  thrpt    5   37854103.127 ?  4808526.773  ops/s
> StringLoopJmhBenchmark.getBytes             UTF16            1000  thrpt    5    4139833.009 ?    70636.784  ops/s
> StringLoopJmhBenchmark.getBytes             UTF16          100000  thrpt    5      57644.637 ?     1887.112  ops/s
> StringLoopJmhBenchmark.getBytesLength       ASCII              10  thrpt    5  946701647.247 ? 76938927.141  ops/s
> StringLoopJmhBenchmark.getBytesLength       ASCII             100  thrpt    5  396615374.479 ? 15167234.884  ops/s
> StringLoopJmhBenchmark.getBytesLength       ASCII            1000  thrpt    5  100464784.979 ?   794027.897  ops/s
> StringLoopJmhBenchmark.getBytesLength       ASCII          100000  thrpt    5    1215487.689 ?     1916.468  ops/s
> StringLoopJmhBenchmark.getBytesLength      LATIN1              10  thrpt    5  221265102.323 ? 17013983.056  ops/s
> StringLoopJmhBenchmark.getBytesLength      LATIN1             100  thrpt    5  137617873.887 ?  5842185.781  ops/s
> StringLoopJmhBenchmark.getBytesLength      LATIN1            1000  thrpt    5   92540259.130 ?  3839233.582  ops/s
> StringLoopJmhBenchmark.ge...

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Rename to encodedLength

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28454/files
  - new: https://git.openjdk.org/jdk/pull/28454/files/e04a5c1a..f9505f60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=17-18

  Stats: 15 lines in 5 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/28454.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454

PR: https://git.openjdk.org/jdk/pull/28454

From eirbjo at openjdk.org  Wed Feb 25 17:34:10 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 25 Feb 2026 17:34:10 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <dOyUIFCE04DB5tyzxCz6O-V93DowK53CPFky7_VmNlo=.8944c08e-8efd-47c8-b9fc-e91310456bf3@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
 <Hi52ETH_emxWdjA51Ld1PtTTW6HXFpAhzB37VFJnJFI=.051397c8-9346-4554-b603-00ae2f2afdc1@github.com>
 <BIkw3JGC7fibl-1YYxgksnYE1HLFknQx77OZjbHaZco=.60a431ea-ce00-46eb-a1bf-2fda0416a868@github.com>
 <dOyUIFCE04DB5tyzxCz6O-V93DowK53CPFky7_VmNlo=.8944c08e-8efd-47c8-b9fc-e91310456bf3@github.com>
Message-ID: <LJ3x7NEGzXJ5w_JCh9dEsP6siEsbHl_IV1xy9aI7Kn4=.7b0af56c-4d19-4638-8ea1-07604215d015@github.com>

On Wed, 25 Feb 2026 17:20:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Thanks @RogerRiggs and @liach, I've started updating the CSR and will make the changes in the PR to rename it from `getByteLength`.
>> 
>> I wasn't sure what the overall approach is for JDK APIs of when to include a `get` prefix. I think that either `getEncodedLength(Charset cs)` or `encodedLength(Charset cs)` are good options, happy to go with whichever the Core Libraries team thinks is best :)
>
> I agree that `encodedLength(cs)` is a cleaner name and consistent with more of the String API.
> The `get` was a carry over from the original method.

Reemerging from my armchair to express a small preference for `encodedLength(Charset)`. 

A `get` prefix does not evoke computation to me, usually the contrary in that it may be a simple getter.

Also, local consistency in String in perhaps more important than global consistency in the JDK for this operation. String does not seem to lean much toward `get` prefixes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2854364358

From cushon at openjdk.org  Wed Feb 25 17:34:11 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 25 Feb 2026 17:34:11 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v17]
In-Reply-To: <LJ3x7NEGzXJ5w_JCh9dEsP6siEsbHl_IV1xy9aI7Kn4=.7b0af56c-4d19-4638-8ea1-07604215d015@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
 <WIfwduTdJg9YPewUaSIZ0Di48JM2BAUYrRifoBBFj18=.ec9cc5f2-516e-46bf-a02f-2171b842707c@github.com>
 <Hi52ETH_emxWdjA51Ld1PtTTW6HXFpAhzB37VFJnJFI=.051397c8-9346-4554-b603-00ae2f2afdc1@github.com>
 <BIkw3JGC7fibl-1YYxgksnYE1HLFknQx77OZjbHaZco=.60a431ea-ce00-46eb-a1bf-2fda0416a868@github.com>
 <dOyUIFCE04DB5tyzxCz6O-V93DowK53CPFky7_VmNlo=.8944c08e-8efd-47c8-b9fc-e91310456bf3@github.com>
 <LJ3x7NEGzXJ5w_JCh9dEsP6siEsbHl_IV1xy9aI7Kn4=.7b0af56c-4d19-4638-8ea1-07604215d015@github.com>
Message-ID: <ts_MAxGaYCiHG_zno1hjzVyfmbk9OpAX7_10vespz5U=.a62d75a0-32af-4e71-8fc8-71a75f1de0ad@github.com>

On Wed, 25 Feb 2026 17:25:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> I agree that `encodedLength(cs)` is a cleaner name and consistent with more of the String API.
>> The `get` was a carry over from the original method.
>
> Reemerging from my armchair to express a small preference for `encodedLength(Charset)`. 
> 
> A `get` prefix does not evoke computation to me, usually the contrary in that it may be a simple getter.
> 
> Also, local consistency in String in perhaps more important than global consistency in the JDK for this operation. String does not seem to lean much toward `get` prefixes.

Thank you! I have updated the PR and CSR to `encodedLength`, I will plan on finalizing the CSR soon.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2854390190

From asemenyuk at openjdk.org  Wed Feb 25 17:46:38 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 25 Feb 2026 17:46:38 GMT
Subject: Integrated: 8374222: jpackage will exit with error if it fails to
 clean the temp directory
In-Reply-To: <slkcuguuN_dOz_pjLZs_xVDEy0aGeTjk6BiBs5fawzU=.245d6070-5d05-4d4a-a923-414b4cbe515d@github.com>
References: <slkcuguuN_dOz_pjLZs_xVDEy0aGeTjk6BiBs5fawzU=.245d6070-5d05-4d4a-a923-414b4cbe515d@github.com>
Message-ID: <ZPapYGjy9msbUAosoE6qSulOZ6e0xU5A_Vi1ylvwN7Y=.6e975c7a-29e5-41b9-94c5-c9f960cdfaaa@github.com>

On Wed, 11 Feb 2026 04:13:53 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> jpackage will attempt to delete the temp directory a few times. If all attempts fail, it will print remaining files and empty directories (100 entries at most) to the console and continue. It will not exit with an error status as previously, as this is not a critical error.

This pull request has now been integrated.

Changeset: 9d4fbbe3
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9d4fbbe36d85d71ce850bb83bbfb1ce1d3e8dd23
Stats:     883 lines in 5 files changed: 866 ins; 7 del; 10 mod

8374222: jpackage will exit with error if it fails to clean the temp directory

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/29664

From jlu at openjdk.org  Wed Feb 25 18:01:26 2026
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Feb 2026 18:01:26 GMT
Subject: RFR: 8378111: Migrate java/util/jar tests to JUnit [v3]
In-Reply-To: <l8LrnqR8DzOC_3hwGEl44Xvu9-PDhw-eGnTvYDlZkEA=.ac98b22f-e5e2-42f9-a673-c91fcfd35923@github.com>
References: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
 <byA5m9O6m0xMz0JVHfA6coX5fePS0EbZNHTeSfnx7kE=.dfdbe356-474c-45f4-8d2c-ac2c2cce8cfc@github.com>
 <l8LrnqR8DzOC_3hwGEl44Xvu9-PDhw-eGnTvYDlZkEA=.ac98b22f-e5e2-42f9-a673-c91fcfd35923@github.com>
Message-ID: <tWFG3g7kFt00B7C8x5ME4s8j98LWm0BMOBOqJC9JUOI=.fa0ce59d-efa4-42ab-bf36-231544c431ab@github.com>

On Wed, 25 Feb 2026 08:11:41 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   get rid of inheritance + zip -> ZIP
>
> test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarHttpProperties.java line 72:
> 
>> 70: 
>> 71:     @BeforeAll
>> 72:     public void initialize() throws Exception {
> 
> Maybe we should add `static` modifier for @BeforeAll and @AfterAll method

These methods appear like they should be `static` but since this test class uses a `PER_CLASS` lifecycle, these methods are actually fine as instance methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2854535843

From fthevenet at openjdk.org  Wed Feb 25 18:45:52 2026
From: fthevenet at openjdk.org (Frederic Thevenet)
Date: Wed, 25 Feb 2026 18:45:52 GMT
Subject: RFR: 8378702: jdk.test.lib.Platform.isMusl() may return false negative
 on Alpine Linux
Message-ID: <ukKifiMQVSDMEFSaUfnxy7bBPLCDeQQ_W_F6JLnJySE=.aa00e770-2ce6-4ceb-a5eb-c74c4ad6aa29@github.com>

jdk.test.lib.Platform.isMusl() may return false on Alpine linux, where it should return true.
This means that the jtreg tests is is used to guard will incorrectly fail.
This happens when tests deliberately clobber the  PATH and `ldd` can no longer be found. This PR uses a full path for `ldd` instead to work around the issue.

-------------

Commit messages:
 - 8378702: jdk.test.lib.Platform.isMusl() may return false negative on Alpine Linux

Changes: https://git.openjdk.org/jdk/pull/29923/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29923&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378702
  Stats: 10 lines in 1 file changed: 2 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/29923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29923/head:pull/29923

PR: https://git.openjdk.org/jdk/pull/29923

From dl at openjdk.org  Wed Feb 25 18:48:28 2026
From: dl at openjdk.org (Doug Lea)
Date: Wed, 25 Feb 2026 18:48:28 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v44]
In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
Message-ID: <gnEIsXzEGZsBK4koB6aTKaQ8I9NPZ1sjeNVM14Vd58w=.28408d95-b51d-4ad9-8d2d-9566fa3912a4@github.com>

> Changes signal filtering to avoid possible starvation

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  re-introduce some fences; rework deactivation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28797/files
  - new: https://git.openjdk.org/jdk/pull/28797/files/7e1ad28d..1d3b4db4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=43
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=42-43

  Stats: 70 lines in 1 file changed: 12 ins; 12 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/28797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28797/head:pull/28797

PR: https://git.openjdk.org/jdk/pull/28797

From duke at openjdk.org  Wed Feb 25 19:43:47 2026
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Wed, 25 Feb 2026 19:43:47 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v3]
In-Reply-To: <VlAq2Q61T2hRpqjjueeoA7GRttajxd6EdD8tRfxQMWQ=.12e877ce-262b-40fa-b710-1af3a0d10e11@github.com>
References: <JOYhlJQ-Gk8MeV6TpLv46ScWxfs1MWvLqNMRtfPC0DY=.edc60cbf-5c16-44e7-b913-68619cbca4bd@github.com>
 <-T2GCGJ65G8TIOOQKNBTv8ACbSZfRGQpcbPyP8OklJI=.01384c3d-e2ca-4b1e-90d3-051add584d6d@github.com>
 <VlAq2Q61T2hRpqjjueeoA7GRttajxd6EdD8tRfxQMWQ=.12e877ce-262b-40fa-b710-1af3a0d10e11@github.com>
Message-ID: <Ft6d5qj_RzOIsuKQPVlFLjMQb9asJvlYQ_4o03dYRmw=.5570d2ef-ed35-42cd-8b2a-46a8e3ca2cca@github.com>

On Fri, 21 Nov 2025 13:47:16 GMT, Doug Lea <dl at openjdk.org> wrote:

>> Vladimir Yaroslavskiy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8266431: Dual-Pivot Quicksort improvements
>>   
>>   * Added @java.io.Serial
>>   * Added information about the best data types for thresholds of sorting
>>   * Added comments about native implementation based on AVX512 instructions
>
> Some general comments:
> 
> The structure  intrinsically gets more complicated and harder to read as  options and sub-options increase -- 6 kinds of sorts, some with parallel and/or SIMD, some only applying to some element types,  almost all of them with incremental improvements. I think the attempts to better organize these is OK, but the main DualPiviotQuicksort should include a brief account similar to the wording in the PR intro to better explain how the dispatching criteria and logic.  And perhaps a summary of constants and thresholds, with notes on sensitivity of values.
> 
> The changes related to parallel sorting all look good to me. I didn't read the other parts in detail

Hi @DougLea Doug Lea, @jatin-bhateja, @jbhateja Jatin Bhateja, @tarsa Piotr Tarsa!

Please review the final sources.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27411#issuecomment-3961583808

From duke at openjdk.org  Wed Feb 25 20:11:01 2026
From: duke at openjdk.org (Patrick Strawderman)
Date: Wed, 25 Feb 2026 20:11:01 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString
In-Reply-To: <3YXAU80lmhvhAl0zwwAijFhx78u1bAq7vPRv5qvioTk=.97e51d4e-9f0c-4662-882b-3b1277a8184f@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
 <3YXAU80lmhvhAl0zwwAijFhx78u1bAq7vPRv5qvioTk=.97e51d4e-9f0c-4662-882b-3b1277a8184f@github.com>
Message-ID: <e3gGw0oxFK-rhgQ8EPXZz4HEcua3gVv-vdxVcvKxusk=.3bfeb092-07a2-44c2-84f8-04744227a8d4@github.com>

On Wed, 25 Feb 2026 15:58:22 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hmm, I checked the code of that deprecated constructor. If the compiler can recognize `count == ascii.length` then it should be able to fold this code; maybe the compiler is too stupid. Have you verified the performance results in a benchmark?

I did not run benchmarks, just saw that the constructor copies the array (obviously since it's public), and that we use JLA in other places to avoid the copy.

> Turns out this is necessary per https://bugs.openjdk.org/browse/JDK-8364418

Yep I saw that as well, which is why I thought this would be beneficial.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29920#issuecomment-3961737142

From duke at openjdk.org  Wed Feb 25 20:16:08 2026
From: duke at openjdk.org (duke)
Date: Wed, 25 Feb 2026 20:16:08 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString
In-Reply-To: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
Message-ID: <0-_xV-tGumqwG3vXTDL9P5tH6QPqW_NB_SKntyG53qU=.fdc55285-0246-41d6-bc44-fe980341c642@github.com>

On Wed, 25 Feb 2026 15:37:02 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes

@kilink 
Your change (at version d007ca46ac6910e2cda7b569716148e1fb30af14) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29920#issuecomment-3961771818

From liach at openjdk.org  Wed Feb 25 20:24:52 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Feb 2026 20:24:52 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString
In-Reply-To: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
Message-ID: <uy_p1rhmk08arWcGecAVJSoL0i94gJsticX4idEYpqk=.96c445e2-f345-4355-972d-af5831a7d867@github.com>

On Wed, 25 Feb 2026 15:37:02 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes

> /integrate

Please be aware of https://openjdk.org/guide/#life-of-a-pr "Life of a PR" point 7, allow 24 hours for sufficient reviews before typing `/integrate` command. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29920#issuecomment-3961821373

From liach at openjdk.org  Wed Feb 25 21:33:13 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Feb 2026 21:33:13 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString
In-Reply-To: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
Message-ID: <ALzxYNcgMViEcEVV5_j0GDmt28YnyQXUabQ2QXYQc1w=.a94908bb-95b8-4f64-a2e3-4bf1e57f685d@github.com>

On Wed, 25 Feb 2026 15:37:02 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes

Ran tier 1-3 on linux x64 on Oracle's CI, all passed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29920#issuecomment-3962213304

From liach at openjdk.org  Wed Feb 25 21:33:40 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Feb 2026 21:33:40 GMT
Subject: RFR: 8378715: Use early field initialization for java.lang.invoke
 generated code
Message-ID: <2wMVCAGsEc_7qZioeEoxC1kZU2cfcaR2Wt9_Ftdras8=.0400105a-6cf6-49ab-bae6-9a64c7998dc4@github.com>

With Flexible Constructor Bodies, the preferred way to assign fields for objects is to assign before making a super call. These are all sites in the JDK code that can migrate to the new preferred pattern. This change also allows these fields to be later declared ACC_STRICT_INIT when strict fields JEP is integrated.

-------------

Commit messages:
 - 8378715: Use early field initialization for java.lang.invoke generated code

Changes: https://git.openjdk.org/jdk/pull/29926/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29926&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378715
  Stats: 29 lines in 3 files changed: 10 ins; 12 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/29926.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29926/head:pull/29926

PR: https://git.openjdk.org/jdk/pull/29926

From liach at openjdk.org  Wed Feb 25 22:29:30 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Feb 2026 22:29:30 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v6]
In-Reply-To: <7HNoIEEFVQ124VGD57eXmGgEEL7xNixKYtHRGyPAFPU=.a83912db-8b0c-4901-9e9b-dffaad3ceab1@github.com>
References: <JOYhlJQ-Gk8MeV6TpLv46ScWxfs1MWvLqNMRtfPC0DY=.edc60cbf-5c16-44e7-b913-68619cbca4bd@github.com>
 <7HNoIEEFVQ124VGD57eXmGgEEL7xNixKYtHRGyPAFPU=.a83912db-8b0c-4901-9e9b-dffaad3ceab1@github.com>
Message-ID: <BURJJZdzfkOLMmZI4fBOh4O2moVznvQkVt3H2KLfOmQ=.3e737cfe-e72e-4523-9d1d-269589b3bd67@github.com>

On Thu, 29 Jan 2026 20:37:23 GMT, Vladimir Yaroslavskiy <duke at openjdk.org> wrote:

>> The goal of the PR is to improve both, sequential and parallel, sorting of primitives.
>> 
>> **The main achievements**
>> 
>> - introduced Radix in parallel sorting which shows several times boost of performance and has linear complexity instead of n*ln(n)
>> - improved mixed insertion sort (makes whole sorting faster)
>> - improved merging sort for almost sorted data
>> - optimized parallel sorting
>> - improved step for pivot candidates and pivot partitioning
>> - suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError
>> - minor javadoc and comment changes
>> 
>> - extended existing tests
>> - added tests for radix sort, heap sort, insertion sort
>> - added benchmarking JMH tests
>> - improved test coverage
>> 
>> **The summary of benchmarking:**
>> 
>> **Sequential sorting (Arrays.sort)**
>> 
>> byte: up to 50% faster
>> char: 4-7 times faster
>> short: 2-6 times faster
>> int: 1.2-5 times faster
>> long: 1.2-5 times faster
>> float: 1.2-5 times faster
>> double: 1.2-4 times faster
>> 
>> **Parallel sorting (Arrays.parallelSort)**
>> 
>> int: 1.2-9 times faster
>> long: 1.2-9 times faster
>> float: 1.2-4 times faster
>> double: 1.2-4 times faster
>> 
>> **AVX512 support**
>> 
>> Vamsi Parasa suggested faster sort routines by taking advantage of AVX512 instructions, see https://github.com/openjdk/jdk/pull/14227, sources of sorting were modified. Therefore, I performed benchmarking of the final version (which includes optimizations by Vamsi Parasa and optimizations from my side) on a server with CPUs supported AVX512 instructions, no regression of performance was found, see detailed benchmarking results.
>> 
>> **High-level chart showing how the actual sorting algorithm is selected
>> based on parallel/sequential and input size**
>> 
>> **int/long/float/double**
>> 
>> if size < MAX_INSERTION_SORT_SIZE(=51) => [ mixed ] insertion sort
>> if array is almost sorted and size > MIN_MERGING_SORT_SIZE(=512) => merging sort
>> if recursion depth > MAX_RECURSION_DEPTH(=64) => heap sort
>> if random data => two pivots quicksort, else => one pivot quicksort
>> 
>> **byte**
>> 
>> if size < MAX_INSERTION_SORT_SIZE(=51) => insertion sort
>> else => counting sort
>> 
>> **char/short**
>> 
>> if size > MIN_COUNTING_SORT_SIZE(640) => counting sort
>> if size < MAX_INSERTION_SORT_SIZE(=51) => insertion sort
>> if recursion depth > MAX_RECURSION_DEPTH(=64) => counting sort
>> if random data => two pivots quicksort, else => one pivot quicksort
>> 
>> **parallel sorting (int/lo...
>
> Vladimir Yaroslavskiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements
>   
>   * Resolved IDE warnings
>   * Set next year 2026

src/java.base/share/classes/java/util/gen-DualPivotQuicksort.sh line 1:

> 1: #!/bin/bash

Consider moving this to a make file in make/modules/java.base/gensrc; there are a few other scripts in that directory.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27411#discussion_r2855821739

From almatvee at openjdk.org  Thu Feb 26 02:32:08 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 26 Feb 2026 02:32:08 GMT
Subject: RFR: 8371438: jpackage should handle the case when "--mac-sign" is
 specified without signing identity options
In-Reply-To: <YfEBGJapqfeJcsFueUI8LP5xT6cc9Kk0eIc6tvCtvRc=.bfb229eb-a0cf-443f-b7b1-162cb7e2eaac@github.com>
References: <YfEBGJapqfeJcsFueUI8LP5xT6cc9Kk0eIc6tvCtvRc=.bfb229eb-a0cf-443f-b7b1-162cb7e2eaac@github.com>
Message-ID: <ImUd1haewcdqxxArjyQmkPhU_gbNnonDHIPj8MCr08o=.32c3333f-9f9f-4a1f-9ba6-b95996dbd313@github.com>

On Sun, 18 Jan 2026 07:34:45 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Restore the logic of how jpackage handles cases when the "--mac-sign" option is specified without the "--mac-signing-key-user-name" or "--mac-app-image-sign-identity" option. 
> 
> Make it work as it did prior to the [JDK-8333664](https://bugs.openjdk.org/browse/JDK-8333664) patch, which caused jpackage to silently ignore the "--mac-sign" option and not sign the output bundle.
> 
> The restored behavior is as follows:
> 
> If the "--mac-sign" option is specified, jpackage will always attempt to sign the output bundle.
> 
> If none of the signing identity options ("--mac-signing-key-user-name", "--mac-app-image-sign-identity", or "--mac-installer-sign-identity") is specified, jpackage will look up for a signing identity (or signing identities in case of PKG bundling) in the keychain specified with the "--mac-signing-keychain", or in the default keychain of the current user if the "--mac-signing-keychain" option is not specified.
> 
> If the keychain contains exactly one signing certificate of a specific type (a certificate for signing an app image or a certificate for signing a PKG installer), jpackage will use it for signing. Otherwise, jpackage will exit with an error.
> 
> Added tests to cover the cases when the "--mac-sign" option is specified and the keychain has/doesn't have signing certificates.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29290#pullrequestreview-3858069316

From liach at openjdk.org  Thu Feb 26 03:32:03 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Feb 2026 03:32:03 GMT
Subject: RFR: 8355536: Model preview enabled VM features in
 ClassFileFormatVersion [v10]
In-Reply-To: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
Message-ID: <aek27a5Md2X1hjD9det4GSoMv4b6Sq4aL3S0gL2jJjU=.bd21b811-d355-4019-97f9-40e5e66a2efe@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 18 commits:

 - Tweak test
 - More tweaks
 - Refresh
 - 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
 - Fixes
 - 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
 - ... and 8 more: https://git.openjdk.org/jdk/compare/d6044d3e...8e128d29

-------------

Changes: https://git.openjdk.org/jdk/pull/25017/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25017&range=09
  Stats: 120 lines in 3 files changed: 96 ins; 2 del; 22 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 jkarthikeyan at openjdk.org  Thu Feb 26 04:33:11 2026
From: jkarthikeyan at openjdk.org (Jasmine Karthikeyan)
Date: Thu, 26 Feb 2026 04:33:11 GMT
Subject: RFR: 8378180: Compiling OpenJDK with C23 C-Compiler gives warning:
 initialization discards =?UTF-8?B?4oCYY29uc3TigJk=?= qualifier from pointer
 target type
Message-ID: <ZMgHMVJXCvSHKIQczEV88lEQge9p2IKAlF7g7x_bYwQ=.cc24304d-25ab-4aa9-bba7-ae4023820c0a@github.com>

Hi all, this is a quick patch to fix a build issue I encountered when updating my Linux system. [Glibc 2.43](https://lists.gnu.org/archive/html/info-gnu/2026-01/msg00005.html) changes the definition of some string related functions to return `const char*` when provided a `const char*` parameter, rather than the previous behavior of returning `char*`. I've fixed this by applying the `const` modifier, and casting to `char*` when needed. This should be backwards-compatible since assigning a non-const pointer to const is an implicit conversion. Thoughts and comments would be appreciated on whether this is the best way to fix this issue. Thanks!

-------------

Commit messages:
 - Fix discarded const qualifiers

Changes: https://git.openjdk.org/jdk/pull/29929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29929&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378180
  Stats: 18 lines in 9 files changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/29929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29929/head:pull/29929

PR: https://git.openjdk.org/jdk/pull/29929

From jpai at openjdk.org  Thu Feb 26 05:51:10 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 26 Feb 2026 05:51:10 GMT
Subject: RFR: 8378268: Thread.join can wait on Thread,
 allows joinNanos to be removed
In-Reply-To: <-ckkcXUkmMzpwb4p_Bc6rx_e25gD-5OhGuG6Uw8JYwg=.d8d7e10c-2218-41af-8167-9446684ace09@github.com>
References: <-ckkcXUkmMzpwb4p_Bc6rx_e25gD-5OhGuG6Uw8JYwg=.d8d7e10c-2218-41af-8167-9446684ace09@github.com>
Message-ID: <MY5JNO3HLBMEUZmr5H4CZYMtyf_oqIKieHSMJ-QdpTM=.a29d3b68-06f9-44ce-98f3-13fcef9ed699@github.com>

On Fri, 20 Feb 2026 09:26:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.join was historically implemented with a loop of Object.wait conditioned on isAlive. We couldn't for this virtual threads because it would pin a virtual thread invoking join to it carrier.  Now that Object.wait preempts, it means the special implementation of join for virtual threads can be removed. Where possible, the notifyAll is elided as it adds to the cost of termination.
> 
> The implNote of the join methods is restored (this is implNote text, not spec, so no CSR required).
> 
> Testing: tier1-5

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29839#pullrequestreview-3858598412

From jpai at openjdk.org  Thu Feb 26 05:54:45 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 26 Feb 2026 05:54:45 GMT
Subject: RFR: 8378268: Thread.join can wait on Thread,
 allows joinNanos to be removed
In-Reply-To: <-ckkcXUkmMzpwb4p_Bc6rx_e25gD-5OhGuG6Uw8JYwg=.d8d7e10c-2218-41af-8167-9446684ace09@github.com>
References: <-ckkcXUkmMzpwb4p_Bc6rx_e25gD-5OhGuG6Uw8JYwg=.d8d7e10c-2218-41af-8167-9446684ace09@github.com>
Message-ID: <trLpAJ3-fhrbarpW4mIQ6ttZ4sc5fI-Av0w2xi4-eFY=.fd964815-acba-4a7c-99a1-7115cb8a108d@github.com>

On Fri, 20 Feb 2026 09:26:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.join was historically implemented with a loop of Object.wait conditioned on isAlive. We couldn't for this virtual threads because it would pin a virtual thread invoking join to it carrier.  Now that Object.wait preempts, it means the special implementation of join for virtual threads can be removed. Where possible, the notifyAll is elided as it adds to the cost of termination.
> 
> The implNote of the join methods is restored (this is implNote text, not spec, so no CSR required).
> 
> Testing: tier1-5

src/java.base/share/classes/java/lang/VirtualThread.java line 188:

> 186: 
> 187:     // termination object when joining, created lazily if needed
> 188:     private volatile CountDownLatch termination;

Nit - I suspect the CountDownLatch import can be removed too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29839#discussion_r2857064073

From dholmes at openjdk.org  Thu Feb 26 06:36:43 2026
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 26 Feb 2026 06:36:43 GMT
Subject: RFR: 8378702: jdk.test.lib.Platform.isMusl() may return false
 negative on Alpine Linux
In-Reply-To: <ukKifiMQVSDMEFSaUfnxy7bBPLCDeQQ_W_F6JLnJySE=.aa00e770-2ce6-4ceb-a5eb-c74c4ad6aa29@github.com>
References: <ukKifiMQVSDMEFSaUfnxy7bBPLCDeQQ_W_F6JLnJySE=.aa00e770-2ce6-4ceb-a5eb-c74c4ad6aa29@github.com>
Message-ID: <9FDyzhrsY8u72jJV-8gVRbf4ONRw862ig3USKw7C9w0=.b18722a3-9006-4422-8bba-c6c603e13409@github.com>

On Wed, 25 Feb 2026 16:47:03 GMT, Frederic Thevenet <fthevenet at openjdk.org> wrote:

> jdk.test.lib.Platform.isMusl() may return false on Alpine linux, where it should return true.
> This means that the jtreg tests is is used to guard will incorrectly fail.
> This happens when tests deliberately clobber the  PATH and `ldd` can no longer be found. This PR uses a full path for `ldd` instead to work around the issue.

test/lib/jdk/test/lib/Platform.java line 196:

> 194:             ProcessBuilder pb = new ProcessBuilder(lddPath.get(), "--version");
> 195:             pb.redirectErrorStream(true);
> 196:             try (Process p = pb.start()) {

`Process` is not `AutoCloseable` - why are you using try-with-resources?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29923#discussion_r2857188022

From jbhateja at openjdk.org  Thu Feb 26 06:46:53 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 26 Feb 2026 06:46:53 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v25]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <5carnZir5Y6WbmXqTmJUz2QA4M6_lUx490epf6fql-E=.823b53d8-1727-4fa4-ab05-a9052f8fc00e@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1344" height="532" alt="image" src="https://github.com/user-attachments/assets/c8157c3c-22b0-4bc1-9de9-7a68cadb7b2a" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - More cleanups
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - JCheck whitespace fixes
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Test cleanups and re-factoring
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Adding new lane type constants for intrinsic entries, removing basictype extension changes
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Clanups
 - ... and 32 more: https://git.openjdk.org/jdk/compare/fd74232d...59cc28e9

-------------

Changes: https://git.openjdk.org/jdk/pull/28002/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=24
  Stats: 53925 lines in 109 files changed: 49707 ins; 74 del; 4144 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

PR: https://git.openjdk.org/jdk/pull/28002

From alanb at openjdk.org  Thu Feb 26 07:26:15 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Feb 2026 07:26:15 GMT
Subject: RFR: 8378268: Thread.join can wait on Thread,
 allows joinNanos to be removed [v2]
In-Reply-To: <-ckkcXUkmMzpwb4p_Bc6rx_e25gD-5OhGuG6Uw8JYwg=.d8d7e10c-2218-41af-8167-9446684ace09@github.com>
References: <-ckkcXUkmMzpwb4p_Bc6rx_e25gD-5OhGuG6Uw8JYwg=.d8d7e10c-2218-41af-8167-9446684ace09@github.com>
Message-ID: <CfAiygiWrykVHMmGzb2wl75WjQUNHl2CEv8R9D7LKBw=.4d90d244-a1f5-4101-b538-93d6ce9e6818@github.com>

> Thread.join was historically implemented with a loop of Object.wait conditioned on isAlive. We couldn't for this virtual threads because it would pin a virtual thread invoking join to it carrier.  Now that Object.wait preempts, it means the special implementation of join for virtual threads can be removed. Where possible, the notifyAll is elided as it adds to the cost of termination.
> 
> The implNote of the join methods is restored (this is implNote text, not spec, so no CSR required).
> 
> Testing: tier1-5

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Remove unused import
 - Merge branch 'master' into JDK-8378268
 - Merge branch 'master' into JDK-8378268
 - Avoid notifyAll if no join
 - Merge branch 'master' into JDK-8378268
 - Merge branch 'master' into JDK-8378268
 - Remove joinNanos

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29839/files
  - new: https://git.openjdk.org/jdk/pull/29839/files/ffe35246..fa12b57e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29839&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29839&range=00-01

  Stats: 14260 lines in 479 files changed: 7348 ins; 2653 del; 4259 mod
  Patch: https://git.openjdk.org/jdk/pull/29839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29839/head:pull/29839

PR: https://git.openjdk.org/jdk/pull/29839

From alanb at openjdk.org  Thu Feb 26 07:36:18 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Feb 2026 07:36:18 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString
In-Reply-To: <e3gGw0oxFK-rhgQ8EPXZz4HEcua3gVv-vdxVcvKxusk=.3bfeb092-07a2-44c2-84f8-04744227a8d4@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
 <3YXAU80lmhvhAl0zwwAijFhx78u1bAq7vPRv5qvioTk=.97e51d4e-9f0c-4662-882b-3b1277a8184f@github.com>
 <e3gGw0oxFK-rhgQ8EPXZz4HEcua3gVv-vdxVcvKxusk=.3bfeb092-07a2-44c2-84f8-04744227a8d4@github.com>
Message-ID: <AhrHtQfdZQp29_1XRGgdC7kD_DAwcUnHaOdnDI7253M=.3d29cc6c-2119-4725-a947-65159105540f@github.com>

On Wed, 25 Feb 2026 20:08:19 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> Hmm, I checked the code of that deprecated constructor. If the compiler can recognize `count == ascii.length` then it should be able to fold this code; maybe the compiler is too stupid. Have you verified the performance results in a benchmark?
>
>> Hmm, I checked the code of that deprecated constructor. If the compiler can recognize `count == ascii.length` then it should be able to fold this code; maybe the compiler is too stupid. Have you verified the performance results in a benchmark?
> 
> I did not run benchmarks, just saw that the constructor copies the array (obviously since it's public), and that we use JLA in other places to avoid the copy.
> 
>> Turns out this is necessary per https://bugs.openjdk.org/browse/JDK-8364418
> 
> Yep I saw that as well, which is why I thought this would be beneficial.

@kilink Are you going to update the PR with the performance data and a summary of the testing that you have done? Are the benchmarks for Base64.Encoder in test/micro sufficient or will this PR propose to add more benchmarks?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29920#issuecomment-3964695824

From erfang at openjdk.org  Thu Feb 26 07:56:42 2026
From: erfang at openjdk.org (Eric Fang)
Date: Thu, 26 Feb 2026 07:56:42 GMT
Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in
 specific patterns [v11]
In-Reply-To: <pnZJvIEVLj9G0x376kpsgd01o7kZX5XJW-xjZOP143g=.775b8168-8726-48d5-9f01-571656e36510@github.com>
References: <HMuVXUIOt76mFvVAk0A4ZRU-GWzSlBS7B9teoJayJGo=.212c3356-ca2a-41a3-b3a0-b7e2370dedea@github.com>
 <7_MkAbcoypxV-8B1u-Gx_LytLa8EbFQCbVUWBE63vI4=.eade482e-7420-42a6-9804-07029309a0db@github.com>
 <pnZJvIEVLj9G0x376kpsgd01o7kZX5XJW-xjZOP143g=.775b8168-8726-48d5-9f01-571656e36510@github.com>
Message-ID: <JMvyluNFxw7oIA_wVEBosNXS8u_5dK24khGF-nRE0y8=.96bba38e-261d-4eea-a116-51faf0506322@github.com>

On Wed, 25 Feb 2026 13:11:28 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Eric Fang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Improve the code comment and tests
>>  - Merge branch 'master' into JDK-8370863-mask-cast-opt
>>  - Refine the JTReg tests
>>  - Add clearer comments to VectorMaskCastIdentityTest.java
>>  - Update copyright year to 2026
>>  - Merge branch 'master' into JDK-8370863-mask-cast-opt
>>  - Convert the check condition for vector length into an assertion
>>    
>>    Also refined the tests.
>>  - Refine code comments
>>  - Merge branch 'master' into JDK-8370863-mask-cast-opt
>>  - Merge branch 'master' into JDK-8370863-mask-cast-opt
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/c0c1775a...dcd64ad1
>
> I'm getting some failures with your new test:
> 
> 
> Failed IR Rules (1) of Methods (1)
> ----------------------------------
> 1) Method "compiler.vectorapi.VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityFloat256" - [Failed IR rules: 1]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"sve", "true", "avx2", "true"}, counts={"_#V#LOAD_VECTOR_Z#_", "_ at 4", ">= 3", "_#VECTOR_LOAD_MASK#_", "= 0", "_#VECTOR_STORE_MASK#_", "= 0", "_#VECTOR_MASK_CAST#_", "= 0"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={"MaxVectorSize", "> 16"}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>      > Phase "PrintIdeal":
>        - counts: Graph contains wrong number of nodes:
>          * Constraint 2: "(\\d+(\\s){2}(VectorLoadMask.*)+(\\s){2}===.*)"
>            - Failed comparison: [found] 1 = 0 [given]
>              - Matched node:
>                * 277  VectorLoadMask  === _ 106  [[ 275 ]]  #vectormask<F,4> !jvms: VectorMask::fromArray @ bci:47 (line 209) VectorStoreMaskIdentityTest::testTwoCastsKernel @ bci:5 (line 75) VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityFloat256 @ bci:29 (line 271)
>          * Constraint 3: "(\\d+(\\s){2}(VectorStoreMask.*)+(\\s){2}===.*)"
>            - Failed comparison: [found] 1 = 0 [given]
>              - Matched node:
>                * 254  VectorStoreMask  === _ 271 272  [[ 216 ]]  #vectors<Z,4> !jvms: AbstractMask::intoArray @ bci:50 (line 75) VectorStoreMaskIdentityTest::testTwoCastsKernel @ bci:20 (line 77) VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityFloat256 @ bci:29 (line 271)
>          * Constraint 4: "(\\d+(\\s){2}(VectorMaskCast.*)+(\\s){2}===.*)"
>            - Failed comparison: [found] 2 = 0 [given]
>              - Matched nodes (2):
>                * 271  VectorMaskCast  === _ 275  [[ 254 ]]  #vectormask<J,4> !jvms: ShortVector64$ShortMask64::cast @ bci:54 (line 665) VectorStoreMaskIdentityTest::testTwoCastsKernel @ bci:13 (line 77) VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityFloat256 @ bci:29 (line 271)
>                * 275  VectorMaskCast  === _ 277  [[ 271 ]]  #vectormask<S,4> !orig=[5222],[2038] !jvms: FloatVector128$FloatMask128::cast @ bci:54 (line 654) VectorStoreMaskIdentityTest::testTwoCastsKernel @ bci:9 (line 76) VectorStoreMaskIdentityTest::testVectorMaskStoreIdentityFloat256 @ bci:29 (line 271)
> 
> 
> This was run on an x64 machine with extra flags:
> `-ea -esa -XX:CompileThreshold=100 ...

@eme64 Thank you for your help! I can reproduce the test failure. It appears to be a random test failure, but we can trigger it in multiple tests. I haven't found the root cause yet. Looking at the dump's IR, it seems an expected optimization isn't working; `(VectorStoreMask (VectorMaskCast (VectorMaskCast (VectorMaskCast (VectorLoadMask (LoadVector m))))))` should have been optimized to `(LoadVector m)`, but it wasn't. I'm continuing to debug. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28313#issuecomment-3964784818

From fthevenet at openjdk.org  Thu Feb 26 08:19:02 2026
From: fthevenet at openjdk.org (Frederic Thevenet)
Date: Thu, 26 Feb 2026 08:19:02 GMT
Subject: RFR: 8378702: jdk.test.lib.Platform.isMusl() may return false
 negative on Alpine Linux
In-Reply-To: <9FDyzhrsY8u72jJV-8gVRbf4ONRw862ig3USKw7C9w0=.b18722a3-9006-4422-8bba-c6c603e13409@github.com>
References: <ukKifiMQVSDMEFSaUfnxy7bBPLCDeQQ_W_F6JLnJySE=.aa00e770-2ce6-4ceb-a5eb-c74c4ad6aa29@github.com>
 <9FDyzhrsY8u72jJV-8gVRbf4ONRw862ig3USKw7C9w0=.b18722a3-9006-4422-8bba-c6c603e13409@github.com>
Message-ID: <w13YIwQJ777alIj6QMuRj8IlUUXslHOc7xMVnaootFc=.0e7e731b-69aa-4257-9295-578a54bc0ffb@github.com>

On Thu, 26 Feb 2026 06:34:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> jdk.test.lib.Platform.isMusl() may return false on Alpine linux, where it should return true.
>> This means that the jtreg tests is is used to guard will incorrectly fail.
>> This happens when tests deliberately clobber the  PATH and `ldd` can no longer be found. This PR uses a full path for `ldd` instead to work around the issue.
>
> test/lib/jdk/test/lib/Platform.java line 196:
> 
>> 194:             ProcessBuilder pb = new ProcessBuilder(lddPath.get(), "--version");
>> 195:             pb.redirectErrorStream(true);
>> 196:             try (Process p = pb.start()) {
> 
> `Process` is not `AutoCloseable` - why are you using try-with-resources?

`Process` implements `Closable` since https://bugs.openjdk.org/browse/JDK-8364361

Although on second thought, I agree it is worth considering whether or not we want to do this here, as it will make backporting this change less straight forward.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29923#discussion_r2857584081

From jpai at openjdk.org  Thu Feb 26 09:48:00 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 26 Feb 2026 09:48:00 GMT
Subject: RFR: 8378268: Thread.join can wait on Thread,
 allows joinNanos to be removed [v2]
In-Reply-To: <CfAiygiWrykVHMmGzb2wl75WjQUNHl2CEv8R9D7LKBw=.4d90d244-a1f5-4101-b538-93d6ce9e6818@github.com>
References: <-ckkcXUkmMzpwb4p_Bc6rx_e25gD-5OhGuG6Uw8JYwg=.d8d7e10c-2218-41af-8167-9446684ace09@github.com>
 <CfAiygiWrykVHMmGzb2wl75WjQUNHl2CEv8R9D7LKBw=.4d90d244-a1f5-4101-b538-93d6ce9e6818@github.com>
Message-ID: <sTj6RdHglTQI_RbsFF2pcqnxf8LqiRP_JJgoCCEdoAw=.b17abf67-7fec-4886-ac59-e57cf8c94d74@github.com>

On Thu, 26 Feb 2026 07:26:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thread.join was historically implemented with a loop of Object.wait conditioned on isAlive. We couldn't for this virtual threads because it would pin a virtual thread invoking join to it carrier.  Now that Object.wait preempts, it means the special implementation of join for virtual threads can be removed. Where possible, the notifyAll is elided as it adds to the cost of termination.
>> 
>> The implNote of the join methods is restored (this is implNote text, not spec, so no CSR required).
>> 
>> Testing: tier1-5
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Remove unused import
>  - Merge branch 'master' into JDK-8378268
>  - Merge branch 'master' into JDK-8378268
>  - Avoid notifyAll if no join
>  - Merge branch 'master' into JDK-8378268
>  - Merge branch 'master' into JDK-8378268
>  - Remove joinNanos

Thank you Alan, looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29839#pullrequestreview-3859741358

From vklang at openjdk.org  Thu Feb 26 10:20:44 2026
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 26 Feb 2026 10:20:44 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString
In-Reply-To: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
Message-ID: <5qBe_lWjFvcI1IFYdakUG1U4XvGijAW6rnz0yqqgGvI=.15c979a3-79b7-4d02-82d7-a77f1fa477d1@github.com>

On Wed, 25 Feb 2026 15:37:02 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes

Seconding Alan's sentiment here, contributing performance improvements without validation data is inadvisable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29920#issuecomment-3965614026

From eirbjo at openjdk.org  Thu Feb 26 10:20:45 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 26 Feb 2026 10:20:45 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString
In-Reply-To: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
Message-ID: <vhF63SnjqY19jQdlrw6X4VWQZaQ7M41xndLWAzve-4k=.b8428e77-aaa3-4ec5-98c9-74932f6d4cbf@github.com>

On Wed, 25 Feb 2026 15:37:02 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes

src/java.base/share/classes/java/util/Base64.java line 351:

> 349:          */
> 350:         public String encodeToString(byte[] src) {
> 351:             byte[] encoded = encode(src);

Consider adding a comment here to make it clear that `encoded` is guaranteed to be ASCII-only.

Otherwise, using `uncheckedNewStringWithLatin1Bytes` would not be safe. Better to make this contract explicit with a comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29920#discussion_r2858168126

From jpai at openjdk.org  Thu Feb 26 10:31:02 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 26 Feb 2026 10:31:02 GMT
Subject: RFR: 8273874: LdapClient can trigger memory leak
Message-ID: <M_eiT_QLSyWtLjH23gQeC18nWXAd1TAnpgSYiFFbZdk=.64a6563c-b11a-4789-9e97-80376b0d7676@github.com>

Can I please get a review of this change which addresses an issue in the `java.naming` module? 

As noted in https://bugs.openjdk.org/browse/JDK-8273874 when a `javax.naming.Context` is constructed backed by a `com.sun.jndi.ldap.LdapCtxFactory`, the internal implemenation of `LdapCtx` can lead to creation of Threads that are used for the managing connections and for managing event notifications. These threads are system threads. However, the way they are created currently, they end up capturing the context classloader of the calling Thread. This classloader will be held onto as long as these Threads stay alive and can thus prevent the classloader from being unreferenced.

The change in this PR replaces the creation of these threads with the `InnocuousThread`s, which do not have a context classloader associated with them.

A new jtreg test has been introduced to reproduce the issue and verify the fix. Existing tests continue to pass with this change.

-------------

Commit messages:
 - add test
 - 8273874: LdapClient can trigger memory leak

Changes: https://git.openjdk.org/jdk/pull/29934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29934&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8273874
  Stats: 341 lines in 4 files changed: 330 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/29934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29934/head:pull/29934

PR: https://git.openjdk.org/jdk/pull/29934

From ogillespie at openjdk.org  Thu Feb 26 10:55:49 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Thu, 26 Feb 2026 10:55:49 GMT
Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v4]
In-Reply-To: <72lBM_XDXOjREMu_aw7hNXCEFKmFADi1JpuSj58obYY=.e2aff6a4-6be5-4e63-b460-371eb5e873fa@github.com>
References: <M5Kk3KWYQZ5UagIv_f-nNwN8gNby1VZP3TlFsXUkBwY=.bfb41c1f-091f-4df4-b68f-6155607db159@github.com>
 <kVAdSfhQqpvUoirf-FPTCyONo-YnIOnBdqRneppV1-8=.cc90825b-41ca-4443-bf1c-aa056b42ffc5@github.com>
 <zdlkfKNlVhjSwlM69QB8T33nQropqQY_SowxQQ0afG4=.5e09fe10-17eb-40f4-bc49-2204f94b42de@github.com>
 <I7tsrhzAwGOb5Ri_kmrnjtimgGv2GtX85MnKu9YhIJk=.76d53686-bf1c-4c45-90d6-66a49e3d45b8@github.com>
 <EdriGMb-EC4hEuUqJvyCGuvXq9GOgwelp5t0B9X9un8=.f207febf-7613-4576-901b-a90e99fd112a@github.com>
 <DHMy4lgZXGGUXs_g5dgzkldBx7VEKnzOkCsXs_6loPw=.da834dd8-7b93-42e5-a084-583f09e61680@github.com>
 <pzruiRy5OL0aqki3JEKxVAeQVybZRBvg8ksd8N2r8KI=.cb791880-795b-46d5-8b79-bda211f6bd91@github.com>
 <MqcByRYB6_RUiifVEaq1G6YlQSQc-NJWtYcc3euXdrY=.a991553d-4631-4cdc-a177-61f346de9e28@github.com>
 <72lBM_XDXOjREMu_aw7hNXCEFKmFADi1JpuSj58obYY=.e2aff6a4-6be5-4e63-b460-371eb5e873fa@github.com>
Message-ID: <3wACDFR6UZdGrFYXrdq6di3FNTlSqp5AzU9VZ0D_bvE=.73ba25b1-aace-416e-9fa9-337b9a420c79@github.com>

On Mon, 23 Feb 2026 16:42:46 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Alternatively we can override `stream()` to call the `StreamSupport.stream` that takes a `Supplier<? extends Spliterator<T>>` instead.
>
> Good point, in fact I think that's more correct. From stream():
> 
>> This method should be overridden when the spliterator() method cannot return a spliterator that is IMMUTABLE, CONCURRENT, or late-binding. (See spliterator() for details.)
> 
> I suppose ours is no longer late-binding.

Fixed, please take a look when you can.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28608#discussion_r2858321395

From jpai at openjdk.org  Thu Feb 26 11:11:49 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 26 Feb 2026 11:11:49 GMT
Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile
 [v4]
In-Reply-To: <wJIvnT9i9uVWyxaGIemUlbA4FZzZ7-1UQ_wDSQVRp6I=.fad7f5cd-8751-4023-adf4-e2564ffa17f4@github.com>
References: <QDvNIqpJBwz2AByfzrrgSs8tKMYI2JpTTkP6M_qoAyc=.9ac31c22-9c76-4bf8-8664-d075caf70ae0@github.com>
 <bKvj6vkHxkcqYFnKRzRkzQLn6ebShnf_09A8XPgbLzo=.c34ce43d-24ef-49a0-a777-d07954c243be@github.com>
 <wJIvnT9i9uVWyxaGIemUlbA4FZzZ7-1UQ_wDSQVRp6I=.fad7f5cd-8751-4023-adf4-e2564ffa17f4@github.com>
Message-ID: <7WN-85taigqPiu2xO69CpapLtHjk7bLWM_5GVWGGIZA=.3c2399fd-215c-49a7-b2ed-55c66b47625e@github.com>

On Fri, 20 Feb 2026 12:41:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Please give me a few more days to approve this PR. I remember there was some discussion around the Inflater cache usage and how it may impact the performance. In this PR we have changed the policy on which Inflater we hand out from the cache, I would like to make sure that it doesn't have any unforeseen impact.

In my manual tests, I haven't found this to cause any noticeable impact. I think this change is OK to be integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29430#issuecomment-3965907234

From jpai at openjdk.org  Thu Feb 26 11:36:28 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 26 Feb 2026 11:36:28 GMT
Subject: RFR: 8369181: InflaterOutputStream: writing after finish() results in
 IllegalStateException instead of an IOException
Message-ID: <mnqiYjtOQiPhxB3Po5L4TFb1vch_b1_T4lWizpxEKRk=.148973c4-3242-4cf7-8e88-b1055a0c0045@github.com>

Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8369181?

As noted in that issue, if `finish()` is called on a `InflaterOutputStream` that was constructed without passing a `Inflater`, then any subsequent `write()`s on that `InflaterOutputStream` result in an `IllegalStateException`, because we close the `Inflater` in `finish()`. The commit in this PR, fixes the issue by throwing the specified `IOException` in place of the `IllegalStateException`. 

At the same time, the documentation of `finish()` has been enhanced to clarify the current behaviour, through a `@implSpec`.

Alternative approaches of deprecating finish() and/or not closing the default Inflater were considered, but given the current long standing implementation of finish(), it was decided to merely specify the current behaviour of closing the  default Inflater in finish().

A new jtreg test has been added to reproduce the issue and verify the fix. tier1, tier2, tier3 testing of this change completed without any related issues.

I'll file a CSR shortly for this change.

-------------

Commit messages:
 - 8369181 (v1): InflaterOutputStream: writing after finish() results in a NullPointerException (NPE) instead of an IOException

Changes: https://git.openjdk.org/jdk/pull/29935/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29935&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369181
  Stats: 220 lines in 2 files changed: 196 ins; 4 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/29935.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29935/head:pull/29935

PR: https://git.openjdk.org/jdk/pull/29935

From jpai at openjdk.org  Thu Feb 26 11:47:04 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 26 Feb 2026 11:47:04 GMT
Subject: RFR: 8378631: Update Zlib Data Compression Library to Version
 1.3.2
In-Reply-To: <3ciJz-gZK5MjQx6SSiAgbf4qmBFUYPT-fMjx9mISCEU=.416de52a-c7a3-4ba3-a282-d9130fd6483c@github.com>
References: <3ciJz-gZK5MjQx6SSiAgbf4qmBFUYPT-fMjx9mISCEU=.416de52a-c7a3-4ba3-a282-d9130fd6483c@github.com>
Message-ID: <U2scLYg_nXn5bE_QrgUGge_A_-ahqGgJsoMEbsoQaaQ=.9b3dba3d-7008-4a9c-9f9d-d4fec4c649f3@github.com>

On Wed, 25 Feb 2026 12:56:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which upgrades JDK's in-tree zlib code from 1.3.1 to the recently released zlib 1.3.2 version?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8378631, then changes between the upstream zlib 1.3.1 and 1.3.2 are available here https://github.com/madler/zlib/compare/v1.3.1...v1.3.2.

Thank you all for the reviews.

tier1, tier2 and tier3 testing completed without any issues. tier4 through tier8 testing is progressing fine without any related issues (and given the progress it has made, I don't expect issues related to this change). The failure in the GitHub actions job in this PR is a known issue that got addressed recently in https://bugs.openjdk.org/browse/JDK-8378641.

I'll go ahead and integrate this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29916#issuecomment-3966104194

From jpai at openjdk.org  Thu Feb 26 11:50:13 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 26 Feb 2026 11:50:13 GMT
Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile
 [v4]
In-Reply-To: <bKvj6vkHxkcqYFnKRzRkzQLn6ebShnf_09A8XPgbLzo=.c34ce43d-24ef-49a0-a777-d07954c243be@github.com>
References: <QDvNIqpJBwz2AByfzrrgSs8tKMYI2JpTTkP6M_qoAyc=.9ac31c22-9c76-4bf8-8664-d075caf70ae0@github.com>
 <bKvj6vkHxkcqYFnKRzRkzQLn6ebShnf_09A8XPgbLzo=.c34ce43d-24ef-49a0-a777-d07954c243be@github.com>
Message-ID: <O3j1rRBb5vmfH2rSIUfLeWsnK6vUtfuzSg3OfoFngrE=.d545794a-7fc5-4990-b7bc-6c6b5b3be64e@github.com>

On Fri, 20 Feb 2026 12:51:12 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Hot on the heals of #29288, this PR replaces `ArrayDeque` with `ArrayList` for the Inflater cache implementation in `ZipFile.CleanableResource`.
>> 
>> With this PR, we change the order of the cache from a LIFO queue to a FIFO stack backed by ArrayList. The order seems unimportant, and has indeed been FIFO in the past when using `java.util.Vector`. Intuitively, it should be better to return the most recently used Inflater.
>> 
>> No tests updated, strict refactoring, `noreg-cleanup`.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Add code comment about returning the most recently used Inflater from the cache
>  - Replace polling-style iteration with simple for loop
>  - Using add instead of addLast seems more natural for a List

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29430#pullrequestreview-3860433732

From jpai at openjdk.org  Thu Feb 26 11:50:24 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 26 Feb 2026 11:50:24 GMT
Subject: Integrated: 8378631: Update Zlib Data Compression Library to Version
 1.3.2
In-Reply-To: <3ciJz-gZK5MjQx6SSiAgbf4qmBFUYPT-fMjx9mISCEU=.416de52a-c7a3-4ba3-a282-d9130fd6483c@github.com>
References: <3ciJz-gZK5MjQx6SSiAgbf4qmBFUYPT-fMjx9mISCEU=.416de52a-c7a3-4ba3-a282-d9130fd6483c@github.com>
Message-ID: <Z6mU2Nx9o9cy1KDwSFbJUMoAXtv0yGgYgniL8eaCFdM=.7e8a2182-2195-430e-968f-698a02d0640b@github.com>

On Wed, 25 Feb 2026 12:56:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which upgrades JDK's in-tree zlib code from 1.3.1 to the recently released zlib 1.3.2 version?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8378631, then changes between the upstream zlib 1.3.1 and 1.3.2 are available here https://github.com/madler/zlib/compare/v1.3.1...v1.3.2.

This pull request has now been integrated.

Changeset: 16740060
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1674006047ba1e96b7b5a8baa899b7cf03e9c9b1
Stats:     1810 lines in 26 files changed: 795 ins; 368 del; 647 mod

8378631: Update Zlib Data Compression Library to Version 1.3.2

Reviewed-by: alanb, erikj, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/29916

From dfuchs at openjdk.org  Thu Feb 26 11:53:20 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Feb 2026 11:53:20 GMT
Subject: RFR: 8273874: LdapClient can trigger memory leak
In-Reply-To: <M_eiT_QLSyWtLjH23gQeC18nWXAd1TAnpgSYiFFbZdk=.64a6563c-b11a-4789-9e97-80376b0d7676@github.com>
References: <M_eiT_QLSyWtLjH23gQeC18nWXAd1TAnpgSYiFFbZdk=.64a6563c-b11a-4789-9e97-80376b0d7676@github.com>
Message-ID: <m35P7aaWkkWJBLAnk-nN_c1z6PHIFdptOKiTUZ8as2o=.351829df-d9c0-48b0-b50a-a1ed8dec52aa@github.com>

On Thu, 26 Feb 2026 10:25:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses an issue in the `java.naming` module? 
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8273874 when a `javax.naming.Context` is constructed backed by a `com.sun.jndi.ldap.LdapCtxFactory`, the internal implemenation of `LdapCtx` can lead to creation of Threads that are used for the managing connections and for managing event notifications. These threads are system threads. However, the way they are created currently, they end up capturing the context classloader of the calling Thread. This classloader will be held onto as long as these Threads stay alive and can thus prevent the classloader from being unreferenced.
> 
> The change in this PR replaces the creation of these threads with the `InnocuousThread`s, which do not have a context classloader associated with them.
> 
> A new jtreg test has been introduced to reproduce the issue and verify the fix. Existing tests continue to pass with this change.

LGTM generally, but I wonder about possible compatibility implications.

test/jdk/com/sun/jndi/ldap/LdapTCCLTest.java line 169:

> 167:                 // add a NamingListener to exercise the Thread creation in the internals
> 168:                 // of LdapCtx
> 169:                 ctx.addNamingListener(LOOKUP_NAME, EventContext.OBJECT_SCOPE, new Listener());

I wonder, before your fix, when the Listener is invoked, is it invoked from a thread whose TCCL is the `urlc`? If so, some listener implementation may be depending on it, and may start failing with CNFE or CCE if the TCCL is no longer set.
In other words - could this change be observed by custom code which might depend on the old behaviour?

-------------

PR Review: https://git.openjdk.org/jdk/pull/29934#pullrequestreview-3860436369
PR Review Comment: https://git.openjdk.org/jdk/pull/29934#discussion_r2858585337

From eirbjo at openjdk.org  Thu Feb 26 12:06:43 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 26 Feb 2026 12:06:43 GMT
Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile
 [v4]
In-Reply-To: <bKvj6vkHxkcqYFnKRzRkzQLn6ebShnf_09A8XPgbLzo=.c34ce43d-24ef-49a0-a777-d07954c243be@github.com>
References: <QDvNIqpJBwz2AByfzrrgSs8tKMYI2JpTTkP6M_qoAyc=.9ac31c22-9c76-4bf8-8664-d075caf70ae0@github.com>
 <bKvj6vkHxkcqYFnKRzRkzQLn6ebShnf_09A8XPgbLzo=.c34ce43d-24ef-49a0-a777-d07954c243be@github.com>
Message-ID: <sFf6NdogsR1P13IA1_y3KFwlaSL3OPrBzDKeCwCdH40=.a25f620f-9c8f-458d-aeb6-91af779ae2d7@github.com>

On Fri, 20 Feb 2026 12:51:12 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Hot on the heals of #29288, this PR replaces `ArrayDeque` with `ArrayList` for the Inflater cache implementation in `ZipFile.CleanableResource`.
>> 
>> With this PR, we change the order of the cache from a FIFO queue to a LIFO stack backed by ArrayList. The order seems unimportant, and has indeed been LIFO in the past when using `java.util.Vector`. Intuitively, it should be better to return the most recently used Inflater.
>> 
>> No tests updated, strict refactoring, `noreg-cleanup`.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Add code comment about returning the most recently used Inflater from the cache
>  - Replace polling-style iteration with simple for loop
>  - Using add instead of addLast seems more natural for a List

With reviews from Jaikiran and Lance and Victor's question answered, I'l go ahead and integrate this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29430#issuecomment-3966180927

From eirbjo at openjdk.org  Thu Feb 26 12:06:44 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 26 Feb 2026 12:06:44 GMT
Subject: Integrated: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile
In-Reply-To: <QDvNIqpJBwz2AByfzrrgSs8tKMYI2JpTTkP6M_qoAyc=.9ac31c22-9c76-4bf8-8664-d075caf70ae0@github.com>
References: <QDvNIqpJBwz2AByfzrrgSs8tKMYI2JpTTkP6M_qoAyc=.9ac31c22-9c76-4bf8-8664-d075caf70ae0@github.com>
Message-ID: <Lo3bdXTrHiN_FEywPYR1rj0Z6fdJQMNXUR8T1yOv9ZU=.e3d5c620-731c-4ecf-9bc2-4008ca65d177@github.com>

On Mon, 26 Jan 2026 20:06:03 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Hot on the heals of #29288, this PR replaces `ArrayDeque` with `ArrayList` for the Inflater cache implementation in `ZipFile.CleanableResource`.
> 
> With this PR, we change the order of the cache from a FIFO queue to a LIFO stack backed by ArrayList. The order seems unimportant, and has indeed been LIFO in the past when using `java.util.Vector`. Intuitively, it should be better to return the most recently used Inflater.
> 
> No tests updated, strict refactoring, `noreg-cleanup`.

This pull request has now been integrated.

Changeset: 173153e1
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/173153e1b25c5081d6e6886fe9588847f5a564b6
Stats:     23 lines in 1 file changed: 2 ins; 4 del; 17 mod

8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile

Reviewed-by: lancea, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/29430

From dfuchs at openjdk.org  Thu Feb 26 12:17:51 2026
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Feb 2026 12:17:51 GMT
Subject: RFR: 8369181: InflaterOutputStream: writing after finish() results
 in IllegalStateException instead of an IOException
In-Reply-To: <mnqiYjtOQiPhxB3Po5L4TFb1vch_b1_T4lWizpxEKRk=.148973c4-3242-4cf7-8e88-b1055a0c0045@github.com>
References: <mnqiYjtOQiPhxB3Po5L4TFb1vch_b1_T4lWizpxEKRk=.148973c4-3242-4cf7-8e88-b1055a0c0045@github.com>
Message-ID: <-d7UD3dkazJxcYacEDI2I-iN_a2nj-vaR6OE7DjerPk=.c4e4628c-49d2-4f76-bbf5-b2b1b842e9e8@github.com>

On Thu, 26 Feb 2026 11:28:17 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-8369181?
> 
> As noted in that issue, if `finish()` is called on a `InflaterOutputStream` that was constructed without passing a `Inflater`, then any subsequent `write()`s on that `InflaterOutputStream` result in an `IllegalStateException`, because we close the `Inflater` in `finish()`. The commit in this PR, fixes the issue by throwing the specified `IOException` in place of the `IllegalStateException`. 
> 
> At the same time, the documentation of `finish()` has been enhanced to clarify the current behaviour, through a `@implSpec`.
> 
> Alternative approaches of deprecating finish() and/or not closing the default Inflater were considered, but given the current long standing implementation of finish(), it was decided to merely specify the current behaviour of closing the  default Inflater in finish().
> 
> A new jtreg test has been added to reproduce the issue and verify the fix. tier1, tier2, tier3 testing of this change completed without any related issues.
> 
> I'll file a CSR shortly for this change.

I like this approach. I believe it's the best for keeping compatibility risks low. I was a bit uncertain about specifying calling `Inflater::close()`  when the implementation actually call `Inflater::end()` but this probably don't matter since it's only called on the default inflater which is not user-supplied.

src/java.base/share/classes/java/util/zip/InflaterOutputStream.java line 243:

> 241:         flush();
> 242:         if (usesDefaultInflater) {
> 243:             inf.end();

close() and end() are the same thing for the default inflater so I guess this is fine and not violating the spec.

src/java.base/share/classes/java/util/zip/InflaterOutputStream.java line 288:

> 286:         if (usesDefaultInflater && defaultInflaterClosed) {
> 287:             throw new IOException("Inflater closed");
> 288:         }

Since we're already checking for `closed` before checking for `null` I guess it makes sense to make this check here in second position. I wonder if it could/should be included in `ensureOpen()`? Maybe, or maybe  not - I see `ensureOpen()` is called from `finish()` too. So if we moved that check to `ensureOpen()` then calling `finish()` twice in succession would throw. What you have now will probably keep compatibility risk at minima.

-------------

PR Review: https://git.openjdk.org/jdk/pull/29935#pullrequestreview-3860485396
PR Review Comment: https://git.openjdk.org/jdk/pull/29935#discussion_r2858632959
PR Review Comment: https://git.openjdk.org/jdk/pull/29935#discussion_r2858648728

From jpai at openjdk.org  Thu Feb 26 12:25:05 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 26 Feb 2026 12:25:05 GMT
Subject: RFR: 8369181: InflaterOutputStream: writing after finish() results
 in IllegalStateException instead of an IOException
In-Reply-To: <-d7UD3dkazJxcYacEDI2I-iN_a2nj-vaR6OE7DjerPk=.c4e4628c-49d2-4f76-bbf5-b2b1b842e9e8@github.com>
References: <mnqiYjtOQiPhxB3Po5L4TFb1vch_b1_T4lWizpxEKRk=.148973c4-3242-4cf7-8e88-b1055a0c0045@github.com>
 <-d7UD3dkazJxcYacEDI2I-iN_a2nj-vaR6OE7DjerPk=.c4e4628c-49d2-4f76-bbf5-b2b1b842e9e8@github.com>
Message-ID: <KmUaqL1ZxSeozbRkOfDopa6qlCcTNnFZNdCHijNb8t0=.380af115-328f-4b5a-91f4-54a50e275103@github.com>

On Thu, 26 Feb 2026 12:03:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>  I wonder if it could/should be included in ensureOpen()? Maybe, or maybe not - I see ensureOpen() is called from finish() too. So if we moved that check to ensureOpen() then calling finish() twice in succession would throw. 

Right, in my initial experiment I had that check for closed inflater within ensureOpen() itself. But like you note, it will introduce these additional behavioural changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29935#discussion_r2858727210

From eirbjo at openjdk.org  Thu Feb 26 12:37:54 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 26 Feb 2026 12:37:54 GMT
Subject: RFR: 8378759: Make ZipFile.CleanableResource.inflaterCache field final
Message-ID: <03BUw7kBhqVcXAo3F62mFFTlTvzUyFtcNI2Dri6cALU=.d15e1620-2539-4f1e-ac6a-a422e3108dd5@github.com>

Please review this cleanup PR where we simplify synchronization on ZipFile's inflater cache.

Currently, the `ZipFile.CleanableResource.inflaterCache` field is non-final, is used in synchronization and is set to `null` to indicate a closed inflater cache. This complicates the state considerations for synchronization, requiring double-checking that the cache does not close under us. Generally, correctness of synchronizing on a non-final field which can also be null is hard to reason about.

This PR marks the `inflaterCache` field as `final` and introduces a boolean flag field to model the closed state explicitly. This allows synchronization to be simplified, double-checking to be removed and the closed state to be more obvious. If we want the future ZipFile to be less mutable, this is one step in that direction.

Cleanup refactoring, `noreg-cleanup`

-------------

Commit messages:
 - Clear inflaterCache before closing
 - Make inflaterCache field final and closed state explicit

Changes: https://git.openjdk.org/jdk/pull/29937/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29937&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378759
  Stats: 27 lines in 1 file changed: 5 ins; 11 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/29937.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29937/head:pull/29937

PR: https://git.openjdk.org/jdk/pull/29937

From eirbjo at openjdk.org  Thu Feb 26 12:56:17 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 26 Feb 2026 12:56:17 GMT
Subject: RFR: 8376477: Avoid loading empty Lock classes in Shutdown and
 ReferenceQueue [v2]
In-Reply-To: <6-UBeTJZMY7O7Ea5sthTbokGk4m-EQ3kP7R70UZLhWQ=.b5def993-854d-4b44-bd2d-46f978fb40f7@github.com>
References: <6-UBeTJZMY7O7Ea5sthTbokGk4m-EQ3kP7R70UZLhWQ=.b5def993-854d-4b44-bd2d-46f978fb40f7@github.com>
Message-ID: <ihBaoGWGW3ghsZFBA0ejVVmsC2L5Pag1CVvlU74nuW0=.3c465cbe-1727-4cc6-8a82-511fb9161fa0@github.com>

> Please review this PR which removes empty nested `Lock` classes in `java.lang.Shutdown` and `java.lang.ref.ReferenceQueue`. 
> 
> These are replaced with the more common "new Object()" idiom, which saves us loading these two nested classes.
> 
> Additionally, this PR marks the lock objects in `Shutdown` as `final`
> 
> This was initially discussed in https://mail.openjdk.org/pipermail/core-libs-dev/2026-January/157704.html.
> 
> Except the observability of the lock name class, this should be a strict refactoring. No tests updated, `noreg-cleanup`.

Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into remove-custom-lock-objects
 - Avoid loading custom empty Lock classes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29442/files
  - new: https://git.openjdk.org/jdk/pull/29442/files/4f17d3fa..efe287eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29442&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29442&range=00-01

  Stats: 579055 lines in 2288 files changed: 292519 ins; 262833 del; 23703 mod
  Patch: https://git.openjdk.org/jdk/pull/29442.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29442/head:pull/29442

PR: https://git.openjdk.org/jdk/pull/29442

From sgrinovero at openjdk.org  Thu Feb 26 13:30:49 2026
From: sgrinovero at openjdk.org (Sanne Grinovero)
Date: Thu, 26 Feb 2026 13:30:49 GMT
Subject: RFR: 8378759: Make ZipFile.CleanableResource.inflaterCache field
 final
In-Reply-To: <03BUw7kBhqVcXAo3F62mFFTlTvzUyFtcNI2Dri6cALU=.d15e1620-2539-4f1e-ac6a-a422e3108dd5@github.com>
References: <03BUw7kBhqVcXAo3F62mFFTlTvzUyFtcNI2Dri6cALU=.d15e1620-2539-4f1e-ac6a-a422e3108dd5@github.com>
Message-ID: <MMabvSNEYFAOJaJhmdnZ_f-8l4b1XHJQoJ0Slc0JlL4=.6fc67b10-d813-42c2-9a9a-1b20db4c3e00@github.com>

On Thu, 26 Feb 2026 12:23:44 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR where we simplify synchronization on ZipFile's inflater cache.
> 
> Currently, the `ZipFile.CleanableResource.inflaterCache` field is non-final, is used in synchronization and is set to `null` to indicate a closed inflater cache. This complicates the state considerations for synchronization, requiring double-checking that the cache does not close under us. Generally, correctness of synchronizing on a non-final field which can also be null is hard to reason about.
> 
> This PR marks the `inflaterCache` field as `final` and introduces a boolean flag field to model the closed state explicitly. This allows synchronization to be simplified, double-checking to be removed and the closed state to be more obvious. If we want the future ZipFile to be less mutable, this is one step in that direction.
> 
> Cleanup refactoring, `noreg-cleanup`

src/java.base/share/classes/java/util/zip/ZipFile.java line 753:

> 751:                 }
> 752:                 // close inflaters cache
> 753:                 inflaterCache.clear();

I agree that the pattern you propose looks easier to maintain, but I'm concerned about this possibly holding on to memory unnecessarily.

_Personally_ I'd prefer the JVM to handle a minor little complication for the sake of lower memory consumption, but if you all think this should be done, could you at least invoke `trimToSize()` on the list after clearing it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29937#discussion_r2859038105

From eirbjo at openjdk.org  Thu Feb 26 13:34:58 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 26 Feb 2026 13:34:58 GMT
Subject: RFR: 8378759: Make ZipFile.CleanableResource.inflaterCache field
 final
In-Reply-To: <MMabvSNEYFAOJaJhmdnZ_f-8l4b1XHJQoJ0Slc0JlL4=.6fc67b10-d813-42c2-9a9a-1b20db4c3e00@github.com>
References: <03BUw7kBhqVcXAo3F62mFFTlTvzUyFtcNI2Dri6cALU=.d15e1620-2539-4f1e-ac6a-a422e3108dd5@github.com>
 <MMabvSNEYFAOJaJhmdnZ_f-8l4b1XHJQoJ0Slc0JlL4=.6fc67b10-d813-42c2-9a9a-1b20db4c3e00@github.com>
Message-ID: <36O9as-9-IZc5aFRqN-qjsr-BbGB9ouImwBnYT5g1yM=.ecfcb036-f1b5-4894-9fdb-e1f4f4a0d87f@github.com>

On Thu, 26 Feb 2026 13:27:48 GMT, Sanne Grinovero <sgrinovero at openjdk.org> wrote:

> I agree that the pattern you propose looks easier to maintain, but I'm concerned about this possibly holding on to memory unnecessarily.

If the cleaning action is run from the Cleaner machinery, then the ZipFile is claimed by GC so no memory is being held on to. If the cleaning action is run from `ZipFile.close()`, then the ZipFile is no longer "usable" and client code should have no good reason to maintain references to the ZipFile.

That said, sure, we can trim the ArrayList to remove any large Object[] for the elements.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29937#discussion_r2859060808

From eirbjo at openjdk.org  Thu Feb 26 13:39:51 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 26 Feb 2026 13:39:51 GMT
Subject: RFR: 8378759: Make ZipFile.CleanableResource.inflaterCache field
 final [v2]
In-Reply-To: <03BUw7kBhqVcXAo3F62mFFTlTvzUyFtcNI2Dri6cALU=.d15e1620-2539-4f1e-ac6a-a422e3108dd5@github.com>
References: <03BUw7kBhqVcXAo3F62mFFTlTvzUyFtcNI2Dri6cALU=.d15e1620-2539-4f1e-ac6a-a422e3108dd5@github.com>
Message-ID: <iFuV7UujPYXJDUk7kKyiA2OGuIHtSObdrrjWVGST3kw=.ec472cff-a12e-417a-afa4-0b9978f72429@github.com>

> Please review this cleanup PR where we simplify synchronization on ZipFile's inflater cache.
> 
> Currently, the `ZipFile.CleanableResource.inflaterCache` field is non-final, is used in synchronization and is set to `null` to indicate a closed inflater cache. This complicates the state considerations for synchronization, requiring double-checking that the cache does not close under us. Generally, correctness of synchronizing on a non-final field which can also be null is hard to reason about.
> 
> This PR marks the `inflaterCache` field as `final` and introduces a boolean flag field to model the closed state explicitly. This allows synchronization to be simplified, double-checking to be removed and the closed state to be more obvious. If we want the future ZipFile to be less mutable, this is one step in that direction.
> 
> Cleanup refactoring, `noreg-cleanup`

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Reduce memory retained by a closed ZipFile

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29937/files
  - new: https://git.openjdk.org/jdk/pull/29937/files/a73afcae..6b9d8f98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29937&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29937&range=00-01

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/29937.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29937/head:pull/29937

PR: https://git.openjdk.org/jdk/pull/29937

From alanb at openjdk.org  Thu Feb 26 13:41:30 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Feb 2026 13:41:30 GMT
Subject: Integrated: 8378268: Thread.join can wait on Thread,
 allows joinNanos to be removed
In-Reply-To: <-ckkcXUkmMzpwb4p_Bc6rx_e25gD-5OhGuG6Uw8JYwg=.d8d7e10c-2218-41af-8167-9446684ace09@github.com>
References: <-ckkcXUkmMzpwb4p_Bc6rx_e25gD-5OhGuG6Uw8JYwg=.d8d7e10c-2218-41af-8167-9446684ace09@github.com>
Message-ID: <jg0kWEruZ24A-E-fPzJS9uYlO_RpnwGB8ZARDtjWF-M=.c7c14a77-0daa-4afc-976f-3d903950d74d@github.com>

On Fri, 20 Feb 2026 09:26:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.join was historically implemented with a loop of Object.wait conditioned on isAlive. We couldn't for this virtual threads because it would pin a virtual thread invoking join to it carrier.  Now that Object.wait preempts, it means the special implementation of join for virtual threads can be removed. Where possible, the notifyAll is elided as it adds to the cost of termination.
> 
> The implNote of the join methods is restored (this is implNote text, not spec, so no CSR required).
> 
> Testing: tier1-5

This pull request has now been integrated.

Changeset: b13a2916
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b13a291667535fdea30936ea5dc87f405e637069
Stats:     86 lines in 2 files changed: 10 ins; 64 del; 12 mod

8378268: Thread.join can wait on Thread, allows joinNanos to be removed

Reviewed-by: jpai, vklang

-------------

PR: https://git.openjdk.org/jdk/pull/29839

From eirbjo at openjdk.org  Thu Feb 26 14:32:53 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 26 Feb 2026 14:32:53 GMT
Subject: RFR: 8376477: Avoid loading empty Lock classes in Shutdown and
 ReferenceQueue [v2]
In-Reply-To: <ihBaoGWGW3ghsZFBA0ejVVmsC2L5Pag1CVvlU74nuW0=.3c465cbe-1727-4cc6-8a82-511fb9161fa0@github.com>
References: <6-UBeTJZMY7O7Ea5sthTbokGk4m-EQ3kP7R70UZLhWQ=.b5def993-854d-4b44-bd2d-46f978fb40f7@github.com>
 <ihBaoGWGW3ghsZFBA0ejVVmsC2L5Pag1CVvlU74nuW0=.3c465cbe-1727-4cc6-8a82-511fb9161fa0@github.com>
Message-ID: <jcW7R4yBaePNeoCDVLKoVNO37ZT_0ULdeP6HTinpiIU=.94870a4c-aa20-4bab-b8db-57ffad166b4a@github.com>

On Thu, 26 Feb 2026 12:56:17 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which removes empty nested `Lock` classes in `java.lang.Shutdown` and `java.lang.ref.ReferenceQueue`. 
>> 
>> These are replaced with the more common "new Object()" idiom, which saves us loading these two nested classes.
>> 
>> Additionally, this PR marks the lock objects in `Shutdown` as `final`
>> 
>> This was initially discussed in https://mail.openjdk.org/pipermail/core-libs-dev/2026-January/157704.html.
>> 
>> Except the observability of the lock name class, this should be a strict refactoring. No tests updated, `noreg-cleanup`.
>
> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into remove-custom-lock-objects
>  - Avoid loading custom empty Lock classes

Circling back to this PR now that the test fixes in #29455 is integrated.

I have synched this branch up with mainline and verified that the affected tests no longer fail in this PR.

While this PR is already marked ready for integration by the bots, I would appreciate a review after the latest merge commit, by @RogerRiggs, @shipilev or some other reviewer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29442#issuecomment-3967003149

From rriggs at openjdk.org  Thu Feb 26 14:44:58 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 26 Feb 2026 14:44:58 GMT
Subject: RFR: 8355536: Model preview enabled VM features in
 ClassFileFormatVersion [v10]
In-Reply-To: <aek27a5Md2X1hjD9det4GSoMv4b6Sq4aL3S0gL2jJjU=.bd21b811-d355-4019-97f9-40e5e66a2efe@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
 <aek27a5Md2X1hjD9det4GSoMv4b6Sq4aL3S0gL2jJjU=.bd21b811-d355-4019-97f9-40e5e66a2efe@github.com>
Message-ID: <vbEgxVjIcCL5ifqwwBKQF7gKZbKnhpTpnk0_jqXRkxI=.b84fc852-ca0c-4c8d-ba71-2058f5b85263@github.com>

On Thu, 26 Feb 2026 03:32:03 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 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 18 commits:
> 
>  - Tweak test
>  - More tweaks
>  - Refresh
>  - 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
>  - Fixes
>  - 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
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/d6044d3e...8e128d29

src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 61:

> 59:     /*
> 60:      * Summary of class file format evolution; previews are listed for
> 61:      * convenience, but they are not modeled by the RELEASE_ constants.

Suggestion:

     * convenience, but they are not modeled by the {@code RELEASE_} constants.

Might be a bit more readable.

src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 418:

> 416:      * This is a reflective preview API to allow tools running in Java runtime
> 417:      * environments with no preview feature enabled to examine preview VM
> 418:      * features, such as those present in {@code class} files.

I don't think class needs code font.

src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 500:

> 498:      */
> 499:     public Runtime.Version runtimeVersion() {
> 500:         if (this == PREVIEW_ENABLED)

Since PREVIEW_ENABLED is for the current version wouldn't it return the same Version string as the running system?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2859372408
PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2859391900
PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2859409739

From duke at openjdk.org  Thu Feb 26 15:03:39 2026
From: duke at openjdk.org (Luca Kellermann)
Date: Thu, 26 Feb 2026 15:03:39 GMT
Subject: RFR: 8378180: Compiling OpenJDK with C23 C-Compiler gives warning:
 initialization discards =?UTF-8?B?4oCYY29uc3TigJk=?= qualifier from pointer
 target type
In-Reply-To: <ZMgHMVJXCvSHKIQczEV88lEQge9p2IKAlF7g7x_bYwQ=.cc24304d-25ab-4aa9-bba7-ae4023820c0a@github.com>
References: <ZMgHMVJXCvSHKIQczEV88lEQge9p2IKAlF7g7x_bYwQ=.cc24304d-25ab-4aa9-bba7-ae4023820c0a@github.com>
Message-ID: <zqN6ArzWWz9uwx0zjyNsDS-F6k90pohBR4KALK2ICW0=.51328cfd-6311-41ba-9e2d-feefc59712ee@github.com>

On Thu, 26 Feb 2026 04:26:43 GMT, Jasmine Karthikeyan <jkarthikeyan at openjdk.org> wrote:

> Hi all, this is a quick patch to fix a build issue I encountered when updating my Linux system. [Glibc 2.43](https://lists.gnu.org/archive/html/info-gnu/2026-01/msg00005.html) changes the definition of some string related functions to return `const char*` when provided a `const char*` parameter, rather than the previous behavior of returning `char*`. I've fixed this by applying the `const` modifier, and casting to `char*` when needed. This should be backwards-compatible since assigning a non-const pointer to const is an implicit conversion. Thoughts and comments would be appreciated on whether this is the best way to fix this issue. Thanks!

src/java.base/unix/native/libjava/TimeZone_md.c line 98:

> 96:     static const char *zidir = "zoneinfo/";
> 97: 
> 98:     char* pos = (char*) strstr((const char *)str, zidir);

Suggestion:

    char *pos = strstr(str, zidir);

removing the first cast should also work here

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29929#discussion_r2859514812

From liach at openjdk.org  Thu Feb 26 15:34:59 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Feb 2026 15:34:59 GMT
Subject: RFR: 8355536: Model preview enabled VM features in
 ClassFileFormatVersion [v10]
In-Reply-To: <vbEgxVjIcCL5ifqwwBKQF7gKZbKnhpTpnk0_jqXRkxI=.b84fc852-ca0c-4c8d-ba71-2058f5b85263@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
 <aek27a5Md2X1hjD9det4GSoMv4b6Sq4aL3S0gL2jJjU=.bd21b811-d355-4019-97f9-40e5e66a2efe@github.com>
 <vbEgxVjIcCL5ifqwwBKQF7gKZbKnhpTpnk0_jqXRkxI=.b84fc852-ca0c-4c8d-ba71-2058f5b85263@github.com>
Message-ID: <kiwC3zXXd5O6XotY9QvmzCtmo2qjdjsEuu2GdTgm1Zs=.b2b0fa37-24ef-487a-8114-496a99e4d663@github.com>

On Thu, 26 Feb 2026 14:32:04 GMT, Roger Riggs <rriggs 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 18 commits:
>> 
>>  - Tweak test
>>  - More tweaks
>>  - Refresh
>>  - 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
>>  - Fixes
>>  - 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
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/d6044d3e...8e128d29
>
> src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 61:
> 
>> 59:     /*
>> 60:      * Summary of class file format evolution; previews are listed for
>> 61:      * convenience, but they are not modeled by the RELEASE_ constants.
> 
> Suggestion:
> 
>      * convenience, but they are not modeled by the {@code RELEASE_} constants.
> 
> Might be a bit more readable.

This is a block comment instead of javadoc, so I think leaving it as-is is ok.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2859706446

From liach at openjdk.org  Thu Feb 26 15:44:19 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Feb 2026 15:44:19 GMT
Subject: RFR: 8378759: Make ZipFile.CleanableResource.inflaterCache field
 final [v2]
In-Reply-To: <iFuV7UujPYXJDUk7kKyiA2OGuIHtSObdrrjWVGST3kw=.ec472cff-a12e-417a-afa4-0b9978f72429@github.com>
References: <03BUw7kBhqVcXAo3F62mFFTlTvzUyFtcNI2Dri6cALU=.d15e1620-2539-4f1e-ac6a-a422e3108dd5@github.com>
 <iFuV7UujPYXJDUk7kKyiA2OGuIHtSObdrrjWVGST3kw=.ec472cff-a12e-417a-afa4-0b9978f72429@github.com>
Message-ID: <Vhjliozr1KyAHGHWG3nONI5muhNwABT5noOTa2vK5Rw=.6214d6ee-5f99-4d19-b8cf-e28c4773eb51@github.com>

On Thu, 26 Feb 2026 13:39:51 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR where we simplify synchronization on ZipFile's inflater cache.
>> 
>> Currently, the `ZipFile.CleanableResource.inflaterCache` field is non-final, is used in synchronization and is set to `null` to indicate a closed inflater cache. This complicates the state considerations for synchronization, requiring double-checking that the cache does not close under us. Generally, correctness of synchronizing on a non-final field which can also be null is hard to reason about.
>> 
>> This PR marks the `inflaterCache` field as `final` and introduces a boolean flag field to model the closed state explicitly. This allows synchronization to be simplified, double-checking to be removed and the closed state to be more obvious. If we want the future ZipFile to be less mutable, this is one step in that direction.
>> 
>> Cleanup refactoring, `noreg-cleanup`
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce memory retained by a closed ZipFile

Old code ensured getInflater can fail properly when inflaterCache is null. This safety is lost in your refactor.

src/java.base/share/classes/java/util/zip/ZipFile.java line 736:

> 734:                 if (inflaterCacheClosed) {
> 735:                     // inflaters cache already closed - just end it.
> 736:                     inf.end();

In your new code, we always need to get the inflaterCache monitor to end an inflator when the cache is closed. Could be a regression.

-------------

PR Review: https://git.openjdk.org/jdk/pull/29937#pullrequestreview-3861810399
PR Review Comment: https://git.openjdk.org/jdk/pull/29937#discussion_r2859749076

From liach at openjdk.org  Thu Feb 26 15:52:14 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Feb 2026 15:52:14 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString
In-Reply-To: <vhF63SnjqY19jQdlrw6X4VWQZaQ7M41xndLWAzve-4k=.b8428e77-aaa3-4ec5-98c9-74932f6d4cbf@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
 <vhF63SnjqY19jQdlrw6X4VWQZaQ7M41xndLWAzve-4k=.b8428e77-aaa3-4ec5-98c9-74932f6d4cbf@github.com>
Message-ID: <ywzfC5cR68ssgBoAzNlhccYa3jPgYbIfPiHMkmgmp_c=.0888754d-44f9-4697-bde0-197856c479f7@github.com>

On Thu, 26 Feb 2026 10:17:54 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes
>
> src/java.base/share/classes/java/util/Base64.java line 351:
> 
>> 349:          */
>> 350:         public String encodeToString(byte[] src) {
>> 351:             byte[] encoded = encode(src);
> 
> Consider adding a comment here to make it clear that `encoded` is guaranteed to be ASCII-only.
> 
> Otherwise, using `uncheckedNewStringWithLatin1Bytes` would not be safe. Better to make this contract explicit with a comment.

`encoded` is already a well-behaved platform API, and this method already states:

> In other words, an invocation of this method has exactly the same effect as invoking `new String(encode(src), StandardCharsets.ISO_8859_1)`.

And this is exactly compatible with `uncheckedNewStringWithLatin1Bytes`.

Let's not add redundant comments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29920#discussion_r2859802886

From eirbjo at openjdk.org  Thu Feb 26 16:00:19 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 26 Feb 2026 16:00:19 GMT
Subject: RFR: 8378759: Make ZipFile.CleanableResource.inflaterCache field
 final [v2]
In-Reply-To: <Vhjliozr1KyAHGHWG3nONI5muhNwABT5noOTa2vK5Rw=.6214d6ee-5f99-4d19-b8cf-e28c4773eb51@github.com>
References: <03BUw7kBhqVcXAo3F62mFFTlTvzUyFtcNI2Dri6cALU=.d15e1620-2539-4f1e-ac6a-a422e3108dd5@github.com>
 <iFuV7UujPYXJDUk7kKyiA2OGuIHtSObdrrjWVGST3kw=.ec472cff-a12e-417a-afa4-0b9978f72429@github.com>
 <Vhjliozr1KyAHGHWG3nONI5muhNwABT5noOTa2vK5Rw=.6214d6ee-5f99-4d19-b8cf-e28c4773eb51@github.com>
Message-ID: <FZDSUnXdJCFldhn4zw4Ym9nfgr0Cmjuz-Ttor1BRWz0=.d104b6df-f10f-481b-a4b1-8eff8c6ec41b@github.com>

On Thu, 26 Feb 2026 15:40:59 GMT, Chen Liang <liach at openjdk.org> wrote:

> Old code ensured getInflater can fail properly when inflaterCache is null. This safety is lost in your refactor.

getInflater is only called from ZipFile::getInputStream which always holds a lock on the ZipFile instance while calling getInflater.

CleanableResource::run can either be run from a Cleaner, in which case nothing references the ZipFile and thus cannot call getInflater. Or it can be run via ZipFile::close, which always holds a lock on the ZipFile instance.

getInputStream will never call getInflater in the case where the inflaterCache is null, since ensureOpen and CleanableResource:run are run holding the same lock.

Even if it could, "fail properly" is a stretch. It would fail with an undocumented NPE, right?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29937#issuecomment-3967528684

From eirbjo at openjdk.org  Thu Feb 26 16:13:09 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 26 Feb 2026 16:13:09 GMT
Subject: RFR: 8378759: Make ZipFile.CleanableResource.inflaterCache field
 final [v2]
In-Reply-To: <FZDSUnXdJCFldhn4zw4Ym9nfgr0Cmjuz-Ttor1BRWz0=.d104b6df-f10f-481b-a4b1-8eff8c6ec41b@github.com>
References: <03BUw7kBhqVcXAo3F62mFFTlTvzUyFtcNI2Dri6cALU=.d15e1620-2539-4f1e-ac6a-a422e3108dd5@github.com>
 <iFuV7UujPYXJDUk7kKyiA2OGuIHtSObdrrjWVGST3kw=.ec472cff-a12e-417a-afa4-0b9978f72429@github.com>
 <Vhjliozr1KyAHGHWG3nONI5muhNwABT5noOTa2vK5Rw=.6214d6ee-5f99-4d19-b8cf-e28c4773eb51@github.com>
 <FZDSUnXdJCFldhn4zw4Ym9nfgr0Cmjuz-Ttor1BRWz0=.d104b6df-f10f-481b-a4b1-8eff8c6ec41b@github.com>
Message-ID: <we341-sXljxMP4mgvW9TR-WSHe8WjlI0j4-3-4wo12I=.31e13dc3-f204-4b1c-b3fb-443ea0f3402a@github.com>

On Thu, 26 Feb 2026 15:57:18 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Old code ensured getInflater can fail properly when inflaterCache is null. This safety is lost in your refactor.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29937#issuecomment-3967606886

From shade at openjdk.org  Thu Feb 26 16:15:50 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 26 Feb 2026 16:15:50 GMT
Subject: RFR: 8376477: Avoid loading empty Lock classes in Shutdown and
 ReferenceQueue [v2]
In-Reply-To: <ihBaoGWGW3ghsZFBA0ejVVmsC2L5Pag1CVvlU74nuW0=.3c465cbe-1727-4cc6-8a82-511fb9161fa0@github.com>
References: <6-UBeTJZMY7O7Ea5sthTbokGk4m-EQ3kP7R70UZLhWQ=.b5def993-854d-4b44-bd2d-46f978fb40f7@github.com>
 <ihBaoGWGW3ghsZFBA0ejVVmsC2L5Pag1CVvlU74nuW0=.3c465cbe-1727-4cc6-8a82-511fb9161fa0@github.com>
Message-ID: <kVG4Z1lXg5DjcJ9OHi4jTjGicWsFcF4VB-DwxdJNnuc=.2a9ce2e0-7753-44a0-bd21-2a7245808871@github.com>

On Thu, 26 Feb 2026 12:56:17 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which removes empty nested `Lock` classes in `java.lang.Shutdown` and `java.lang.ref.ReferenceQueue`. 
>> 
>> These are replaced with the more common "new Object()" idiom, which saves us loading these two nested classes.
>> 
>> Additionally, this PR marks the lock objects in `Shutdown` as `final`
>> 
>> This was initially discussed in https://mail.openjdk.org/pipermail/core-libs-dev/2026-January/157704.html.
>> 
>> Except the observability of the lock name class, this should be a strict refactoring. No tests updated, `noreg-cleanup`.
>
> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into remove-custom-lock-objects
>  - Avoid loading custom empty Lock classes

Looks fine to me, thanks.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29442#pullrequestreview-3862018884

From liach at openjdk.org  Thu Feb 26 16:18:20 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Feb 2026 16:18:20 GMT
Subject: RFR: 8378759: Make ZipFile.CleanableResource.inflaterCache field
 final [v2]
In-Reply-To: <iFuV7UujPYXJDUk7kKyiA2OGuIHtSObdrrjWVGST3kw=.ec472cff-a12e-417a-afa4-0b9978f72429@github.com>
References: <03BUw7kBhqVcXAo3F62mFFTlTvzUyFtcNI2Dri6cALU=.d15e1620-2539-4f1e-ac6a-a422e3108dd5@github.com>
 <iFuV7UujPYXJDUk7kKyiA2OGuIHtSObdrrjWVGST3kw=.ec472cff-a12e-417a-afa4-0b9978f72429@github.com>
Message-ID: <3Wfaq-vnzEMtqp6NrX1kU8Ay2PwWkfzoMe1l6LWb6Bg=.ec34a871-d800-4af9-9017-5f4f4ba55550@github.com>

On Thu, 26 Feb 2026 13:39:51 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR where we simplify synchronization on ZipFile's inflater cache.
>> 
>> Currently, the `ZipFile.CleanableResource.inflaterCache` field is non-final, is used in synchronization and is set to `null` to indicate a closed inflater cache. This complicates the state considerations for synchronization, requiring double-checking that the cache does not close under us. Generally, correctness of synchronizing on a non-final field which can also be null is hard to reason about.
>> 
>> This PR marks the `inflaterCache` field as `final` and introduces a boolean flag field to model the closed state explicitly. This allows synchronization to be simplified, double-checking to be removed and the closed state to be more obvious. If we want the future ZipFile to be less mutable, this is one step in that direction.
>> 
>> Cleanup refactoring, `noreg-cleanup`
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce memory retained by a closed ZipFile

I don't think this patch brings much value; the old model was working fine, and people already identified a few regressions with this supposedly optimization. It's not worth reviewers' time to go through "hey there's a specific undocumented caller constraint to this method that I hope will continue to work by chance" for a supposedly stylistic improvement.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29937#issuecomment-3967639980

From rriggs at openjdk.org  Thu Feb 26 16:27:17 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 26 Feb 2026 16:27:17 GMT
Subject: RFR: 8376477: Avoid loading empty Lock classes in Shutdown and
 ReferenceQueue [v2]
In-Reply-To: <ihBaoGWGW3ghsZFBA0ejVVmsC2L5Pag1CVvlU74nuW0=.3c465cbe-1727-4cc6-8a82-511fb9161fa0@github.com>
References: <6-UBeTJZMY7O7Ea5sthTbokGk4m-EQ3kP7R70UZLhWQ=.b5def993-854d-4b44-bd2d-46f978fb40f7@github.com>
 <ihBaoGWGW3ghsZFBA0ejVVmsC2L5Pag1CVvlU74nuW0=.3c465cbe-1727-4cc6-8a82-511fb9161fa0@github.com>
Message-ID: <JKJK9Ef0pGoK1Z0QTcyPuvRbhmC7HkLdtnXQ4qMfHSU=.ffc374da-f3d8-41d7-b62d-fc47cfa6dd09@github.com>

On Thu, 26 Feb 2026 12:56:17 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which removes empty nested `Lock` classes in `java.lang.Shutdown` and `java.lang.ref.ReferenceQueue`. 
>> 
>> These are replaced with the more common "new Object()" idiom, which saves us loading these two nested classes.
>> 
>> Additionally, this PR marks the lock objects in `Shutdown` as `final`
>> 
>> This was initially discussed in https://mail.openjdk.org/pipermail/core-libs-dev/2026-January/157704.html.
>> 
>> Except the observability of the lock name class, this should be a strict refactoring. No tests updated, `noreg-cleanup`.
>
> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into remove-custom-lock-objects
>  - Avoid loading custom empty Lock classes

Still good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29442#pullrequestreview-3862080948

From eirbjo at openjdk.org  Thu Feb 26 16:35:02 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 26 Feb 2026 16:35:02 GMT
Subject: RFR: 8378759: Make ZipFile.CleanableResource.inflaterCache field
 final [v2]
In-Reply-To: <3Wfaq-vnzEMtqp6NrX1kU8Ay2PwWkfzoMe1l6LWb6Bg=.ec34a871-d800-4af9-9017-5f4f4ba55550@github.com>
References: <03BUw7kBhqVcXAo3F62mFFTlTvzUyFtcNI2Dri6cALU=.d15e1620-2539-4f1e-ac6a-a422e3108dd5@github.com>
 <iFuV7UujPYXJDUk7kKyiA2OGuIHtSObdrrjWVGST3kw=.ec472cff-a12e-417a-afa4-0b9978f72429@github.com>
 <3Wfaq-vnzEMtqp6NrX1kU8Ay2PwWkfzoMe1l6LWb6Bg=.ec34a871-d800-4af9-9017-5f4f4ba55550@github.com>
Message-ID: <qiOf0l4XtQjUmadoIwLHrYOGiLtWqPWNkrrK9jorVmg=.fb0c949d-b265-4b20-8114-9b3e22d5aee8@github.com>

On Thu, 26 Feb 2026 16:15:14 GMT, Chen Liang <liach at openjdk.org> wrote:

> I don't think this patch brings much value; the old model was working fine, and people already identified a few regressions with this supposedly optimization. 

Noted. For reference, the motivation here was to make it more obvious to current and future maintainers why this synchronization is correct by making the lock object a constant and the closed state explicit. (I still have work to do to understand why the current model is working fine, other than trusting the lock of reported issues).  Optimization was not a goal here at all.

> It's not worth reviewers' time to go through "hey there's a specific undocumented caller constraint to this method that I hope will continue to work by chance" for a supposedly stylistic improvement.

I would not consider synchronizing on non-final fields as merely a "stylistic" issue, But fair enough, I can withdraw this PR :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29937#issuecomment-3967732243

From eirbjo at openjdk.org  Thu Feb 26 16:35:04 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 26 Feb 2026 16:35:04 GMT
Subject: Withdrawn: 8378759: Make ZipFile.CleanableResource.inflaterCache field
 final
In-Reply-To: <03BUw7kBhqVcXAo3F62mFFTlTvzUyFtcNI2Dri6cALU=.d15e1620-2539-4f1e-ac6a-a422e3108dd5@github.com>
References: <03BUw7kBhqVcXAo3F62mFFTlTvzUyFtcNI2Dri6cALU=.d15e1620-2539-4f1e-ac6a-a422e3108dd5@github.com>
Message-ID: <-cHjTmo_Huro491eHY4wMhedJD5M1qdAnMdGoDRf9_E=.ba32a325-8d9c-4ea1-846b-fa3fc301ff48@github.com>

On Thu, 26 Feb 2026 12:23:44 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR where we simplify synchronization on ZipFile's inflater cache.
> 
> Currently, the `ZipFile.CleanableResource.inflaterCache` field is non-final, is used in synchronization and is set to `null` to indicate a closed inflater cache. This complicates the state considerations for synchronization, requiring double-checking that the cache does not close under us. Generally, correctness of synchronizing on a non-final field which can also be null is hard to reason about.
> 
> This PR marks the `inflaterCache` field as `final` and introduces a boolean flag field to model the closed state explicitly. This allows synchronization to be simplified, double-checking to be removed and the closed state to be more obvious. If we want the future ZipFile to be less mutable, this is one step in that direction.
> 
> Cleanup refactoring, `noreg-cleanup`

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/29937

From eirbjo at openjdk.org  Thu Feb 26 16:37:23 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 26 Feb 2026 16:37:23 GMT
Subject: RFR: 8376477: Avoid loading empty Lock classes in Shutdown and
 ReferenceQueue [v2]
In-Reply-To: <ihBaoGWGW3ghsZFBA0ejVVmsC2L5Pag1CVvlU74nuW0=.3c465cbe-1727-4cc6-8a82-511fb9161fa0@github.com>
References: <6-UBeTJZMY7O7Ea5sthTbokGk4m-EQ3kP7R70UZLhWQ=.b5def993-854d-4b44-bd2d-46f978fb40f7@github.com>
 <ihBaoGWGW3ghsZFBA0ejVVmsC2L5Pag1CVvlU74nuW0=.3c465cbe-1727-4cc6-8a82-511fb9161fa0@github.com>
Message-ID: <wDTrrsxMi5v5aixSgNPM_h6NvAnWNpLF-j4z81CjOtE=.bcb1ac60-a436-47f8-91ce-e0f4d123665d@github.com>

On Thu, 26 Feb 2026 12:56:17 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which removes empty nested `Lock` classes in `java.lang.Shutdown` and `java.lang.ref.ReferenceQueue`. 
>> 
>> These are replaced with the more common "new Object()" idiom, which saves us loading these two nested classes.
>> 
>> Additionally, this PR marks the lock objects in `Shutdown` as `final`
>> 
>> This was initially discussed in https://mail.openjdk.org/pipermail/core-libs-dev/2026-January/157704.html.
>> 
>> Except the observability of the lock name class, this should be a strict refactoring. No tests updated, `noreg-cleanup`.
>
> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into remove-custom-lock-objects
>  - Avoid loading custom empty Lock classes

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29442#issuecomment-3967744594

From eirbjo at openjdk.org  Thu Feb 26 16:37:25 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 26 Feb 2026 16:37:25 GMT
Subject: Integrated: 8376477: Avoid loading empty Lock classes in Shutdown and
 ReferenceQueue
In-Reply-To: <6-UBeTJZMY7O7Ea5sthTbokGk4m-EQ3kP7R70UZLhWQ=.b5def993-854d-4b44-bd2d-46f978fb40f7@github.com>
References: <6-UBeTJZMY7O7Ea5sthTbokGk4m-EQ3kP7R70UZLhWQ=.b5def993-854d-4b44-bd2d-46f978fb40f7@github.com>
Message-ID: <ODrRzfjiPw1_JYsHXx0J8-5nJ-IIkS91Yn9AL2gB46k=.9acb7a98-57bf-4eb1-a8ab-cb566ccc3f38@github.com>

On Tue, 27 Jan 2026 10:01:34 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which removes empty nested `Lock` classes in `java.lang.Shutdown` and `java.lang.ref.ReferenceQueue`. 
> 
> These are replaced with the more common "new Object()" idiom, which saves us loading these two nested classes.
> 
> Additionally, this PR marks the lock objects in `Shutdown` as `final`
> 
> This was initially discussed in https://mail.openjdk.org/pipermail/core-libs-dev/2026-January/157704.html.
> 
> Except the observability of the lock name class, this should be a strict refactoring. No tests updated, `noreg-cleanup`.

This pull request has now been integrated.

Changeset: 8b805630
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b805630b4c54a8e9e489cff08f0260cd42dc362
Stats:     7 lines in 2 files changed: 0 ins; 2 del; 5 mod

8376477: Avoid loading empty Lock classes in Shutdown and ReferenceQueue

Reviewed-by: rriggs, shade

-------------

PR: https://git.openjdk.org/jdk/pull/29442

From eirbjo at openjdk.org  Thu Feb 26 17:00:04 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 26 Feb 2026 17:00:04 GMT
Subject: RFR: 8376582: Remove assert from default method in
 java.util.zip.Checksum interface
In-Reply-To: <upC2a0WFHO8ZgYTKY4uDIrtpERPGWBBXUURyfIXwIBI=.7c9d1606-cf97-4851-aa86-54a73d0858a0@github.com>
References: <upC2a0WFHO8ZgYTKY4uDIrtpERPGWBBXUURyfIXwIBI=.7c9d1606-cf97-4851-aa86-54a73d0858a0@github.com>
Message-ID: <RnIBsPYeuF21SDJjc-DqROg2hqq0-OJTQS5_1OeCA-I=.3d485f77-5265-46a2-8fa4-60eaa6a71d82@github.com>

On Wed, 28 Jan 2026 13:46:39 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which removes an `assert` from the default method `Checksum::update(ByteBuffer)`.
> 
> Since this is an interface, javac generates a synthetic inner class to capture the `$assertionsDisabled` information.
> 
> This is the only use of assert within default methods in `java.base`.
> 
> I do not think it carries its weight in terms of the loading the generated class, so I suggest we simply remove it. The method already returns when `pos > limit`.
> 
> Trivial cleanup, `noreg-cleanup`.

Withdrawing this PR because a solution to avoid the synthetic class is better found elsewhere.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29466#issuecomment-3967892997

From eirbjo at openjdk.org  Thu Feb 26 17:00:04 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 26 Feb 2026 17:00:04 GMT
Subject: Withdrawn: 8376582: Remove assert from default method in
 java.util.zip.Checksum interface
In-Reply-To: <upC2a0WFHO8ZgYTKY4uDIrtpERPGWBBXUURyfIXwIBI=.7c9d1606-cf97-4851-aa86-54a73d0858a0@github.com>
References: <upC2a0WFHO8ZgYTKY4uDIrtpERPGWBBXUURyfIXwIBI=.7c9d1606-cf97-4851-aa86-54a73d0858a0@github.com>
Message-ID: <nwM1xDtWKth5xBt8QYJp3i7PouSRL0fUWR3yHd85JD0=.f948b3c6-01be-4b2a-9a71-1dc4f7d23121@github.com>

On Wed, 28 Jan 2026 13:46:39 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which removes an `assert` from the default method `Checksum::update(ByteBuffer)`.
> 
> Since this is an interface, javac generates a synthetic inner class to capture the `$assertionsDisabled` information.
> 
> This is the only use of assert within default methods in `java.base`.
> 
> I do not think it carries its weight in terms of the loading the generated class, so I suggest we simply remove it. The method already returns when `pos > limit`.
> 
> Trivial cleanup, `noreg-cleanup`.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/29466

From nbenalla at openjdk.org  Thu Feb 26 18:36:39 2026
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 26 Feb 2026 18:36:39 GMT
Subject: RFR: 8309748: Improve host selection in `External Specifications`
 page [v3]
In-Reply-To: <pcpJDGRCtt4jewQ9_YFMBLEOHvWPhn1I2FmbV_B0XV0=.a4d037dc-df25-46f5-b1a8-d65435adbe8d@github.com>
References: <VRQeGKu9h86k5u3kjRt83_F3Ig42hAjgx8Es7rQDrR4=.12c9ad24-a8d1-4ce9-9e49-3dcb701007b7@github.com>
 <pcpJDGRCtt4jewQ9_YFMBLEOHvWPhn1I2FmbV_B0XV0=.a4d037dc-df25-46f5-b1a8-d65435adbe8d@github.com>
Message-ID: <D9GEvw9q2rRlpwbQJ_iCW_-NuMh68WHnEWI2q5XzSL8=.ac8d91d8-50a9-4708-a0e5-72a52b3ce1cb@github.com>

On Thu, 19 Feb 2026 07:59:52 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to improve selection by host name in the External Specifications page. After trying a list of checkboxes as used in the API summary pages and finding it not a suitable solution, I found that a select/dropdown menu works best for this page. 
>> 
>>  - [New external specs page](https://cr.openjdk.org/~hannesw/8309748/api.00/external-specs.html)
>>  - [Old external specs page](https://docs.oracle.com/en/java/javase/25/docs/api/external-specs.html) for comparsion
>> 
>> I also updated `@spec` tags in `java.lang.Character` to point to `www.unicode.org` rather than `unicode.org` to avoid a  `unicode.org` entry in the host list (other `@spec` tags use the `www.unicode.org` host name). The short `unicode.org` URL is still used elsewhere in the `java.lang.Character` class, I can update those links to the canonical host name as well if desired.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright headers

Looks good.

-------------

Marked as reviewed by nbenalla (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28863#pullrequestreview-3862871362

From hannesw at openjdk.org  Thu Feb 26 18:53:27 2026
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 26 Feb 2026 18:53:27 GMT
Subject: RFR: 8309748: Improve host selection in `External Specifications`
 page [v3]
In-Reply-To: <pcpJDGRCtt4jewQ9_YFMBLEOHvWPhn1I2FmbV_B0XV0=.a4d037dc-df25-46f5-b1a8-d65435adbe8d@github.com>
References: <VRQeGKu9h86k5u3kjRt83_F3Ig42hAjgx8Es7rQDrR4=.12c9ad24-a8d1-4ce9-9e49-3dcb701007b7@github.com>
 <pcpJDGRCtt4jewQ9_YFMBLEOHvWPhn1I2FmbV_B0XV0=.a4d037dc-df25-46f5-b1a8-d65435adbe8d@github.com>
Message-ID: <fckDmaLrjLY0QBwmhWEfMuXwK_PdRggitVkHUcYY3R8=.febbedb9-ebe0-45ba-bd4f-0004dc9a460d@github.com>

On Thu, 19 Feb 2026 07:59:52 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to improve selection by host name in the External Specifications page. After trying a list of checkboxes as used in the API summary pages and finding it not a suitable solution, I found that a select/dropdown menu works best for this page. 
>> 
>>  - [New external specs page](https://cr.openjdk.org/~hannesw/8309748/api.00/external-specs.html)
>>  - [Old external specs page](https://docs.oracle.com/en/java/javase/25/docs/api/external-specs.html) for comparsion
>> 
>> I also updated `@spec` tags in `java.lang.Character` to point to `www.unicode.org` rather than `unicode.org` to avoid a  `unicode.org` entry in the host list (other `@spec` tags use the `www.unicode.org` host name). The short `unicode.org` URL is still used elsewhere in the `java.lang.Character` class, I can update those links to the canonical host name as well if desired.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright headers

Thanks Nizar.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28863#issuecomment-3968537969

From hannesw at openjdk.org  Thu Feb 26 18:53:29 2026
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 26 Feb 2026 18:53:29 GMT
Subject: Integrated: 8309748: Improve host selection in `External
 Specifications` page
In-Reply-To: <VRQeGKu9h86k5u3kjRt83_F3Ig42hAjgx8Es7rQDrR4=.12c9ad24-a8d1-4ce9-9e49-3dcb701007b7@github.com>
References: <VRQeGKu9h86k5u3kjRt83_F3Ig42hAjgx8Es7rQDrR4=.12c9ad24-a8d1-4ce9-9e49-3dcb701007b7@github.com>
Message-ID: <5Ok_J2KwunbFi9rFl5Y0vnrzB4lsCXgroQ33rafgXRY=.80cfff61-2425-4607-9c11-30f8a7215575@github.com>

On Wed, 17 Dec 2025 08:45:01 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to improve selection by host name in the External Specifications page. After trying a list of checkboxes as used in the API summary pages and finding it not a suitable solution, I found that a select/dropdown menu works best for this page. 
> 
>  - [New external specs page](https://cr.openjdk.org/~hannesw/8309748/api.00/external-specs.html)
>  - [Old external specs page](https://docs.oracle.com/en/java/javase/25/docs/api/external-specs.html) for comparsion
> 
> I also updated `@spec` tags in `java.lang.Character` to point to `www.unicode.org` rather than `unicode.org` to avoid a  `unicode.org` entry in the host list (other `@spec` tags use the `www.unicode.org` host name). The short `unicode.org` URL is still used elsewhere in the `java.lang.Character` class, I can update those links to the canonical host name as well if desired.

This pull request has now been integrated.

Changeset: aa6c06e1
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aa6c06e1665cd44ae880824aedb3c861f0951cb1
Stats:     101 lines in 5 files changed: 71 ins; 3 del; 27 mod

8309748: Improve host selection in `External Specifications` page

Reviewed-by: nbenalla

-------------

PR: https://git.openjdk.org/jdk/pull/28863

From jvernee at openjdk.org  Thu Feb 26 19:19:59 2026
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 26 Feb 2026 19:19:59 GMT
Subject: RFR: 8378715: Use early field initialization for java.lang.invoke
 generated code
In-Reply-To: <2wMVCAGsEc_7qZioeEoxC1kZU2cfcaR2Wt9_Ftdras8=.0400105a-6cf6-49ab-bae6-9a64c7998dc4@github.com>
References: <2wMVCAGsEc_7qZioeEoxC1kZU2cfcaR2Wt9_Ftdras8=.0400105a-6cf6-49ab-bae6-9a64c7998dc4@github.com>
Message-ID: <IQPQUWnML2bNgs1ev0928L_W5SVmwMfOwK-mCbKjhJU=.535ed25f-4442-412b-b59b-68deb137f7b1@github.com>

On Wed, 25 Feb 2026 21:27:08 GMT, Chen Liang <liach at openjdk.org> wrote:

> With Flexible Constructor Bodies, the preferred way to assign fields for objects is to assign before making a super call. These are all sites in the JDK code that can migrate to the new preferred pattern. This change also allows these fields to be later declared ACC_STRICT_INIT when strict fields JEP is integrated.

Looks good. Are these really the only three cases in j.l.i. where we can do this change?

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29926#pullrequestreview-3863077836

From liach at openjdk.org  Thu Feb 26 19:22:09 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Feb 2026 19:22:09 GMT
Subject: RFR: 8378792: ObjectMethods.bootstrap missing getter validation
Message-ID: <QiYoOJBVd4Foi_Ci9NAeUnRKGyWQXPVddmG26Hcf99U=.44dd836c-298f-41d5-8e37-0bcc9d2562da@github.com>

During review of Valhalla lworld vs mainline patch, I noticed Valhalla has a fix for a mainline issue where there is no getter validation for ObjectMethods.bootstrap. We should upstream this fix to mainline to make lworld cleaner and make mainline more robust.

Before this fix, the invalid getters caused weird exceptions in method handle construction. Now they consistently throw IllegalArgumentException as specified.

-------------

Commit messages:
 - 8378792: ObjectMethods.bootstrap missing getter validation

Changes: https://git.openjdk.org/jdk/pull/29941/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29941&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378792
  Stats: 68 lines in 2 files changed: 43 ins; 4 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/29941.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29941/head:pull/29941

PR: https://git.openjdk.org/jdk/pull/29941

From duke at openjdk.org  Thu Feb 26 19:25:51 2026
From: duke at openjdk.org (Patrick Strawderman)
Date: Thu, 26 Feb 2026 19:25:51 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString
In-Reply-To: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
Message-ID: <rg-HvyOcx7EJLBMG8E4Yg4WJcsiSkUx_vWTAC8uFnhM=.528a3d44-0442-4597-abec-ac7baa9d9055@github.com>

On Wed, 25 Feb 2026 15:37:02 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes

I put together a JMH benchmark that tests `encodeToString` on various size inputs (100, 100, 10000), and here are the results running locally:

Baseline

Benchmark                              (inputSize)   Mode  Cnt      Score      Error   Units
Base64Encode.testBase64EncodeToString          100  thrpt   12  25830.222 ? 1515.781  ops/ms
Base64Encode.testBase64EncodeToString         1000  thrpt   12   6864.086 ?  361.713  ops/ms
Base64Encode.testBase64EncodeToString        10000  thrpt   12    413.448 ?   83.529  ops/ms


This patch:

Benchmark                              (inputSize)   Mode  Cnt      Score      Error   Units
Base64Encode.testBase64EncodeToString          100  thrpt   12  31614.860 ? 2434.919  ops/ms
Base64Encode.testBase64EncodeToString         1000  thrpt   12   9134.750 ?  315.348  ops/ms
Base64Encode.testBase64EncodeToString        10000  thrpt   12    706.133 ?  163.285  ops/ms


Looks like an improvement across the board just looking at throughput, I didn't run an allocation rate benchmark but it seems fairly clear to me it would show an improvement. I can clean up the benchmark and add it to this PR if desired.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29920#issuecomment-3968707787

From jvernee at openjdk.org  Thu Feb 26 19:26:42 2026
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 26 Feb 2026 19:26:42 GMT
Subject: RFR: 8378715: Use early field initialization for java.lang.invoke
 generated code
In-Reply-To: <IQPQUWnML2bNgs1ev0928L_W5SVmwMfOwK-mCbKjhJU=.535ed25f-4442-412b-b59b-68deb137f7b1@github.com>
References: <2wMVCAGsEc_7qZioeEoxC1kZU2cfcaR2Wt9_Ftdras8=.0400105a-6cf6-49ab-bae6-9a64c7998dc4@github.com>
 <IQPQUWnML2bNgs1ev0928L_W5SVmwMfOwK-mCbKjhJU=.535ed25f-4442-412b-b59b-68deb137f7b1@github.com>
Message-ID: <wv52H2ca5jYgkfOx1qwF85u4lYFBY4WD-q8NsO6YY10=.9856b18c-1c0b-4282-9eca-a5cc50105ac9@github.com>

On Thu, 26 Feb 2026 19:17:29 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Are these really the only three cases in j.l.i. where we can do this change?

I did a quick check as well, and you are addressing every case. I had honestly expected something in `InvokerBytecodeGenerator` as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29926#issuecomment-3968708322

From liach at openjdk.org  Thu Feb 26 19:31:31 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Feb 2026 19:31:31 GMT
Subject: RFR: 8378715: Use early field initialization for java.lang.invoke
 generated code
In-Reply-To: <2wMVCAGsEc_7qZioeEoxC1kZU2cfcaR2Wt9_Ftdras8=.0400105a-6cf6-49ab-bae6-9a64c7998dc4@github.com>
References: <2wMVCAGsEc_7qZioeEoxC1kZU2cfcaR2Wt9_Ftdras8=.0400105a-6cf6-49ab-bae6-9a64c7998dc4@github.com>
Message-ID: <qLPviPnkJ6YuSUs0XBMYnFT7HH4Cv75jTolbRhXTiOI=.fcf60b0e-b6a5-4e61-8943-757946a934c4@github.com>

On Wed, 25 Feb 2026 21:27:08 GMT, Chen Liang <liach at openjdk.org> wrote:

> With Flexible Constructor Bodies, the preferred way to assign fields for objects is to assign before making a super call. These are all sites in the JDK code that can migrate to the new preferred pattern. This change also allows these fields to be later declared ACC_STRICT_INIT when strict fields JEP is integrated.

Not only that, I think these are the only valid appearance sites of `CodeBuilder::invokespecial` that represent super calls instead of new instance creations and has associated field store instructions within the whole JDK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29926#issuecomment-3968733813

From rriggs at openjdk.org  Thu Feb 26 19:33:22 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 26 Feb 2026 19:33:22 GMT
Subject: RFR: 8378792: ObjectMethods.bootstrap missing getter validation
In-Reply-To: <QiYoOJBVd4Foi_Ci9NAeUnRKGyWQXPVddmG26Hcf99U=.44dd836c-298f-41d5-8e37-0bcc9d2562da@github.com>
References: <QiYoOJBVd4Foi_Ci9NAeUnRKGyWQXPVddmG26Hcf99U=.44dd836c-298f-41d5-8e37-0bcc9d2562da@github.com>
Message-ID: <K-C9QbzgyV83ILwHa3cEzZ_8ANaeKx0jeUq_ePN1Mrk=.2ae61e02-aafd-4cea-8e7e-98ae6d4641ac@github.com>

On Thu, 26 Feb 2026 19:15:14 GMT, Chen Liang <liach at openjdk.org> wrote:

> During review of Valhalla lworld vs mainline patch, I noticed Valhalla has a fix for a mainline issue where there is no getter validation for ObjectMethods.bootstrap. We should upstream this fix to mainline to make lworld cleaner and make mainline more robust.
> 
> Before this fix, the invalid getters caused weird exceptions in method handle construction. Now they consistently throw IllegalArgumentException as specified.

Marked as reviewed by rriggs (Reviewer).

test/jdk/java/lang/runtime/ObjectMethodsTest.java line 162:

> 160:     }
> 161: 
> 162:     record NamePlusType(String mn, MethodType mt) {}

Parameter/fields names of `name`, and `type` would make the uses below more readable.

-------------

PR Review: https://git.openjdk.org/jdk/pull/29941#pullrequestreview-3863131791
PR Review Comment: https://git.openjdk.org/jdk/pull/29941#discussion_r2860912640

From jvernee at openjdk.org  Thu Feb 26 19:33:23 2026
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 26 Feb 2026 19:33:23 GMT
Subject: RFR: 8378792: ObjectMethods.bootstrap missing getter validation
In-Reply-To: <QiYoOJBVd4Foi_Ci9NAeUnRKGyWQXPVddmG26Hcf99U=.44dd836c-298f-41d5-8e37-0bcc9d2562da@github.com>
References: <QiYoOJBVd4Foi_Ci9NAeUnRKGyWQXPVddmG26Hcf99U=.44dd836c-298f-41d5-8e37-0bcc9d2562da@github.com>
Message-ID: <L-CtRVPjw3PrPh6iuyEIuS3IayRWqtUDwbIuP4-3_DQ=.6d96a1fb-c72b-4c3b-8198-40628f1c301e@github.com>

On Thu, 26 Feb 2026 19:15:14 GMT, Chen Liang <liach at openjdk.org> wrote:

> During review of Valhalla lworld vs mainline patch, I noticed Valhalla has a fix for a mainline issue where there is no getter validation for ObjectMethods.bootstrap. We should upstream this fix to mainline to make lworld cleaner and make mainline more robust.
> 
> Before this fix, the invalid getters caused weird exceptions in method handle construction. Now they consistently throw IllegalArgumentException as specified.

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29941#pullrequestreview-3863134702

From liach at openjdk.org  Thu Feb 26 19:36:25 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Feb 2026 19:36:25 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString
In-Reply-To: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
Message-ID: <kMmB5w0QkdaPLfdWLLO-wI9ZvaA49XkA7QU5mv-kXNw=.c0d72053-2b19-442e-856f-be49367c9e33@github.com>

On Wed, 25 Feb 2026 15:37:02 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes

Yes, please add this new benchmark method to `Base64Encode` benchmark.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29920#issuecomment-3968757175

From jvernee at openjdk.org  Thu Feb 26 19:38:21 2026
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 26 Feb 2026 19:38:21 GMT
Subject: RFR: 8378715: Use early field initialization for java.lang.invoke
 generated code
In-Reply-To: <qLPviPnkJ6YuSUs0XBMYnFT7HH4Cv75jTolbRhXTiOI=.fcf60b0e-b6a5-4e61-8943-757946a934c4@github.com>
References: <2wMVCAGsEc_7qZioeEoxC1kZU2cfcaR2Wt9_Ftdras8=.0400105a-6cf6-49ab-bae6-9a64c7998dc4@github.com>
 <qLPviPnkJ6YuSUs0XBMYnFT7HH4Cv75jTolbRhXTiOI=.fcf60b0e-b6a5-4e61-8943-757946a934c4@github.com>
Message-ID: <Mq0lcgPOzxrrBYBv9K5qM1y2FO9mElW1Fm7oWyLA_i4=.486f60e4-1bc3-4588-8eaa-3d19f947c3b4@github.com>

On Thu, 26 Feb 2026 19:28:27 GMT, Chen Liang <liach at openjdk.org> wrote:

> Not only that, I think these are the only valid appearance sites of `CodeBuilder::invokespecial` that represent super calls instead of new instance creations and has associated field store instructions within the whole JDK.

I see a few more super calls in `SystemModulesPlugin` as well, but other than that I don't see any under the `src` dir.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29926#issuecomment-3968766250

From liach at openjdk.org  Thu Feb 26 19:42:24 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Feb 2026 19:42:24 GMT
Subject: RFR: 8378792: ObjectMethods.bootstrap missing getter validation
 [v2]
In-Reply-To: <QiYoOJBVd4Foi_Ci9NAeUnRKGyWQXPVddmG26Hcf99U=.44dd836c-298f-41d5-8e37-0bcc9d2562da@github.com>
References: <QiYoOJBVd4Foi_Ci9NAeUnRKGyWQXPVddmG26Hcf99U=.44dd836c-298f-41d5-8e37-0bcc9d2562da@github.com>
Message-ID: <ERTWfHsShOvkZiWQ1Pq2Y3UiOCeRFbHeauIRXXCwwJA=.ddb183f4-f9d7-4ba2-b9cf-b726358e3805@github.com>

> During review of Valhalla lworld vs mainline patch, I noticed Valhalla has a fix for a mainline issue where there is no getter validation for ObjectMethods.bootstrap. We should upstream this fix to mainline to make lworld cleaner and make mainline more robust.
> 
> Before this fix, the invalid getters caused weird exceptions in method handle construction. Now they consistently throw IllegalArgumentException as specified.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Name change as review recommended

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29941/files
  - new: https://git.openjdk.org/jdk/pull/29941/files/63c94366..880e110a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29941&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29941&range=00-01

  Stats: 15 lines in 1 file changed: 3 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/29941.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29941/head:pull/29941

PR: https://git.openjdk.org/jdk/pull/29941

From liach at openjdk.org  Thu Feb 26 19:42:26 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Feb 2026 19:42:26 GMT
Subject: RFR: 8378792: ObjectMethods.bootstrap missing getter validation
 [v2]
In-Reply-To: <K-C9QbzgyV83ILwHa3cEzZ_8ANaeKx0jeUq_ePN1Mrk=.2ae61e02-aafd-4cea-8e7e-98ae6d4641ac@github.com>
References: <QiYoOJBVd4Foi_Ci9NAeUnRKGyWQXPVddmG26Hcf99U=.44dd836c-298f-41d5-8e37-0bcc9d2562da@github.com>
 <K-C9QbzgyV83ILwHa3cEzZ_8ANaeKx0jeUq_ePN1Mrk=.2ae61e02-aafd-4cea-8e7e-98ae6d4641ac@github.com>
Message-ID: <ecN5ttpf4tQFV1pzt_KVZnv5ozDI1TJoo9tlQNj2xOg=.25c0bfb2-4e36-41ab-b7cf-2cc652141b8d@github.com>

On Thu, 26 Feb 2026 19:30:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Name change as review recommended
>
> test/jdk/java/lang/runtime/ObjectMethodsTest.java line 162:
> 
>> 160:     }
>> 161: 
>> 162:     record NamePlusType(String mn, MethodType mt) {}
> 
> Parameter/fields names of `name`, and `type` would make the uses below more readable.

I have renamed these two components, and extracted them in the test method to local variables early on to make the test code more concise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29941#discussion_r2860948595

From liach at openjdk.org  Thu Feb 26 20:20:09 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Feb 2026 20:20:09 GMT
Subject: RFR: 8378715: Use early field initialization for java.lang.invoke
 generated code
In-Reply-To: <2wMVCAGsEc_7qZioeEoxC1kZU2cfcaR2Wt9_Ftdras8=.0400105a-6cf6-49ab-bae6-9a64c7998dc4@github.com>
References: <2wMVCAGsEc_7qZioeEoxC1kZU2cfcaR2Wt9_Ftdras8=.0400105a-6cf6-49ab-bae6-9a64c7998dc4@github.com>
Message-ID: <p2L-lcSI_099aWzRBkqaC__koJkNh8svdMsvKHo5pEM=.43185615-db4f-41e0-be6e-26d87a7512ee@github.com>

On Wed, 25 Feb 2026 21:27:08 GMT, Chen Liang <liach at openjdk.org> wrote:

> With Flexible Constructor Bodies, the preferred way to assign fields for objects is to assign before making a super call. These are all sites in the JDK code that can migrate to the new preferred pattern. This change also allows these fields to be later declared ACC_STRICT_INIT when strict fields JEP is integrated.

I checked the SystemModulesPlugin ones and did not find any that performs field initialization in the constructors. I think I have covered all cases. Thanks for the review! I ran tier 1-3 on linux-x64, all green, should be good to go.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29926#issuecomment-3968987029

From liach at openjdk.org  Thu Feb 26 20:20:10 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Feb 2026 20:20:10 GMT
Subject: Integrated: 8378715: Use early field initialization for
 java.lang.invoke generated code
In-Reply-To: <2wMVCAGsEc_7qZioeEoxC1kZU2cfcaR2Wt9_Ftdras8=.0400105a-6cf6-49ab-bae6-9a64c7998dc4@github.com>
References: <2wMVCAGsEc_7qZioeEoxC1kZU2cfcaR2Wt9_Ftdras8=.0400105a-6cf6-49ab-bae6-9a64c7998dc4@github.com>
Message-ID: <PkJH9MrWw-fscJIXNAY3vo9wg4LRQxLx33Qqi4T6np4=.a5a5bcdf-fd5f-4ff6-b9c9-b0b40aa7805e@github.com>

On Wed, 25 Feb 2026 21:27:08 GMT, Chen Liang <liach at openjdk.org> wrote:

> With Flexible Constructor Bodies, the preferred way to assign fields for objects is to assign before making a super call. These are all sites in the JDK code that can migrate to the new preferred pattern. This change also allows these fields to be later declared ACC_STRICT_INIT when strict fields JEP is integrated.

This pull request has now been integrated.

Changeset: 5e85d99c
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5e85d99c360fa12042a42fb3ed8ceb50c733d7a0
Stats:     29 lines in 3 files changed: 10 ins; 12 del; 7 mod

8378715: Use early field initialization for java.lang.invoke generated code

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/29926

From duke at openjdk.org  Thu Feb 26 20:28:14 2026
From: duke at openjdk.org (Patrick Strawderman)
Date: Thu, 26 Feb 2026 20:28:14 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString
In-Reply-To: <kMmB5w0QkdaPLfdWLLO-wI9ZvaA49XkA7QU5mv-kXNw=.c0d72053-2b19-442e-856f-be49367c9e33@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
 <kMmB5w0QkdaPLfdWLLO-wI9ZvaA49XkA7QU5mv-kXNw=.c0d72053-2b19-442e-856f-be49367c9e33@github.com>
Message-ID: <dzI_UDhSDI1b7WKl4mv-TKXm5ECcIInSOHZwKbaSs84=.5bbec7b4-9a3b-4f33-b79e-2c27ddab4619@github.com>

On Thu, 26 Feb 2026 19:33:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> Yes, please add this new benchmark method to `Base64Encode` benchmark.

Okay, it was a little easier to just add a new benchmark class rather than rework the existing one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29920#issuecomment-3969030054

From duke at openjdk.org  Thu Feb 26 20:28:12 2026
From: duke at openjdk.org (Patrick Strawderman)
Date: Thu, 26 Feb 2026 20:28:12 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString [v2]
In-Reply-To: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
Message-ID: <L67gEnD0GzudCEK9iFqWlRgfzdKjqO-bzZ4FbBVvIEo=.7f839ee8-9b52-4f96-9abe-046bee6abbc3@github.com>

> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes

Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:

  Add JMH benchmark for encodeToString

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29920/files
  - new: https://git.openjdk.org/jdk/pull/29920/files/d007ca46..458236ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29920&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29920&range=00-01

  Stats: 54 lines in 1 file changed: 54 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29920.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29920/head:pull/29920

PR: https://git.openjdk.org/jdk/pull/29920

From liach at openjdk.org  Thu Feb 26 20:39:19 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Feb 2026 20:39:19 GMT
Subject: RFR: 8378759: Make ZipFile.CleanableResource.inflaterCache field
 final [v2]
In-Reply-To: <iFuV7UujPYXJDUk7kKyiA2OGuIHtSObdrrjWVGST3kw=.ec472cff-a12e-417a-afa4-0b9978f72429@github.com>
References: <03BUw7kBhqVcXAo3F62mFFTlTvzUyFtcNI2Dri6cALU=.d15e1620-2539-4f1e-ac6a-a422e3108dd5@github.com>
 <iFuV7UujPYXJDUk7kKyiA2OGuIHtSObdrrjWVGST3kw=.ec472cff-a12e-417a-afa4-0b9978f72429@github.com>
Message-ID: <05q2Kg2NVk-o0IizIiMQetu1CB6PyS7ZHdQULOyrl-I=.7fb0e813-abfa-46b7-911f-e30a7c15ece0@github.com>

On Thu, 26 Feb 2026 13:39:51 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR where we simplify synchronization on ZipFile's inflater cache.
>> 
>> Currently, the `ZipFile.CleanableResource.inflaterCache` field is non-final, is used in synchronization and is set to `null` to indicate a closed inflater cache. This complicates the state considerations for synchronization, requiring double-checking that the cache does not close under us. Generally, correctness of synchronizing on a non-final field which can also be null is hard to reason about.
>> 
>> This PR marks the `inflaterCache` field as `final` and introduces a boolean flag field to model the closed state explicitly. This allows synchronization to be simplified, double-checking to be removed and the closed state to be more obvious. If we want the future ZipFile to be less mutable, this is one step in that direction.
>> 
>> Cleanup refactoring, `noreg-cleanup`
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce memory retained by a closed ZipFile

Thank you for your understanding. A lot of active reviewers' efforts are oriented toward new projects and developments so we often cannot afford revisiting code that has been running for decades without problems to triage the impact of minor improvements.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29937#issuecomment-3969089915

From rriggs at openjdk.org  Thu Feb 26 22:15:18 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 26 Feb 2026 22:15:18 GMT
Subject: RFR: 8378792: ObjectMethods.bootstrap missing getter validation
 [v2]
In-Reply-To: <ERTWfHsShOvkZiWQ1Pq2Y3UiOCeRFbHeauIRXXCwwJA=.ddb183f4-f9d7-4ba2-b9cf-b726358e3805@github.com>
References: <QiYoOJBVd4Foi_Ci9NAeUnRKGyWQXPVddmG26Hcf99U=.44dd836c-298f-41d5-8e37-0bcc9d2562da@github.com>
 <ERTWfHsShOvkZiWQ1Pq2Y3UiOCeRFbHeauIRXXCwwJA=.ddb183f4-f9d7-4ba2-b9cf-b726358e3805@github.com>
Message-ID: <cRbxtoOrGesE3cx7eWuNZkpkiFIeIRiHPVbuG7lg0rw=.c263a97e-76db-443d-aedf-019c1741a582@github.com>

On Thu, 26 Feb 2026 19:42:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> During review of Valhalla lworld vs mainline patch, I noticed Valhalla has a fix for a mainline issue where there is no getter validation for ObjectMethods.bootstrap. We should upstream this fix to mainline to make lworld cleaner and make mainline more robust.
>> 
>> Before this fix, the invalid getters caused weird exceptions in method handle construction. Now they consistently throw IllegalArgumentException as specified.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Name change as review recommended

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29941#pullrequestreview-3863821297

From rriggs at openjdk.org  Thu Feb 26 22:22:06 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 26 Feb 2026 22:22:06 GMT
Subject: RFR: 8378702: jdk.test.lib.Platform.isMusl() may return false
 negative on Alpine Linux
In-Reply-To: <ukKifiMQVSDMEFSaUfnxy7bBPLCDeQQ_W_F6JLnJySE=.aa00e770-2ce6-4ceb-a5eb-c74c4ad6aa29@github.com>
References: <ukKifiMQVSDMEFSaUfnxy7bBPLCDeQQ_W_F6JLnJySE=.aa00e770-2ce6-4ceb-a5eb-c74c4ad6aa29@github.com>
Message-ID: <AvOTOBEz9JsyTpmSO78Fkarz9upJoJqsvNUfIMoM-k4=.b0939329-a9f9-4ee0-af2d-904284ad301e@github.com>

On Wed, 25 Feb 2026 16:47:03 GMT, Frederic Thevenet <fthevenet at openjdk.org> wrote:

> jdk.test.lib.Platform.isMusl() may return false on Alpine linux, where it should return true.
> This means that the jtreg tests is is used to guard will incorrectly fail.
> This happens when tests deliberately clobber the  PATH and `ldd` can no longer be found. This PR uses a full path for `ldd` instead to work around the issue.

test/lib/jdk/test/lib/Platform.java line 200:

> 198:                 String l = b.readLine();
> 199:                 return (l != null && l.contains("musl"));
> 200:             } catch (Exception e) {}

Wouldn't it be better to at least print the exception to make it easier to diagnose.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29923#discussion_r2861558846

From dholmes at openjdk.org  Thu Feb 26 22:30:53 2026
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 26 Feb 2026 22:30:53 GMT
Subject: RFR: 8378702: jdk.test.lib.Platform.isMusl() may return false
 negative on Alpine Linux
In-Reply-To: <w13YIwQJ777alIj6QMuRj8IlUUXslHOc7xMVnaootFc=.0e7e731b-69aa-4257-9295-578a54bc0ffb@github.com>
References: <ukKifiMQVSDMEFSaUfnxy7bBPLCDeQQ_W_F6JLnJySE=.aa00e770-2ce6-4ceb-a5eb-c74c4ad6aa29@github.com>
 <9FDyzhrsY8u72jJV-8gVRbf4ONRw862ig3USKw7C9w0=.b18722a3-9006-4422-8bba-c6c603e13409@github.com>
 <w13YIwQJ777alIj6QMuRj8IlUUXslHOc7xMVnaootFc=.0e7e731b-69aa-4257-9295-578a54bc0ffb@github.com>
Message-ID: <Pfqr1YhqqWWPD1jqdsOO2I8fqZkrbXsSMXfHlAimNVQ=.fe011a26-7051-4804-88f2-1e5d29eee7ff@github.com>

On Thu, 26 Feb 2026 08:14:39 GMT, Frederic Thevenet <fthevenet at openjdk.org> wrote:

>> test/lib/jdk/test/lib/Platform.java line 196:
>> 
>>> 194:             ProcessBuilder pb = new ProcessBuilder(lddPath.get(), "--version");
>>> 195:             pb.redirectErrorStream(true);
>>> 196:             try (Process p = pb.start()) {
>> 
>> `Process` is not `AutoCloseable` - why are you using try-with-resources?
>
> `Process` implements `Closable` since https://bugs.openjdk.org/browse/JDK-8364361
> 
> Although on second thought, I agree it is worth considering whether or not we want to do this here, as it will make backporting this change less straight forward.

TIL ... okay but TBH it looks weird to me to use it this way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29923#discussion_r2861590301

From bperez at openjdk.org  Thu Feb 26 22:32:11 2026
From: bperez at openjdk.org (Ben Perez)
Date: Thu, 26 Feb 2026 22:32:11 GMT
Subject: RFR: 8368841: X25519 implementation differs from the specification
 in RFC 7748 [v4]
In-Reply-To: <c_dJLNLDU_f3_R5l-IX8FccJW6lAy6-TdzFlM_oEIJ0=.da3b9092-e3e7-4e34-84dd-178c94833a71@github.com>
References: <c_dJLNLDU_f3_R5l-IX8FccJW6lAy6-TdzFlM_oEIJ0=.da3b9092-e3e7-4e34-84dd-178c94833a71@github.com>
Message-ID: <HieSzoWFWiyJuT4Azezl4HhibWx8WDLzrzBmgYuZve8=.b517081f-1a59-42d4-97ec-3aed0996e03e@github.com>

> Our implementation of X25519 does not zero the MSB of the `u` coordinate as required by RFC 7748. Currently the test `jdk/sun/security/ec/xec/TestXDH.java` zeroes the bit manually while parsing test vectors, which is likely why this went uncaught.

Ben Perez has updated the pull request incrementally with one additional commit since the last revision:

  moved hexStringToBigInteger from Convert.java to TestXDH.java, no longer clears MSB

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29750/files
  - new: https://git.openjdk.org/jdk/pull/29750/files/0dd0c9d3..e00bd0fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29750&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29750&range=02-03

  Stats: 37 lines in 2 files changed: 16 ins; 19 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/29750.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29750/head:pull/29750

PR: https://git.openjdk.org/jdk/pull/29750

From liach at openjdk.org  Thu Feb 26 22:34:44 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Feb 2026 22:34:44 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString [v2]
In-Reply-To: <L67gEnD0GzudCEK9iFqWlRgfzdKjqO-bzZ4FbBVvIEo=.7f839ee8-9b52-4f96-9abe-046bee6abbc3@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
 <L67gEnD0GzudCEK9iFqWlRgfzdKjqO-bzZ4FbBVvIEo=.7f839ee8-9b52-4f96-9abe-046bee6abbc3@github.com>
Message-ID: <0C52iqFgcMvYMKXf74K3XCZetBss3U0gc8LDaMPGjgI=.8deaca41-1097-4c27-b36b-681d0e2114e1@github.com>

On Thu, 26 Feb 2026 20:28:12 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add JMH benchmark for encodeToString

Apparently the new benchmark takes 33 mins to be fully run. I recommend reducing the iterations as done in https://bugs.openjdk.org/browse/JDK-8287810.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29920#issuecomment-3969620680

From bperez at openjdk.org  Thu Feb 26 22:38:38 2026
From: bperez at openjdk.org (Ben Perez)
Date: Thu, 26 Feb 2026 22:38:38 GMT
Subject: RFR: 8368841: X25519 implementation differs from the specification
 in RFC 7748 [v5]
In-Reply-To: <c_dJLNLDU_f3_R5l-IX8FccJW6lAy6-TdzFlM_oEIJ0=.da3b9092-e3e7-4e34-84dd-178c94833a71@github.com>
References: <c_dJLNLDU_f3_R5l-IX8FccJW6lAy6-TdzFlM_oEIJ0=.da3b9092-e3e7-4e34-84dd-178c94833a71@github.com>
Message-ID: <uLuQkpGQwShm3JL2kw6sxYVOkWeXWonO_enVBml1Gj8=.695d7248-a2d4-409f-9fef-49a226a7a812@github.com>

> Our implementation of X25519 does not zero the MSB of the `u` coordinate as required by RFC 7748. Currently the test `jdk/sun/security/ec/xec/TestXDH.java` zeroes the bit manually while parsing test vectors, which is likely why this went uncaught.

Ben Perez has updated the pull request incrementally with one additional commit since the last revision:

  removed @build statement

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29750/files
  - new: https://git.openjdk.org/jdk/pull/29750/files/e00bd0fe..028e5ba0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29750&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29750&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29750.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29750/head:pull/29750

PR: https://git.openjdk.org/jdk/pull/29750

From weijun at openjdk.org  Thu Feb 26 22:49:06 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 26 Feb 2026 22:49:06 GMT
Subject: RFR: 8368841: X25519 implementation differs from the specification
 in RFC 7748 [v3]
In-Reply-To: <2N1k3PlPpZGwMY3p6pSP8o1ZnH0VDOmIMGSFs59smPY=.00d8c421-57d0-40c3-b31e-8b69f976c5d0@github.com>
References: <c_dJLNLDU_f3_R5l-IX8FccJW6lAy6-TdzFlM_oEIJ0=.da3b9092-e3e7-4e34-84dd-178c94833a71@github.com>
 <WcR-ShFFnhzlo9uJ0w8MVM0p67ipMeMdTcOLF4WbzWw=.951c61e5-3b19-4c4e-8c91-77a5c450dc15@github.com>
 <2N1k3PlPpZGwMY3p6pSP8o1ZnH0VDOmIMGSFs59smPY=.00d8c421-57d0-40c3-b31e-8b69f976c5d0@github.com>
Message-ID: <mxzhkT4Yj831D87RA4uNUvw5fzLsdaaYSYE0YX8ZKpk=.d29cd483-7b59-4aa5-ad07-f646194859cc@github.com>

On Tue, 24 Feb 2026 02:10:37 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed parsing functionality in TestXDH that manually clears MSB
>
> src/java.base/share/classes/sun/security/ec/XDHPublicKeyImpl.java line 59:
> 
>> 57: 
>> 58:         // RFC 7748 Section 5 requires the MSB of `u` to be zeroed for X25519
>> 59:         this.u = params.getName().equals("X448") ? u.mod(params.getP()) :
> 
> I think it would cleaner to compare `NamedParameterSpec` instead of the String.  `(paramSpec == NamedParameterSpec.X448) ?`.  For here an the other constructor.

But `paramSpec` is newly created and it won't be the same as the one defined in the class.

On the other hand, I do think we can compare `params` itself. It's only useful internally and these are only 2 instances.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29750#discussion_r2861655441

From bperez at openjdk.org  Thu Feb 26 23:05:55 2026
From: bperez at openjdk.org (Ben Perez)
Date: Thu, 26 Feb 2026 23:05:55 GMT
Subject: RFR: 8368841: X25519 implementation differs from the specification
 in RFC 7748 [v6]
In-Reply-To: <c_dJLNLDU_f3_R5l-IX8FccJW6lAy6-TdzFlM_oEIJ0=.da3b9092-e3e7-4e34-84dd-178c94833a71@github.com>
References: <c_dJLNLDU_f3_R5l-IX8FccJW6lAy6-TdzFlM_oEIJ0=.da3b9092-e3e7-4e34-84dd-178c94833a71@github.com>
Message-ID: <dDIKJcxxxMmGaQWEyjmEx3Kj9m_KcaZixE1i41N6ogk=.61a3b166-dda7-4206-a5a9-3c3b48ed6ad4@github.com>

> Our implementation of X25519 does not zero the MSB of the `u` coordinate as required by RFC 7748. Currently the test `jdk/sun/security/ec/xec/TestXDH.java` zeroes the bit manually while parsing test vectors, which is likely why this went uncaught.

Ben Perez has updated the pull request incrementally with one additional commit since the last revision:

  Changed params comparison

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29750/files
  - new: https://git.openjdk.org/jdk/pull/29750/files/028e5ba0..82416735

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29750&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29750&range=04-05

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/29750.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29750/head:pull/29750

PR: https://git.openjdk.org/jdk/pull/29750

From bperez at openjdk.org  Thu Feb 26 23:05:56 2026
From: bperez at openjdk.org (Ben Perez)
Date: Thu, 26 Feb 2026 23:05:56 GMT
Subject: RFR: 8368841: X25519 implementation differs from the specification
 in RFC 7748 [v3]
In-Reply-To: <mxzhkT4Yj831D87RA4uNUvw5fzLsdaaYSYE0YX8ZKpk=.d29cd483-7b59-4aa5-ad07-f646194859cc@github.com>
References: <c_dJLNLDU_f3_R5l-IX8FccJW6lAy6-TdzFlM_oEIJ0=.da3b9092-e3e7-4e34-84dd-178c94833a71@github.com>
 <WcR-ShFFnhzlo9uJ0w8MVM0p67ipMeMdTcOLF4WbzWw=.951c61e5-3b19-4c4e-8c91-77a5c450dc15@github.com>
 <2N1k3PlPpZGwMY3p6pSP8o1ZnH0VDOmIMGSFs59smPY=.00d8c421-57d0-40c3-b31e-8b69f976c5d0@github.com>
 <mxzhkT4Yj831D87RA4uNUvw5fzLsdaaYSYE0YX8ZKpk=.d29cd483-7b59-4aa5-ad07-f646194859cc@github.com>
Message-ID: <bFsnnK4MlguHU0JWeHdLbk_k4mCjtVFqWyWYuKgvn9Q=.ee7a4f52-e871-4b5a-b20a-51faa218f198@github.com>

On Thu, 26 Feb 2026 22:46:14 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ec/XDHPublicKeyImpl.java line 59:
>> 
>>> 57: 
>>> 58:         // RFC 7748 Section 5 requires the MSB of `u` to be zeroed for X25519
>>> 59:         this.u = params.getName().equals("X448") ? u.mod(params.getP()) :
>> 
>> I think it would cleaner to compare `NamedParameterSpec` instead of the String.  `(paramSpec == NamedParameterSpec.X448) ?`.  For here an the other constructor.
>
> But `paramSpec` is newly created and it won't be the same as the one defined in the class.
> 
> On the other hand, I do think we can compare `params` itself. It's only useful internally and these are only 2 instances.

Good catch. You're correct that comparing `paramSpec` won't work but `params` does.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29750#discussion_r2861725599

From liach at openjdk.org  Thu Feb 26 23:18:01 2026
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Feb 2026 23:18:01 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString [v2]
In-Reply-To: <L67gEnD0GzudCEK9iFqWlRgfzdKjqO-bzZ4FbBVvIEo=.7f839ee8-9b52-4f96-9abe-046bee6abbc3@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
 <L67gEnD0GzudCEK9iFqWlRgfzdKjqO-bzZ4FbBVvIEo=.7f839ee8-9b52-4f96-9abe-046bee6abbc3@github.com>
Message-ID: <9UFCjbJ2-EIx5-lqTGDvNCdolGfrYrGb9MMinujeQeQ=.2d490006-8014-4824-8eeb-ee6e0a039c40@github.com>

On Thu, 26 Feb 2026 20:28:12 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add JMH benchmark for encodeToString

My results with this benchmark (yes, took me two of 33:25 to run!)

Without patch:

Benchmark                                (inputSize)   Mode  Cnt      Score     Error   Units
Base64EncodeToString.testEncodeToString           10  thrpt   25  60318.739 ? 912.624  ops/ms
Base64EncodeToString.testEncodeToString          100  thrpt   25  34639.846 ? 564.989  ops/ms
Base64EncodeToString.testEncodeToString         1000  thrpt   25   4760.465 ?  66.707  ops/ms
Base64EncodeToString.testEncodeToString        10000  thrpt   25    416.867 ?   6.590  ops/ms


With patch:

Benchmark                                (inputSize)   Mode  Cnt      Score      Error   Units
Base64EncodeToString.testEncodeToString           10  thrpt   25  73585.221 ? 1250.220  ops/ms
Base64EncodeToString.testEncodeToString          100  thrpt   25  37766.561 ?  991.396  ops/ms
Base64EncodeToString.testEncodeToString         1000  thrpt   25   8198.071 ?  193.539  ops/ms
Base64EncodeToString.testEncodeToString        10000  thrpt   25    725.249 ?   11.494  ops/ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29920#issuecomment-3969795570

From asemenyuk at openjdk.org  Fri Feb 27 00:02:10 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 27 Feb 2026 00:02:10 GMT
Subject: Integrated: 8371438: jpackage should handle the case when "--mac-sign"
 is specified without signing identity options
In-Reply-To: <YfEBGJapqfeJcsFueUI8LP5xT6cc9Kk0eIc6tvCtvRc=.bfb229eb-a0cf-443f-b7b1-162cb7e2eaac@github.com>
References: <YfEBGJapqfeJcsFueUI8LP5xT6cc9Kk0eIc6tvCtvRc=.bfb229eb-a0cf-443f-b7b1-162cb7e2eaac@github.com>
Message-ID: <BmgmDcdlqYLSOarip5JAM-UCKLgyahGpgMIdtOTvjx0=.278c3585-f79a-4e42-a8ee-1aa4089c12dd@github.com>

On Sun, 18 Jan 2026 07:34:45 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Restore the logic of how jpackage handles cases when the "--mac-sign" option is specified without the "--mac-signing-key-user-name" or "--mac-app-image-sign-identity" option. 
> 
> Make it work as it did prior to the [JDK-8333664](https://bugs.openjdk.org/browse/JDK-8333664) patch, which caused jpackage to silently ignore the "--mac-sign" option and not sign the output bundle.
> 
> The restored behavior is as follows:
> 
> If the "--mac-sign" option is specified, jpackage will always attempt to sign the output bundle.
> 
> If none of the signing identity options ("--mac-signing-key-user-name", "--mac-app-image-sign-identity", or "--mac-installer-sign-identity") is specified, jpackage will look up for a signing identity (or signing identities in case of PKG bundling) in the keychain specified with the "--mac-signing-keychain", or in the default keychain of the current user if the "--mac-signing-keychain" option is not specified.
> 
> If the keychain contains exactly one signing certificate of a specific type (a certificate for signing an app image or a certificate for signing a PKG installer), jpackage will use it for signing. Otherwise, jpackage will exit with an error.
> 
> Added tests to cover the cases when the "--mac-sign" option is specified and the keychain has/doesn't have signing certificates.

This pull request has now been integrated.

Changeset: 4a6de12b
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4a6de12b3a356b4aec9049ec3ee1ee26cd4517bf
Stats:     1429 lines in 20 files changed: 1295 ins; 35 del; 99 mod

8371438: jpackage should handle the case when "--mac-sign" is specified without signing identity options

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/29290

From ascarpino at openjdk.org  Fri Feb 27 00:03:50 2026
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 27 Feb 2026 00:03:50 GMT
Subject: RFR: 8368841: X25519 implementation differs from the specification
 in RFC 7748 [v3]
In-Reply-To: <bFsnnK4MlguHU0JWeHdLbk_k4mCjtVFqWyWYuKgvn9Q=.ee7a4f52-e871-4b5a-b20a-51faa218f198@github.com>
References: <c_dJLNLDU_f3_R5l-IX8FccJW6lAy6-TdzFlM_oEIJ0=.da3b9092-e3e7-4e34-84dd-178c94833a71@github.com>
 <WcR-ShFFnhzlo9uJ0w8MVM0p67ipMeMdTcOLF4WbzWw=.951c61e5-3b19-4c4e-8c91-77a5c450dc15@github.com>
 <2N1k3PlPpZGwMY3p6pSP8o1ZnH0VDOmIMGSFs59smPY=.00d8c421-57d0-40c3-b31e-8b69f976c5d0@github.com>
 <mxzhkT4Yj831D87RA4uNUvw5fzLsdaaYSYE0YX8ZKpk=.d29cd483-7b59-4aa5-ad07-f646194859cc@github.com>
 <bFsnnK4MlguHU0JWeHdLbk_k4mCjtVFqWyWYuKgvn9Q=.ee7a4f52-e871-4b5a-b20a-51faa218f198@github.com>
Message-ID: <L-DRqoWzc_DhKDlbTHB2ifLJogr6blrFUi3-eW-kf80=.3d8026fd-0e79-4749-827e-db2212687aa4@github.com>

On Thu, 26 Feb 2026 23:01:22 GMT, Ben Perez <bperez at openjdk.org> wrote:

>> But `paramSpec` is newly created and it won't be the same as the one defined in the class.
>> 
>> On the other hand, I do think we can compare `params` itself. It's only useful internally and these are only 2 instances.
>
> Good catch. You're correct that comparing `paramSpec` won't work but `params` does.

Using `XECParameter.X448` is fine.

But I don't see why `paramSpec` wouldn't work as it is created from `params`.  With params set to `XECParameter.X448`, `new NamedParameterSpec(XECParameter.X448.getName())` would return the static `NamedParameterSpec.X448`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29750#discussion_r2861873026

From duke at openjdk.org  Fri Feb 27 00:32:07 2026
From: duke at openjdk.org (Patrick Strawderman)
Date: Fri, 27 Feb 2026 00:32:07 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString [v3]
In-Reply-To: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
Message-ID: <if8A10jM3snRUu7NLYRez3l8guLrt91U3poXIt83qiI=.023f7eda-a1cd-4e72-a1e0-1ac0da5d9b18@github.com>

> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes

Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:

  Reduce warmup and measurement iterations for benchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29920/files
  - new: https://git.openjdk.org/jdk/pull/29920/files/458236ba..a2fa6d14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29920&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29920&range=01-02

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29920.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29920/head:pull/29920

PR: https://git.openjdk.org/jdk/pull/29920

From duke at openjdk.org  Fri Feb 27 00:38:09 2026
From: duke at openjdk.org (Patrick Strawderman)
Date: Fri, 27 Feb 2026 00:38:09 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString [v2]
In-Reply-To: <0C52iqFgcMvYMKXf74K3XCZetBss3U0gc8LDaMPGjgI=.8deaca41-1097-4c27-b36b-681d0e2114e1@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
 <L67gEnD0GzudCEK9iFqWlRgfzdKjqO-bzZ4FbBVvIEo=.7f839ee8-9b52-4f96-9abe-046bee6abbc3@github.com>
 <0C52iqFgcMvYMKXf74K3XCZetBss3U0gc8LDaMPGjgI=.8deaca41-1097-4c27-b36b-681d0e2114e1@github.com>
Message-ID: <z6GfrWq9HbeRq0gcz2jfN314OM3H7-HJ93yqqk2kp8A=.5a74c096-9c00-49c8-babc-5db944822f5a@github.com>

On Thu, 26 Feb 2026 22:32:23 GMT, Chen Liang <liach at openjdk.org> wrote:

> Apparently the new benchmark takes 33 mins to be fully run. I recommend reducing the iterations as done in https://bugs.openjdk.org/browse/JDK-8287810.

Whoops, I just used the defaults. I've changed it to be more in line with the other benchmarks.

I've rerun it with the new settings and allocation information included, and this is what I get locally on an M1 Macbook.


make test TEST="micro:Base64EncodeToString" MICRO='RESULTS_FORMAT=JSON;OPTIONS=-prof gc'


baseline:

Benchmark                                                   (inputSize)   Mode  Cnt      Score      Error   Units
Base64EncodeToString.testEncodeToString                              10  thrpt   10  37077.450 ? 6720.486  ops/ms
Base64EncodeToString.testEncodeToString:gc.alloc.rate                10  thrpt   10   3109.573 ?  566.545  MB/sec
Base64EncodeToString.testEncodeToString:gc.alloc.rate.norm           10  thrpt   10     88.000 ?    0.001    B/op
Base64EncodeToString.testEncodeToString:gc.count                     10  thrpt   10    169.000             counts
Base64EncodeToString.testEncodeToString:gc.time                      10  thrpt   10    102.000                 ms
Base64EncodeToString.testEncodeToString                             100  thrpt   10  44531.727 ? 2228.099  ops/ms
Base64EncodeToString.testEncodeToString:gc.alloc.rate               100  thrpt   10  13928.036 ?  698.474  MB/sec
Base64EncodeToString.testEncodeToString:gc.alloc.rate.norm          100  thrpt   10    328.000 ?    0.001    B/op
Base64EncodeToString.testEncodeToString:gc.count                    100  thrpt   10    233.000             counts
Base64EncodeToString.testEncodeToString:gc.time                     100  thrpt   10    151.000                 ms
Base64EncodeToString.testEncodeToString                            1000  thrpt   10   8071.402 ?  334.834  ops/ms
Base64EncodeToString.testEncodeToString:gc.alloc.rate              1000  thrpt   10  20996.105 ?  871.475  MB/sec
Base64EncodeToString.testEncodeToString:gc.alloc.rate.norm         1000  thrpt   10   2728.000 ?    0.001    B/op
Base64EncodeToString.testEncodeToString:gc.count                   1000  thrpt   10    298.000             counts
Base64EncodeToString.testEncodeToString:gc.time                    1000  thrpt   10    191.000                 ms
Base64EncodeToString.testEncodeToString                           10000  thrpt   10    605.186 ?   19.722  ops/ms
Base64EncodeToString.testEncodeToString:gc.alloc.rate             10000  thrpt   10  15424.548 ?  502.632  MB/sec
Base64EncodeToString.testEncodeToString:gc.alloc.rate.norm        10000  thrpt   10  26728.006 ?    0.001    B/op
Base64EncodeToString.testEncodeToString:gc.count                  10000  thrpt   10    275.000             counts
Base64EncodeToString.testEncodeToString:gc.time                   10000  thrpt   10    176.000                 ms


With patch:


Benchmark                                                   (inputSize)   Mode  Cnt      Score      Error   Units
Base64EncodeToString.testEncodeToString                              10  thrpt   10  74105.364 ? 2901.628  ops/ms
Base64EncodeToString.testEncodeToString:gc.alloc.rate                10  thrpt   10   3957.248 ?  154.970  MB/sec
Base64EncodeToString.testEncodeToString:gc.alloc.rate.norm           10  thrpt   10     56.000 ?    0.001    B/op
Base64EncodeToString.testEncodeToString:gc.count                     10  thrpt   10    201.000             counts
Base64EncodeToString.testEncodeToString:gc.time                      10  thrpt   10    139.000                 ms
Base64EncodeToString.testEncodeToString                             100  thrpt   10  56614.125 ? 3686.741  ops/ms
Base64EncodeToString.testEncodeToString:gc.alloc.rate               100  thrpt   10   9497.667 ?  618.182  MB/sec
Base64EncodeToString.testEncodeToString:gc.alloc.rate.norm          100  thrpt   10    176.000 ?    0.001    B/op
Base64EncodeToString.testEncodeToString:gc.count                    100  thrpt   10    173.000             counts
Base64EncodeToString.testEncodeToString:gc.time                     100  thrpt   10    122.000                 ms
Base64EncodeToString.testEncodeToString                            1000  thrpt   10  10738.733 ? 1765.562  ops/ms
Base64EncodeToString.testEncodeToString:gc.alloc.rate              1000  thrpt   10  14090.662 ? 2316.935  MB/sec
Base64EncodeToString.testEncodeToString:gc.alloc.rate.norm         1000  thrpt   10   1376.000 ?    0.001    B/op
Base64EncodeToString.testEncodeToString:gc.count                   1000  thrpt   10    200.000             counts
Base64EncodeToString.testEncodeToString:gc.time                    1000  thrpt   10    150.000                 ms
Base64EncodeToString.testEncodeToString                           10000  thrpt   10    940.693 ?   91.054  ops/ms
Base64EncodeToString.testEncodeToString:gc.alloc.rate             10000  thrpt   10  11998.463 ? 1161.641  MB/sec
Base64EncodeToString.testEncodeToString:gc.alloc.rate.norm        10000  thrpt   10  13376.004 ?    0.001    B/op
Base64EncodeToString.testEncodeToString:gc.count                  10000  thrpt   10    158.000             counts
Base64EncodeToString.testEncodeToString:gc.time                   10000  thrpt   10    136.000                 ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29920#issuecomment-3970052161

From liach at openjdk.org  Fri Feb 27 00:57:55 2026
From: liach at openjdk.org (Chen Liang)
Date: Fri, 27 Feb 2026 00:57:55 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString [v3]
In-Reply-To: <if8A10jM3snRUu7NLYRez3l8guLrt91U3poXIt83qiI=.023f7eda-a1cd-4e72-a1e0-1ac0da5d9b18@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
 <if8A10jM3snRUu7NLYRez3l8guLrt91U3poXIt83qiI=.023f7eda-a1cd-4e72-a1e0-1ac0da5d9b18@github.com>
Message-ID: <v0uC1vhjV9xXi7-mw-yKon6ZWtZThMiEHs89wzpOyS8=.eb63c10b-2d06-4004-a57c-d90d7065c5fc@github.com>

On Fri, 27 Feb 2026 00:32:07 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce warmup and measurement iterations for benchmark

test/micro/org/openjdk/bench/java/util/Base64EncodeToString.java line 9:

> 7:  * published by the Free Software Foundation.  Oracle designates this
> 8:  * particular file as subject to the "Classpath" exception as provided
> 9:  * by Oracle in the LICENSE file that accompanied this code.

Suggestion:

 * published by the Free Software Foundation.


Note that tests do not have this exception.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29920#discussion_r2861996941

From sherman at openjdk.org  Fri Feb 27 01:39:56 2026
From: sherman at openjdk.org (Xueming Shen)
Date: Fri, 27 Feb 2026 01:39:56 GMT
Subject: RFR: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to
 intrinsify [v4]
In-Reply-To: <3Cj-8Ae4bGQs6soTjbPTNeOK1p6owLuGAVk72PySAZk=.a1527cf4-bf4d-4e02-89aa-81a578ca2dbb@github.com>
References: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
 <3Cj-8Ae4bGQs6soTjbPTNeOK1p6owLuGAVk72PySAZk=.a1527cf4-bf4d-4e02-89aa-81a578ca2dbb@github.com>
Message-ID: <5hj-HMzlpFdCLcn4uICkCMvnXUhbsnOSEQbZhu_i_bs=.eff601d1-66bf-40a9-a892-501e87bd02fc@github.com>

On Wed, 25 Feb 2026 11:05:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I ran following code with `-Djdk.incubator.vector.DEBUG=true`, however it was not intrinsified.
>> 
>> 
>>   public static void cos(){
>>     var rand = new Random();
>>     for(int i = 0; i < 1_000_000; i++){
>>       var vec = DoubleVector.fromArray(DoubleVector.SPECIES_256, rand.doubles().limit(4).toArray(), 0);
>> 
>>       vec.lanewise(VectorOperators.COS);
>>     }
>>   }
>> 
>> 
>> I knew `__jsvml_cos4_ha_l9()` in libjsvml.so should be called in this case (via vector debug log), but it was not hitted even though I set breakpoint in it.
>> 
>> `LaneType` has been introduced in [JDK-8376187](https://bugs.openjdk.org/browse/JDK-8376187), and `LibraryCallKit::inline_vector_call()` was updated to handle lane type rather than class of element type. However `VectorMathLibrary` wasn't modified.
>> 
>> I confirmed `__jsvml_cos4_ha_l9()` is called with this fix, and also all jdk/jdk/incubator/vector jtreg tests passed on Linux AMD64.
>
> Yasumasa Suenaga has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unnecesary file
>  - Update testcase
>  - Add comment

Tested tier1,tier2 & tier3: looks good.
https://mach5.us.oracle.com/mdash/jobs?search=id:xuemingshen-pr-29835-20260225-1747-41993911

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29835#issuecomment-3970218711

From duke at openjdk.org  Fri Feb 27 03:43:11 2026
From: duke at openjdk.org (Patrick Strawderman)
Date: Fri, 27 Feb 2026 03:43:11 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString [v4]
In-Reply-To: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
Message-ID: <WORvBabWLArBs9EVm47NdR8lwTKqOMo_VjrjdtVZNWY=.9fc17aff-d069-4385-9a61-c28a52f2f8c8@github.com>

> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes

Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:

  Update license for benchmark
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29920/files
  - new: https://git.openjdk.org/jdk/pull/29920/files/a2fa6d14..4e82915a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29920&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29920&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29920.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29920/head:pull/29920

PR: https://git.openjdk.org/jdk/pull/29920

From liach at openjdk.org  Fri Feb 27 04:24:20 2026
From: liach at openjdk.org (Chen Liang)
Date: Fri, 27 Feb 2026 04:24:20 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString [v4]
In-Reply-To: <WORvBabWLArBs9EVm47NdR8lwTKqOMo_VjrjdtVZNWY=.9fc17aff-d069-4385-9a61-c28a52f2f8c8@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
 <WORvBabWLArBs9EVm47NdR8lwTKqOMo_VjrjdtVZNWY=.9fc17aff-d069-4385-9a61-c28a52f2f8c8@github.com>
Message-ID: <lF_-loQdH4yDFr6BxSh4I-1Zj-f6G5t17bSmPDaTjwI=.38a984d3-fbc6-4dd8-9738-038f4f88994e@github.com>

On Fri, 27 Feb 2026 03:43:11 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update license for benchmark
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

Let's wait for at least another reviewer before integration.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29920#pullrequestreview-3864791469

From weijun at openjdk.org  Fri Feb 27 04:25:21 2026
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 27 Feb 2026 04:25:21 GMT
Subject: RFR: 8368841: X25519 implementation differs from the specification
 in RFC 7748 [v6]
In-Reply-To: <dDIKJcxxxMmGaQWEyjmEx3Kj9m_KcaZixE1i41N6ogk=.61a3b166-dda7-4206-a5a9-3c3b48ed6ad4@github.com>
References: <c_dJLNLDU_f3_R5l-IX8FccJW6lAy6-TdzFlM_oEIJ0=.da3b9092-e3e7-4e34-84dd-178c94833a71@github.com>
 <dDIKJcxxxMmGaQWEyjmEx3Kj9m_KcaZixE1i41N6ogk=.61a3b166-dda7-4206-a5a9-3c3b48ed6ad4@github.com>
Message-ID: <GJoiNsuXdIqUGyhWGj2CSWgdDE0izobMeuXEv-EN8Xk=.da429b36-2cf4-46c5-9244-188487df6c58@github.com>

On Thu, 26 Feb 2026 23:05:55 GMT, Ben Perez <bperez at openjdk.org> wrote:

>> Our implementation of X25519 does not zero the MSB of the `u` coordinate as required by RFC 7748. Currently the test `jdk/sun/security/ec/xec/TestXDH.java` zeroes the bit manually while parsing test vectors, which is likely why this went uncaught.
>
> Ben Perez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed params comparison

src/java.base/share/classes/sun/security/ec/XDHPublicKeyImpl.java line 94:

> 92:         this.u = (params == XECParameters.X448) ?
> 93:             new BigInteger(1, u_arr) :
> 94:             new BigInteger(1, u_arr).clearBit(255);

Aren't lines 86-89 already doing it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29750#discussion_r2862439402

From jbhateja at openjdk.org  Fri Feb 27 04:47:34 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 27 Feb 2026 04:47:34 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v15]
In-Reply-To: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
Message-ID: <up7EQAL7S0ys5dBV32C0nP4uKmisZg8w1mXKAiNRoOM=.2ed8a6e0-7ebf-415a-8d20-ab90ace5d765@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:

  Review resolutions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24104/files
  - new: https://git.openjdk.org/jdk/pull/24104/files/444a3568..9625b04e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=13-14

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 Feb 27 04:47:35 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 27 Feb 2026 04:47:35 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v14]
In-Reply-To: <HcMzc0JEWmkpKIySeUPbp3UNBCVQcz_qWCpGxlgTfhI=.3d6e0847-7adb-4b4b-8045-56c326f3cdb0@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <ZFFAsf3VHOHPTZc3NvS5Kq9NLUGyKL2T-Sh7RYW-_cs=.05b0d3b7-7702-488f-8e81-08c0a4086675@github.com>
 <HcMzc0JEWmkpKIySeUPbp3UNBCVQcz_qWCpGxlgTfhI=.3d6e0847-7adb-4b4b-8045-56c326f3cdb0@github.com>
Message-ID: <lPphNiU21uBY5On82Ot4MJ3Cg3iJ4r7ahb0WqFK5AqE=.e057e55c-3f6e-4b03-9617-148fba49fcb5@github.com>

On Wed, 25 Feb 2026 07:50:03 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> There are regression for these two cases. Do you know the root cause?
> 
> ```
> Before:
> VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   6204.489          ops/ms
> VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2   1651.334          ops/ms
> 
> After:
> VectorSliceBenchmark.intVectorSliceWithVariableIndex       1024  thrpt    2   5626.367          ops/ms
> VectorSliceBenchmark.longVectorSliceWithConstantIndex1     1024  thrpt    2    960.958          ops/ms
> ```

Hi @XiaohongGong  I observed that there is quite a lot of run to run variation in these micro even with stock JDK, I collected PMU events and found on AVX512 system there are MISALIGNED vector memory operation in fallback which causes this variation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3970737916

From jbhateja at openjdk.org  Fri Feb 27 04:47:37 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 27 Feb 2026 04:47:37 GMT
Subject: RFR: 8303762: Optimize vector slice operation with constant index
 using VPALIGNR instruction [v14]
In-Reply-To: <f7cpJTUpgGmh1np9qOinFg6YCmBK0qAE7xw-iJTtslI=.448a855b-9ad5-429b-a040-c24cec993661@github.com>
References: <oHhjicRldNzRK9vWNQFhpglJ-yICPm9ZgXH7VdwKaug=.8c5ec00b-7b29-4719-9d89-7dcbb28f6c79@github.com>
 <ZFFAsf3VHOHPTZc3NvS5Kq9NLUGyKL2T-Sh7RYW-_cs=.05b0d3b7-7702-488f-8e81-08c0a4086675@github.com>
 <f7cpJTUpgGmh1np9qOinFg6YCmBK0qAE7xw-iJTtslI=.448a855b-9ad5-429b-a040-c24cec993661@github.com>
Message-ID: <B_31tSme7R2WJKbPWo0BXh22BzIm_W1tqzI1X3qWOLs=.51c0a285-7394-4010-a54a-c6ffdfcdb30a@github.com>

On Wed, 25 Feb 2026 05:35:41 GMT, Eric Fang <erfang at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolution
>
> src/hotspot/share/opto/compile.cpp line 2065:
> 
>> 2063:     igvn_worklist()->ensure_empty(); // should be done with igvn
>> 2064: 
>> 2065:     while (inline_incrementally_one()) {
> 
> Is it possible to generate `_vector_late_inlines` candidate again in `inline_incrementally_one`?

`Compile::inline_vector_fallback(PhaseIterGVN& igvn) `inlines fallback implementation and if fallback is composed of intrinsics which are recorded in _late_inlines it attempts intrinsification. We don't append to _vector_late_inlines while executing fallback generator
https://github.com/jatin-bhateja/jdk/blob/444a35685eed8442b721795824cf0a43c7bb02f8/src/hotspot/share/opto/callGenerator.cpp#L722

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2862486751

From jbhateja at openjdk.org  Fri Feb 27 04:51:23 2026
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 27 Feb 2026 04:51:23 GMT
Subject: RFR: 8358521: Optimize vector operations by reassociating
 broadcasted inputs [v4]
In-Reply-To: <_k3M5u2VvDg1uyHvIzWKJ7I9EDrYl0RijaDnvwKCYrY=.b7353580-c3ed-47b0-a56c-26e039a6c2ac@github.com>
References: <0CXLtcNbnlzTPDzpy0MfO2fFXA7xLXa0CgiqQQops_4=.e43107dc-9280-4d67-ac2a-4f7516a1f479@github.com>
 <pOF2vnq6e-ycbGs8DKIkJiCQBXHMY-O9rea_Ua-giCM=.b21d2594-2375-41cc-8ff6-8491ac332ea2@github.com>
 <_k3M5u2VvDg1uyHvIzWKJ7I9EDrYl0RijaDnvwKCYrY=.b7353580-c3ed-47b0-a56c-26e039a6c2ac@github.com>
Message-ID: <u9e27-h0Kh_0ZHz9lk4FtxNNT4KYCcE0zLGkJflkjLI=.1875bada-d602-42db-9801-87b143f95369@github.com>

On Tue, 24 Feb 2026 08:42:52 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions
>
> Just scanned the PR description:
> 
>  VectorOperation (VectorBroadcast INP1) (VectorOperation (VectorBroadcast INP2) INP3) => 
>                              VectorOperation INP3 (VectorOperation (VectorBroadcast INP1) (VectorOperation INP2))
> 
> I think it should be `VectorBroadcast INP2` in both cases, and not `VectorOperation INP2`, because `INP2` is scalar, right?

Hi @eme64 , Please proceed with review, your comments have been addressed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25617#issuecomment-3970753993

From stuefe at openjdk.org  Fri Feb 27 06:16:26 2026
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 27 Feb 2026 06:16:26 GMT
Subject: RFR: 8377907: (process) Race in ProcessBuilder can cause JVM hangs
Message-ID: <JPOHltHN-kr96XXbnfTXmhgFNNpqcPBi7nbAQ0Ng08c=.4f2a2a3d-0b00-4c76-890f-ea9903607dc2@github.com>

When starting child processes from Java, we bootstrap the child process after fork and before exec. As part of that process, up to five pipes are handed to the child: three for stdin/out/err, respectively, and two internal communication pipes (fail and childenv).

If, concurrently with our invocation of `ProcessBuilder.start()`, third-party native code forks a child of its own, the natively forked child carries copies of these pipes. It then may keep these pipes open. This results in various forms of communication errors, most likely hangs - either in `ProcessBuilder.start()`, or in customer code. 

In the customer case that started this investigation, `ProcessBuilder.start()` hung intermittently when using a third-party Eclipse library that happened to perform forks natively.

The JVM has no full control over what happens in its process, since we allow native code to run. Therefore, native forks can happen, and we have to work around them. 

The fix makes sure that the pipes we use in ProcessBuilder are always tagged with CLOEXEC. Since forks are typically followed by execs, this will close any file descriptors that were accidentally inherited.

### FORK/VFORK mode

Here, it is sufficient to open all our pipes with O_CLOEXEC.

The caveat here is that only Linux offers an API to do that cleanly: `pipe2(2)` ([1]). On MacOS and AIX, we don't have `pipe2(2)`, so we need to emulate that behavior using `pipe(2)` and `fcntl(2)` in quick succession. That is still racy, since we did not completely close the time window within which pipe file descriptors are not O_CLOEXEC. But this is the best we can do.

### POSIX_SPAWN mode

Creating the pipes with CLOEXEC alone is not sufficient. With `posix_spawn(3)`, we exec twice: first to load the jspawnhelper (inside `posix_spawn(3)`), a second time to load the target binary. Pipes created with O_CLOEXEC would not survive the first exec.

Therefore, instead of manually `dup2(2)`'ing our file descriptors after the first exec in jspawnhelper itself, we set up dup2 file actions to let posix_spawn do the dup'ing. According to POSIX, these dup2 file actions will be processed before the kernel closes the inherited CLOEXEC file descriptors.

Unfortunately, macOS is again not POSIX-compliant, since the macOS kernel can close CLOEXEC file descriptors before posix_spawn processes them in its dup2 file actions. As a workaround for that bug, we create temporary copies of the pipe file descriptors that are untagged with CLOEXEC and use them as sources for posix_spawn dup2 actions. Of course, these file descriptor copies would again leak to concurrently forked processes. But since these are only temporary copies, that is benign.

### Code changes

We replace the manual file descriptor dup'ing in jspawnhelper with posix_spawn file actions. That means we can scrap everything associated with that: it is no longer necessary to pass file descriptors via command-line arguments to jspawnhelper or via the `ChildStuff` structure.

However, I tried to keep code reshuffling minimal and this patch as small as possible. While working on this code, I had a number of ideas for streamlining and improvements, but I will hold that off for future RFRs. This patch aims to be small and easily backportable.

-----------

Testing:

The patch adds three new tests:

1) `ConcNativeForkTest` is a reproducer for the "native concurrent forks cause hangs in ProcessBuilder.start()" problem. It is pretty good at provoking hangs in unpatched JVMs. However, it is not suited for automated CI/CD environments since it essentially fork-bombs itself. Therefore, I marked the test as "manual".

2) `PipesCloseOnExecTest` is a modified variant of `ConcNativeForkTest` that, instead of executing concurrent native forks, continuously checks that no file descriptors pop up untagged with CLOEXEC during a `ProcessBuilder` invocation. This test is fast and reliable, but it works only on Linux, since only with `pipe2(2)` we can completely close the !CLOEXEC time window. On MacOS and AIX, the test correctly spots untagged file descriptors since we still have the small time window between `pipe(2)` and `fcntl(2)`.

3) Finally, `FDLeaks` is a complementary test that checks that we don't accumulate unclosed file descriptors in ProcessBuilder.start().

- All tests in java/lang/ProcessBuilder were run, and all issues fixed. In particular, I tested:
	- Linux x64 with glibc
	- Linux x64 with muslc (Alpine)
	- MacOS Arm64
- Ran jdk + hotspot tier1 on Linux x64
- Tests on AIX are ongoing at SAP
- GHAs ran through successfully

[1] https://linux.die.net/man/2/pipe2

-------------

Commit messages:
 - wip
 - copyrights
 - new test
 - start

Changes: https://git.openjdk.org/jdk/pull/29939/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29939&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377907
  Stats: 1250 lines in 16 files changed: 1123 ins; 54 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/29939.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29939/head:pull/29939

PR: https://git.openjdk.org/jdk/pull/29939

From stuefe at openjdk.org  Fri Feb 27 06:16:27 2026
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 27 Feb 2026 06:16:27 GMT
Subject: RFR: 8377907: (process) Race in ProcessBuilder can cause JVM hangs
In-Reply-To: <JPOHltHN-kr96XXbnfTXmhgFNNpqcPBi7nbAQ0Ng08c=.4f2a2a3d-0b00-4c76-890f-ea9903607dc2@github.com>
References: <JPOHltHN-kr96XXbnfTXmhgFNNpqcPBi7nbAQ0Ng08c=.4f2a2a3d-0b00-4c76-890f-ea9903607dc2@github.com>
Message-ID: <2IT88TOsnynye9sgwigD5ZlIz_-AjU4WBeXm1n8NH2Q=.67750ed8-d07f-434a-b2b5-3ca8da8e8771@github.com>

On Thu, 26 Feb 2026 15:16:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> When starting child processes from Java, we bootstrap the child process after fork and before exec. As part of that process, up to five pipes are handed to the child: three for stdin/out/err, respectively, and two internal communication pipes (fail and childenv).
> 
> If, concurrently with our invocation of `ProcessBuilder.start()`, third-party native code forks a child of its own, the natively forked child carries copies of these pipes. It then may keep these pipes open. This results in various forms of communication errors, most likely hangs - either in `ProcessBuilder.start()`, or in customer code. 
> 
> In the customer case that started this investigation, `ProcessBuilder.start()` hung intermittently when using a third-party Eclipse library that happened to perform forks natively.
> 
> The JVM has no full control over what happens in its process, since we allow native code to run. Therefore, native forks can happen, and we have to work around them. 
> 
> The fix makes sure that the pipes we use in ProcessBuilder are always tagged with CLOEXEC. Since forks are typically followed by execs, this will close any file descriptors that were accidentally inherited.
> 
> ### FORK/VFORK mode
> 
> Here, it is sufficient to open all our pipes with O_CLOEXEC.
> 
> The caveat here is that only Linux offers an API to do that cleanly: `pipe2(2)` ([1]). On MacOS and AIX, we don't have `pipe2(2)`, so we need to emulate that behavior using `pipe(2)` and `fcntl(2)` in quick succession. That is still racy, since we did not completely close the time window within which pipe file descriptors are not O_CLOEXEC. But this is the best we can do.
> 
> ### POSIX_SPAWN mode
> 
> Creating the pipes with CLOEXEC alone is not sufficient. With `posix_spawn(3)`, we exec twice: first to load the jspawnhelper (inside `posix_spawn(3)`), a second time to load the target binary. Pipes created with O_CLOEXEC would not survive the first exec.
> 
> Therefore, instead of manually `dup2(2)`'ing our file descriptors after the first exec in jspawnhelper itself, we set up dup2 file actions to let posix_spawn do the dup'ing. According to POSIX, these dup2 file actions will be processed before the kernel closes the inherited CLOEXEC file descriptors.
> 
> Unfortunately, macOS is again not POSIX-compliant, since the macOS kernel can close CLOEXEC file descriptors before posix_spawn processes them in its dup2 file actions. As a workaround for that bug, we create temporary copies of the pipe file descriptors that are untagged with CLOEXEC and use ...

ping @prrace and @simonis - could you give this a look? Thanks!

test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 61:

> 59:             // Route any stdout from the child process - be it jspawnhelper error messages or the output of "/bin/pwd" -
> 60:             // through to the parent process.
> 61:             p = new ProcessBuilder(CMD).inheritIO().start();

Reviewer Note:

JspawnhelperProtocol had a subtle issue: it implicitly relied on standard fork() redirection rules (everything redirected to the parent process) at the very beginning of jspawnhelper main(). This is because we scan in the grandfather process for the "posix_spawn:xx" string produced in the child process, but in the parent process, we don't set up Java inheritIO, instead just calling Runtime.exec(). 

I think this works more by accident, since before we dup2 the stdout fd in jspawnhelper, fork default redirection apply.

Since we now set up filedescriptors before launching jspawnhelper, this does not work anymore. We need to replace Runtime.exec() with ProcessBuilder.inheritIO in the parent process, and move the output scanning code from parent to grandparent.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29939#issuecomment-3971005281
PR Review Comment: https://git.openjdk.org/jdk/pull/29939#discussion_r2859717998

From alanb at openjdk.org  Fri Feb 27 10:34:21 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 27 Feb 2026 10:34:21 GMT
Subject: RFR: 8369181: InflaterOutputStream: writing after finish() results
 in IllegalStateException instead of an IOException
In-Reply-To: <mnqiYjtOQiPhxB3Po5L4TFb1vch_b1_T4lWizpxEKRk=.148973c4-3242-4cf7-8e88-b1055a0c0045@github.com>
References: <mnqiYjtOQiPhxB3Po5L4TFb1vch_b1_T4lWizpxEKRk=.148973c4-3242-4cf7-8e88-b1055a0c0045@github.com>
Message-ID: <wIlIpnqgn-uQIj98ds-MITYguwRKPJ02OYlNaxBBtqs=.92667f3d-405a-4662-983b-86ddb2cb7f3a@github.com>

On Thu, 26 Feb 2026 11:28:17 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-8369181?
> 
> As noted in that issue, if `finish()` is called on a `InflaterOutputStream` that was constructed without passing a `Inflater`, then any subsequent `write()`s on that `InflaterOutputStream` result in an `IllegalStateException`, because we close the `Inflater` in `finish()`. The commit in this PR, fixes the issue by throwing the specified `IOException` in place of the `IllegalStateException`. 
> 
> At the same time, the documentation of `finish()` has been enhanced to clarify the current behaviour, through a `@implSpec`.
> 
> Alternative approaches of deprecating finish() and/or not closing the default Inflater were considered, but given the current long standing implementation of finish(), it was decided to merely specify the current behaviour of closing the  default Inflater in finish().
> 
> A new jtreg test has been added to reproduce the issue and verify the fix. tier1, tier2, tier3 testing of this change completed without any related issues.
> 
> I'll file a CSR shortly for this change.

src/java.base/share/classes/java/util/zip/InflaterOutputStream.java line 224:

> 222: 
> 223:     /**
> 224:      * Forces writing any pending buffered decompressed data to the output stream,

What you would think about dropping the term "Force" from this method, and flush. They can simply say that they write any pending buffered decompress data to the underlying output stream.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29935#discussion_r2863651878

From fthevenet at openjdk.org  Fri Feb 27 11:37:25 2026
From: fthevenet at openjdk.org (Frederic Thevenet)
Date: Fri, 27 Feb 2026 11:37:25 GMT
Subject: RFR: 8378702: jdk.test.lib.Platform.isMusl() may return false
 negative on Alpine Linux
In-Reply-To: <AvOTOBEz9JsyTpmSO78Fkarz9upJoJqsvNUfIMoM-k4=.b0939329-a9f9-4ee0-af2d-904284ad301e@github.com>
References: <ukKifiMQVSDMEFSaUfnxy7bBPLCDeQQ_W_F6JLnJySE=.aa00e770-2ce6-4ceb-a5eb-c74c4ad6aa29@github.com>
 <AvOTOBEz9JsyTpmSO78Fkarz9upJoJqsvNUfIMoM-k4=.b0939329-a9f9-4ee0-af2d-904284ad301e@github.com>
Message-ID: <7Q6gTPe8xDPYMbYpmn7Lbyz7BzFkfDyRxeFqNaXa8xU=.5a5c0a6c-db24-4049-b7a2-07c9149c2151@github.com>

On Thu, 26 Feb 2026 22:18:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> jdk.test.lib.Platform.isMusl() may return false on Alpine linux, where it should return true.
>> This means that the jtreg tests is is used to guard will incorrectly fail.
>> This happens when tests deliberately clobber the  PATH and `ldd` can no longer be found. This PR uses a full path for `ldd` instead to work around the issue.
>
> test/lib/jdk/test/lib/Platform.java line 200:
> 
>> 198:                 String l = b.readLine();
>> 199:                 return (l != null && l.contains("musl"));
>> 200:             } catch (Exception e) {}
> 
> Wouldn't it be better to at least print the exception to make it easier to diagnose.

I'm glad you raise that point, because I actually feel the same, especially since printing the exception is the first thing I did when I started investigating the problem.
But, given that this is how the original test was written, I suspected this might have been done on purpose to avoid polluting the output, that some tests might be parsing as part of their operation.

Not sure this is justified; I just opted to minimize the risk of an unfortunate side-effect. But again, I agree better logging would probably have helped catching this way earlier.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29923#discussion_r2863895254

From rgiulietti at openjdk.org  Fri Feb 27 12:43:13 2026
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 27 Feb 2026 12:43:13 GMT
Subject: RFR: 8378833: Improve offset arithmetic in ArraysSupport::mismatch
Message-ID: <e23sdEos-dDbYqLzau4KV6s_-CdjCXXAWdP2onvr31w=.1750fce8-0ea1-4cd0-a8a5-4021cd2934a8@github.com>

Some of the `ArraysSupport::mismatch` family of methods compute offsets using a mix of `int` and `long` arithmetic.
This can lead to wrong results, which are then passed as arguments to an intrinsic method or to a Java method using `Unsafe`.

-------------

Commit messages:
 - 8378833: Improve offset arithmetic in ArraysSupport::mismatch

Changes: https://git.openjdk.org/jdk/pull/29957/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29957&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378833
  Stats: 13 lines in 1 file changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/29957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29957/head:pull/29957

PR: https://git.openjdk.org/jdk/pull/29957

From liach at openjdk.org  Fri Feb 27 12:48:23 2026
From: liach at openjdk.org (Chen Liang)
Date: Fri, 27 Feb 2026 12:48:23 GMT
Subject: RFR: 8378833: Improve offset arithmetic in ArraysSupport::mismatch
In-Reply-To: <e23sdEos-dDbYqLzau4KV6s_-CdjCXXAWdP2onvr31w=.1750fce8-0ea1-4cd0-a8a5-4021cd2934a8@github.com>
References: <e23sdEos-dDbYqLzau4KV6s_-CdjCXXAWdP2onvr31w=.1750fce8-0ea1-4cd0-a8a5-4021cd2934a8@github.com>
Message-ID: <PL33D2nbDBv6kpucMUoMSulBg3ghT3rNXXo5OwuXOXY=.18279f4f-a3a0-49e9-b6d5-971265c557b1@github.com>

On Fri, 27 Feb 2026 12:35:51 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Some of the `ArraysSupport::mismatch` family of methods compute offsets using a mix of `int` and `long` arithmetic.
> This can lead to wrong results, which are then passed as arguments to an intrinsic method or to a Java method using `Unsafe`.

And this is exactly why the base offsets are statically typed long in the first place...

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29957#pullrequestreview-3866770156

From alanb at openjdk.org  Fri Feb 27 13:27:25 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 27 Feb 2026 13:27:25 GMT
Subject: RFR: 8378833: Improve offset arithmetic in ArraysSupport::mismatch
In-Reply-To: <e23sdEos-dDbYqLzau4KV6s_-CdjCXXAWdP2onvr31w=.1750fce8-0ea1-4cd0-a8a5-4021cd2934a8@github.com>
References: <e23sdEos-dDbYqLzau4KV6s_-CdjCXXAWdP2onvr31w=.1750fce8-0ea1-4cd0-a8a5-4021cd2934a8@github.com>
Message-ID: <AAMpHCNrLa8GgfxDBk7kLvxR9_5Av6OGHykO_Ytr_ao=.96e2468b-a2a5-43b1-b813-8453654a4f68@github.com>

On Fri, 27 Feb 2026 12:35:51 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Some of the `ArraysSupport::mismatch` family of methods compute offsets using a mix of `int` and `long` arithmetic.
> This can lead to wrong results, which are then passed as arguments to an intrinsic method or to a Java method using `Unsafe`.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29957#pullrequestreview-3866933979

From dl at openjdk.org  Fri Feb 27 16:05:50 2026
From: dl at openjdk.org (Doug Lea)
Date: Fri, 27 Feb 2026 16:05:50 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v45]
In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
Message-ID: <mDF56rFPul7qSHpJGkc8wu-4QFIh8tL8bp2XmrwCfw4=.b4ee26d2-f289-43c5-9fc7-3f1c62fba423@github.com>

> Changes signal filtering to avoid possible starvation

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Undo some external submit and signalling changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28797/files
  - new: https://git.openjdk.org/jdk/pull/28797/files/1d3b4db4..35781c13

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=44
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=43-44

  Stats: 574 lines in 2 files changed: 216 ins; 107 del; 251 mod
  Patch: https://git.openjdk.org/jdk/pull/28797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28797/head:pull/28797

PR: https://git.openjdk.org/jdk/pull/28797

From rriggs at openjdk.org  Fri Feb 27 16:21:52 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 27 Feb 2026 16:21:52 GMT
Subject: RFR: 8378833: Improve offset arithmetic in ArraysSupport::mismatch
In-Reply-To: <e23sdEos-dDbYqLzau4KV6s_-CdjCXXAWdP2onvr31w=.1750fce8-0ea1-4cd0-a8a5-4021cd2934a8@github.com>
References: <e23sdEos-dDbYqLzau4KV6s_-CdjCXXAWdP2onvr31w=.1750fce8-0ea1-4cd0-a8a5-4021cd2934a8@github.com>
Message-ID: <8SGGny2ak6_W9NSC4mSn0A1zKYWmMgHRRRq6zVKkOqU=.23718e16-4ecf-41bf-bb38-52eefc66da6e@github.com>

On Fri, 27 Feb 2026 12:35:51 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Some of the `ArraysSupport::mismatch` family of methods compute offsets using a mix of `int` and `long` arithmetic.
> This can lead to wrong results, which are then passed as arguments to an intrinsic method or to a Java method using `Unsafe`.

looks good

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29957#pullrequestreview-3867803491

From rriggs at openjdk.org  Fri Feb 27 16:23:54 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 27 Feb 2026 16:23:54 GMT
Subject: RFR: 8378702: jdk.test.lib.Platform.isMusl() may return false
 negative on Alpine Linux
In-Reply-To: <7Q6gTPe8xDPYMbYpmn7Lbyz7BzFkfDyRxeFqNaXa8xU=.5a5c0a6c-db24-4049-b7a2-07c9149c2151@github.com>
References: <ukKifiMQVSDMEFSaUfnxy7bBPLCDeQQ_W_F6JLnJySE=.aa00e770-2ce6-4ceb-a5eb-c74c4ad6aa29@github.com>
 <AvOTOBEz9JsyTpmSO78Fkarz9upJoJqsvNUfIMoM-k4=.b0939329-a9f9-4ee0-af2d-904284ad301e@github.com>
 <7Q6gTPe8xDPYMbYpmn7Lbyz7BzFkfDyRxeFqNaXa8xU=.5a5c0a6c-db24-4049-b7a2-07c9149c2151@github.com>
Message-ID: <sGoVTD48HZLux64hfe7hMnjngHbwQaVC1smUYFsn5rw=.ebfdd60e-5c10-46cd-b2d6-fd2f47ce756e@github.com>

On Fri, 27 Feb 2026 11:32:54 GMT, Frederic Thevenet <fthevenet at openjdk.org> wrote:

>> test/lib/jdk/test/lib/Platform.java line 200:
>> 
>>> 198:                 String l = b.readLine();
>>> 199:                 return (l != null && l.contains("musl"));
>>> 200:             } catch (Exception e) {}
>> 
>> Wouldn't it be better to at least print the exception to make it easier to diagnose.
>
> I'm glad you raise that point, because I actually feel the same, especially since printing the exception is the first thing I did when I started investigating the problem.
> But, given that this is how the original code was written, I suspected this might have been done on purpose to avoid polluting the program's output, that some tests parse as part of their operation.
> 
> Not sure this is justified; I just opted to minimize the risk of an unfortunate side-effect. But again, I agree better logging would probably have helped catching this way earlier.

The default output stream for is stderr, and will not interfere with stdout used for regular output.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29923#discussion_r2865127401

From rriggs at openjdk.org  Fri Feb 27 16:32:23 2026
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 27 Feb 2026 16:32:23 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString [v4]
In-Reply-To: <WORvBabWLArBs9EVm47NdR8lwTKqOMo_VjrjdtVZNWY=.9fc17aff-d069-4385-9a61-c28a52f2f8c8@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
 <WORvBabWLArBs9EVm47NdR8lwTKqOMo_VjrjdtVZNWY=.9fc17aff-d069-4385-9a61-c28a52f2f8c8@github.com>
Message-ID: <ypqsfqEMBo8VNeyQdGUkNXzx9XFmbDvxy9IR1obe5M8=.2b08a206-b5df-495e-872d-17686e17f1e6@github.com>

On Fri, 27 Feb 2026 03:43:11 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update license for benchmark
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

Looks good.  Thanks for the JMH test.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29920#pullrequestreview-3867870340

From duke at openjdk.org  Fri Feb 27 16:36:32 2026
From: duke at openjdk.org (duke)
Date: Fri, 27 Feb 2026 16:36:32 GMT
Subject: RFR: 8378698: Optimize Base64.Encoder#encodeToString [v4]
In-Reply-To: <WORvBabWLArBs9EVm47NdR8lwTKqOMo_VjrjdtVZNWY=.9fc17aff-d069-4385-9a61-c28a52f2f8c8@github.com>
References: <V_Z9NittlwFHuF9NSK0EyK1AMs2B2A1XnYhgt9D8VbY=.1c12bd3d-b474-4eee-8222-fecd80f6456d@github.com>
 <WORvBabWLArBs9EVm47NdR8lwTKqOMo_VjrjdtVZNWY=.9fc17aff-d069-4385-9a61-c28a52f2f8c8@github.com>
Message-ID: <f42Gbw2wWJGdOFfdaA-_QOvRMoWkLXOduR5qIX9le7U=.cbdebe76-ec59-4463-a0cf-c9c10a3a3e0a@github.com>

On Fri, 27 Feb 2026 03:43:11 GMT, Patrick Strawderman <duke at openjdk.org> wrote:

>> Avoid a byte array copy in encodeToString by using JavaLangAccess#uncheckedNewStringWithLatin1Bytes
>
> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update license for benchmark
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

@kilink 
Your change (at version 4e82915aa112483ba5de7c357bba16ca44630551) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29920#issuecomment-3973890660

From vklang at openjdk.org  Fri Feb 27 16:52:28 2026
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 27 Feb 2026 16:52:28 GMT
Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed
 out [v45]
In-Reply-To: <mDF56rFPul7qSHpJGkc8wu-4QFIh8tL8bp2XmrwCfw4=.b4ee26d2-f289-43c5-9fc7-3f1c62fba423@github.com>
References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com>
 <mDF56rFPul7qSHpJGkc8wu-4QFIh8tL8bp2XmrwCfw4=.b4ee26d2-f289-43c5-9fc7-3f1c62fba423@github.com>
Message-ID: <yLsO5o_tvI2nvV67TckcDRrY91bkFJswc7dUP-U4YeU=.8a367b7e-4717-4ec5-a60d-6d655caa66af@github.com>

On Fri, 27 Feb 2026 16:05:50 GMT, Doug Lea <dl at openjdk.org> wrote:

>> Changes signal filtering to avoid possible starvation
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Undo some external submit and signalling changes

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1298:

> 1296:                 if (room < 0)
> 1297:                     throw new RejectedExecutionException("Queue capacity exceeded");
> 1298:                 if ((room == 0 || room == m ||

Not that it would make any visible difference, but I guess we could eliminate one conditional by doing something like `(room | m) == m`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2865250542

From psandoz at openjdk.org  Fri Feb 27 16:53:24 2026
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 27 Feb 2026 16:53:24 GMT
Subject: RFR: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to
 intrinsify [v4]
In-Reply-To: <3Cj-8Ae4bGQs6soTjbPTNeOK1p6owLuGAVk72PySAZk=.a1527cf4-bf4d-4e02-89aa-81a578ca2dbb@github.com>
References: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
 <3Cj-8Ae4bGQs6soTjbPTNeOK1p6owLuGAVk72PySAZk=.a1527cf4-bf4d-4e02-89aa-81a578ca2dbb@github.com>
Message-ID: <tLZiMTGiuJeuw7vWUEXn3DrPm2xg2WLSqEMZjIwP8VQ=.bb27955c-2386-472b-9a9e-32dd671ab9ca@github.com>

On Wed, 25 Feb 2026 11:05:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I ran following code with `-Djdk.incubator.vector.DEBUG=true`, however it was not intrinsified.
>> 
>> 
>>   public static void cos(){
>>     var rand = new Random();
>>     for(int i = 0; i < 1_000_000; i++){
>>       var vec = DoubleVector.fromArray(DoubleVector.SPECIES_256, rand.doubles().limit(4).toArray(), 0);
>> 
>>       vec.lanewise(VectorOperators.COS);
>>     }
>>   }
>> 
>> 
>> I knew `__jsvml_cos4_ha_l9()` in libjsvml.so should be called in this case (via vector debug log), but it was not hitted even though I set breakpoint in it.
>> 
>> `LaneType` has been introduced in [JDK-8376187](https://bugs.openjdk.org/browse/JDK-8376187), and `LibraryCallKit::inline_vector_call()` was updated to handle lane type rather than class of element type. However `VectorMathLibrary` wasn't modified.
>> 
>> I confirmed `__jsvml_cos4_ha_l9()` is called with this fix, and also all jdk/jdk/incubator/vector jtreg tests passed on Linux AMD64.
>
> Yasumasa Suenaga has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unnecesary file
>  - Update testcase
>  - Add comment

Marked as reviewed by psandoz (Reviewer).

test/hotspot/jtreg/compiler/vectorapi/TestVectorUnaryOpAndBinaryOp.java line 40:

> 38:  */
> 39: 
> 40: public class TestVectorUnaryOpAndBinaryOp {

One last comment, sorry did not notice before. Can we rename that to `TestVectorLibraryUnaryOpAndBinaryOp`? (I will approve no need for another review round for this change.)

-------------

PR Review: https://git.openjdk.org/jdk/pull/29835#pullrequestreview-3867975316
PR Review Comment: https://git.openjdk.org/jdk/pull/29835#discussion_r2865256085

From duke at openjdk.org  Fri Feb 27 17:48:04 2026
From: duke at openjdk.org (Sruthy Jayan)
Date: Fri, 27 Feb 2026 17:48:04 GMT
Subject: RFR: 8375045: Incorrect Interpretation of POSIX TZ Environment
 Variable on AIX.
Message-ID: <D2kIcRxdi48MWoH0UOgtJ0UWs7tUCsTgiOomjDlaDFk=.0fae9b13-6acd-42cb-9d39-7559f4cf1567@github.com>

Bug Reference : https://bugs.openjdk.org/browse/JDK-8375045

On AIX, the POSIX TZ environment variable is not interpreted as expected when it includes DST rules.
Example: `TZ=CET-1CEST,M3.5.0,M10.5.0`

The fix includes : 
The TZ environment variable is processed by first matching the full value against tzmappings, then retrying with the value truncated at the first comma if no match is found, and finally defaulting to GMT if no mapping exists.

This fixes the regression caused by https://bugs.openjdk.org/browse/JDK-8292899

Signed-off-by: Sruthy Jayan <srutjay1 at in.ibm.com>

-------------

Commit messages:
 - Fix to handle Incorrect Interpretation of POSIX TZ Environment Variable on AIX

Changes: https://git.openjdk.org/jdk/pull/29183/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29183&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8375045
  Stats: 61 lines in 1 file changed: 39 ins; 18 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/29183.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29183/head:pull/29183

PR: https://git.openjdk.org/jdk/pull/29183

From liach at openjdk.org  Fri Feb 27 17:52:23 2026
From: liach at openjdk.org (Chen Liang)
Date: Fri, 27 Feb 2026 17:52:23 GMT
Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v5]
In-Reply-To: <0gXvclAjJnz5LPRXjhklSd6elcyuSRhoVxTwI6PKChE=.0385da57-1d46-450b-a817-7832e7ee19b6@github.com>
References: <M5Kk3KWYQZ5UagIv_f-nNwN8gNby1VZP3TlFsXUkBwY=.bfb41c1f-091f-4df4-b68f-6155607db159@github.com>
 <0gXvclAjJnz5LPRXjhklSd6elcyuSRhoVxTwI6PKChE=.0385da57-1d46-450b-a817-7832e7ee19b6@github.com>
Message-ID: <SPwN_3M0hEkzskk90wETIMPdp7NFlh7pkdUYoc68UhE=.8de5f187-76db-4e0d-8631-c74d0d0f6fc5@github.com>

On Mon, 23 Feb 2026 17:05:27 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> `TreeMap` sub-maps use the default `IteratorSpliterator` implementation for `TreeMap$EntrySetView` which is slow for some operations, because `EntrySetView.size()` iterates all elements. This is most trivially shown by something like `largeTreeMap.tailMap(0L, false).entrySet().limit(1).count()` taking a long time. This showed up in my application, where it was trivial to mitigate by switching to a for loop, but I think the fix is easy enough.
>> 
>> `keySet()` does not have the same problem, as it provides a custom `Spliterator` implementation which is not `Spliterator.SIZED`, and returns `Long.MAX_VALUE` for `estimateSize()` (which is the recommended approach when the size is expensive to compute). I'm *assuming* this optimization was simply missed for the EntryIterator in the original implementation, but I don't know for sure.
>> 
>> This patch fixes the issue by using `Spliterators.spliteratorUnknownSize` for `EntrySetView`, marking the size as unknown avoids accidentally iterating the whole thing for simple operations.
>> 
>> 
>> Basic performance test: `map.tailMap(0L, false).entrySet().stream().limit(1).count()` for a `TreeMap` with `10_000_000` entries.
>> 
>> Before (keySet is fast using `SubMapKeyIterator`, entrySet is slow):
>> 
>> class java.util.TreeMap$KeySet
>>     .stream().limit(1).count() took 0.046ms
>>     spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807
>> class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView
>>     .stream().limit(1).count() took 218ms
>>     spliterator = IteratorSpliterator, estimateSize() = 9999999 
>> 
>> 
>> After (entrySet is now fast):
>> 
>> class java.util.TreeMap$KeySet
>> 	.stream().limit(1).count() took 0.017ms
>> 	spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807
>> class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView
>> 	.stream().limit(1).count() took 0.115419ms
>> 	spliterator = IteratorSpliterator, estimateSize() = 9223372036854775807
>> 
>> 
>> Behaviour is tested by the test cases added in https://bugs.openjdk.org/browse/JDK-8376698.
>> 
>> The Set default stream() implementation uses spliterator(), and since our spliterator() implementation is no longer late-binding (it eagerly creates the iterator), we override stream() to use a late-binding wrapper.
>
> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make stream() late-binding

I think this looks reasonable. Please wait for other reviewers; thanks.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28608#pullrequestreview-3868244868

From liach at openjdk.org  Fri Feb 27 17:55:33 2026
From: liach at openjdk.org (Chen Liang)
Date: Fri, 27 Feb 2026 17:55:33 GMT
Subject: RFR: 8378792: ObjectMethods.bootstrap missing getter validation
 [v2]
In-Reply-To: <ERTWfHsShOvkZiWQ1Pq2Y3UiOCeRFbHeauIRXXCwwJA=.ddb183f4-f9d7-4ba2-b9cf-b726358e3805@github.com>
References: <QiYoOJBVd4Foi_Ci9NAeUnRKGyWQXPVddmG26Hcf99U=.44dd836c-298f-41d5-8e37-0bcc9d2562da@github.com>
 <ERTWfHsShOvkZiWQ1Pq2Y3UiOCeRFbHeauIRXXCwwJA=.ddb183f4-f9d7-4ba2-b9cf-b726358e3805@github.com>
Message-ID: <sYKGRwQIyWfLT6oGN48e8PxMi27YKC-z9sOzPX4-QLs=.abda74d9-39c2-4741-8e04-3f734ebb6ed3@github.com>

On Thu, 26 Feb 2026 19:42:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> During review of Valhalla lworld vs mainline patch, I noticed Valhalla has a fix for a mainline issue where there is no getter validation for ObjectMethods.bootstrap. We should upstream this fix to mainline to make lworld cleaner and make mainline more robust.
>> 
>> Before this fix, the invalid getters caused weird exceptions in method handle construction. Now they consistently throw IllegalArgumentException as specified.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Name change as review recommended

Thanks for the reviews! This will facilitate Valhalla cleanups.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29941#issuecomment-3974245446

From liach at openjdk.org  Fri Feb 27 17:55:34 2026
From: liach at openjdk.org (Chen Liang)
Date: Fri, 27 Feb 2026 17:55:34 GMT
Subject: Integrated: 8378792: ObjectMethods.bootstrap missing getter validation
In-Reply-To: <QiYoOJBVd4Foi_Ci9NAeUnRKGyWQXPVddmG26Hcf99U=.44dd836c-298f-41d5-8e37-0bcc9d2562da@github.com>
References: <QiYoOJBVd4Foi_Ci9NAeUnRKGyWQXPVddmG26Hcf99U=.44dd836c-298f-41d5-8e37-0bcc9d2562da@github.com>
Message-ID: <uGaj43SGN6KfgYfpdKR1wCjT71fXABDLl248pZK9w1M=.e5fe96d0-0cce-4e74-bfc7-5e33aa8f8611@github.com>

On Thu, 26 Feb 2026 19:15:14 GMT, Chen Liang <liach at openjdk.org> wrote:

> During review of Valhalla lworld vs mainline patch, I noticed Valhalla has a fix for a mainline issue where there is no getter validation for ObjectMethods.bootstrap. We should upstream this fix to mainline to make lworld cleaner and make mainline more robust.
> 
> Before this fix, the invalid getters caused weird exceptions in method handle construction. Now they consistently throw IllegalArgumentException as specified.

This pull request has now been integrated.

Changeset: 1fb608e1
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1fb608e1bcbbc3fd68205ea168f10584cc5c2a62
Stats:     71 lines in 2 files changed: 46 ins; 4 del; 21 mod

8378792: ObjectMethods.bootstrap missing getter validation

Reviewed-by: rriggs, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/29941

From cjplummer at openjdk.org  Fri Feb 27 18:05:47 2026
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 27 Feb 2026 18:05:47 GMT
Subject: RFR: 8378854: Disable SA tests when ZGC is being used
Message-ID: <V0rd_Rw85eLG32YmMr7cJvbiM-Hb6bfjAQzaW512Gk0=.59c696e0-77a7-4300-8a0d-83c2235f6dc8@github.com>

We currently problem list all the SA tests when ZGC is being used. However, recently the CR they are problem listed under ([JDK-8307393](https://bugs.openjdk.org/browse/JDK-8307393)) was closed as WNF. Tests are not suppose to be problem listed under closed CRs. The proposed solution is to use the following in all the SA tests:

`?? * @requires vm.gc != "Z"`

Note I kept `serviceability/sa/TestUniverse.java` enabled for ZGC as it was explicitly called out in the problem list comment as a sanity check to keep enabled.

While adding the `@requires` I also did some minor cleanup in a few places to keep the `@requires` less cluttered and consistent between tests. Specifically I made it so `@requires vm.hasSA` is always on its own line and always first.

Testing in progress. Will cover all tier1 plus tier2, tier3, and tier5 svc testing.

-------------

Commit messages:
 - disable SA tests when using ZGC
 - disable SA tests when using ZGC

Changes: https://git.openjdk.org/jdk/pull/29959/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29959&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378854
  Stats: 260 lines in 77 files changed: 94 ins; 91 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/29959.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29959/head:pull/29959

PR: https://git.openjdk.org/jdk/pull/29959

From simonis at openjdk.org  Fri Feb 27 18:32:22 2026
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 27 Feb 2026 18:32:22 GMT
Subject: RFR: 8377907: (process) Race in ProcessBuilder can cause JVM hangs
In-Reply-To: <JPOHltHN-kr96XXbnfTXmhgFNNpqcPBi7nbAQ0Ng08c=.4f2a2a3d-0b00-4c76-890f-ea9903607dc2@github.com>
References: <JPOHltHN-kr96XXbnfTXmhgFNNpqcPBi7nbAQ0Ng08c=.4f2a2a3d-0b00-4c76-890f-ea9903607dc2@github.com>
Message-ID: <PFoU7RGLCUmRq1WTLCLy50eCKA2_uZ86DEr3179Y9ZQ=.a2a5cd61-72ec-466d-9836-55253db959d6@github.com>

On Thu, 26 Feb 2026 15:16:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> When starting child processes from Java, we bootstrap the child process after fork and before exec. As part of that process, up to five pipes are handed to the child: three for stdin/out/err, respectively, and two internal communication pipes (fail and childenv).
> 
> If, concurrently with our invocation of `ProcessBuilder.start()`, third-party native code forks a child of its own, the natively forked child carries copies of these pipes. It then may keep these pipes open. This results in various forms of communication errors, most likely hangs - either in `ProcessBuilder.start()`, or in customer code. 
> 
> In the customer case that started this investigation, `ProcessBuilder.start()` hung intermittently when using a third-party Eclipse library that happened to perform forks natively.
> 
> The JVM has no full control over what happens in its process, since we allow native code to run. Therefore, native forks can happen, and we have to work around them. 
> 
> The fix makes sure that the pipes we use in ProcessBuilder are always tagged with CLOEXEC. Since forks are typically followed by execs, this will close any file descriptors that were accidentally inherited.
> 
> ### FORK/VFORK mode
> 
> Here, it is sufficient to open all our pipes with O_CLOEXEC.
> 
> The caveat here is that only Linux offers an API to do that cleanly: `pipe2(2)` ([1]). On MacOS and AIX, we don't have `pipe2(2)`, so we need to emulate that behavior using `pipe(2)` and `fcntl(2)` in quick succession. That is still racy, since we did not completely close the time window within which pipe file descriptors are not O_CLOEXEC. But this is the best we can do.
> 
> ### POSIX_SPAWN mode
> 
> Creating the pipes with CLOEXEC alone is not sufficient. With `posix_spawn(3)`, we exec twice: first to load the jspawnhelper (inside `posix_spawn(3)`), a second time to load the target binary. Pipes created with O_CLOEXEC would not survive the first exec.
> 
> Therefore, instead of manually `dup2(2)`'ing our file descriptors after the first exec in jspawnhelper itself, we set up dup2 file actions to let posix_spawn do the dup'ing. According to POSIX, these dup2 file actions will be processed before the kernel closes the inherited CLOEXEC file descriptors.
> 
> Unfortunately, macOS is again not POSIX-compliant, since the macOS kernel can close CLOEXEC file descriptors before posix_spawn processes them in its dup2 file actions. As a workaround for that bug, we create temporary copies of the pipe file descriptors that are untagged with CLOEXEC and use ...

Hi Thomas,

Thanks a lot for finding this issue, describing it in all details and creating regression tests for it.

>From a first glance the changes look OK but I'll have to take a closer look next week.

I am just a little concerned about the ever increasing code complexity in this area. Have you thought about using Unix domain sockets with `socketpair()` instead of pipes for the parent/child communication? That might be simpler and more portable, although I haven't really tried it out yet.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29939#issuecomment-3974413937

From sherman at openjdk.org  Fri Feb 27 18:44:21 2026
From: sherman at openjdk.org (Xueming Shen)
Date: Fri, 27 Feb 2026 18:44:21 GMT
Subject: RFR: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to
 intrinsify [v4]
In-Reply-To: <3Cj-8Ae4bGQs6soTjbPTNeOK1p6owLuGAVk72PySAZk=.a1527cf4-bf4d-4e02-89aa-81a578ca2dbb@github.com>
References: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
 <3Cj-8Ae4bGQs6soTjbPTNeOK1p6owLuGAVk72PySAZk=.a1527cf4-bf4d-4e02-89aa-81a578ca2dbb@github.com>
Message-ID: <Bss6rFC8u_e68pj-NoNlClMcXjhqNkYabd3p3VQvf5A=.cf8deaa3-553b-4ffa-b1e0-04630da72f15@github.com>

On Wed, 25 Feb 2026 11:05:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I ran following code with `-Djdk.incubator.vector.DEBUG=true`, however it was not intrinsified.
>> 
>> 
>>   public static void cos(){
>>     var rand = new Random();
>>     for(int i = 0; i < 1_000_000; i++){
>>       var vec = DoubleVector.fromArray(DoubleVector.SPECIES_256, rand.doubles().limit(4).toArray(), 0);
>> 
>>       vec.lanewise(VectorOperators.COS);
>>     }
>>   }
>> 
>> 
>> I knew `__jsvml_cos4_ha_l9()` in libjsvml.so should be called in this case (via vector debug log), but it was not hitted even though I set breakpoint in it.
>> 
>> `LaneType` has been introduced in [JDK-8376187](https://bugs.openjdk.org/browse/JDK-8376187), and `LibraryCallKit::inline_vector_call()` was updated to handle lane type rather than class of element type. However `VectorMathLibrary` wasn't modified.
>> 
>> I confirmed `__jsvml_cos4_ha_l9()` is called with this fix, and also all jdk/jdk/incubator/vector jtreg tests passed on Linux AMD64.
>
> Yasumasa Suenaga has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unnecesary file
>  - Update testcase
>  - Add comment

Marked as reviewed by sherman (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29835#pullrequestreview-3868467460

From naoto at openjdk.org  Fri Feb 27 18:48:21 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 27 Feb 2026 18:48:21 GMT
Subject: RFR: 8375045: Incorrect Interpretation of POSIX TZ Environment
 Variable on AIX.
In-Reply-To: <D2kIcRxdi48MWoH0UOgtJ0UWs7tUCsTgiOomjDlaDFk=.0fae9b13-6acd-42cb-9d39-7559f4cf1567@github.com>
References: <D2kIcRxdi48MWoH0UOgtJ0UWs7tUCsTgiOomjDlaDFk=.0fae9b13-6acd-42cb-9d39-7559f4cf1567@github.com>
Message-ID: <Asmybz_T3HJeBWPI3KqxjBgxJT7sKTKzsLwl5iqn43g=.452085bf-9213-4169-ae55-4ada5cb247dd@github.com>

On Tue, 13 Jan 2026 06:26:02 GMT, Sruthy Jayan <duke at openjdk.org> wrote:

> Bug Reference : https://bugs.openjdk.org/browse/JDK-8375045
> 
> On AIX, the POSIX TZ environment variable is not interpreted as expected when it includes DST rules.
> Example: `TZ=CET-1CEST,M3.5.0,M10.5.0`
> 
> The fix includes : 
> The TZ environment variable is processed by first matching the full value against tzmappings, then retrying with the value truncated at the first comma if no match is found, and finally defaulting to GMT if no mapping exists.
> 
> This fixes the regression caused by https://bugs.openjdk.org/browse/JDK-8292899
> 
> Signed-off-by: Sruthy Jayan <srutjay1 at in.ibm.com>

I don't have any knowledge on AIX's TZ mappings, so I just left generic comments.

src/java.base/unix/native/libjava/TimeZone_md.c line 355:

> 353: 
> 354: static char *
> 355: mapTimezoneToJava(const char *tz_buf, size_t tz_len, const char *mapfilename) {

This function name is kind of vague as to what it actually does. More specific name would be preferred.

src/java.base/unix/native/libjava/TimeZone_md.c line 451:

> 449:         temp_tz = strchr(tz, ',');
> 450:         tz_len = (temp_tz == NULL) ? strlen(tz) : temp_tz - tz;
> 451:         tz_buf = (char *)malloc(tz_len + 1);

Is this malloc needed?  Is `tz_buf` already allocated by the above `strdup` with full length? If for some reason it needs to reallocate a new buffer, previously allocated buffer needs to be freed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/29183#pullrequestreview-3868469696
PR Review Comment: https://git.openjdk.org/jdk/pull/29183#discussion_r2865687106
PR Review Comment: https://git.openjdk.org/jdk/pull/29183#discussion_r2865692828

From lancea at openjdk.org  Fri Feb 27 18:51:30 2026
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 27 Feb 2026 18:51:30 GMT
Subject: RFR: 8378111: Migrate java/util/jar tests to JUnit [v3]
In-Reply-To: <byA5m9O6m0xMz0JVHfA6coX5fePS0EbZNHTeSfnx7kE=.dfdbe356-474c-45f4-8d2c-ac2c2cce8cfc@github.com>
References: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
 <byA5m9O6m0xMz0JVHfA6coX5fePS0EbZNHTeSfnx7kE=.dfdbe356-474c-45f4-8d2c-ac2c2cce8cfc@github.com>
Message-ID: <E-jL_upP9ONw3pUz55nHbBJpdt2kqUOM9hIl3PasMrg=.36b42f2f-fc3b-44ee-9557-e03a989acf72@github.com>

On Mon, 23 Feb 2026 22:56:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR migrates the java/util/jar tests to use _JUnit_.
>> 
>> https://github.com/openjdk/jdk/commit/afe0aeee746bccbbe4bc6c9a8cd2302228ecc2f6 includes changes for _testNG_ based tests.
>> https://github.com/openjdk/jdk/commit/c5a7f75840f96fa77ec3ed7faa713990adb84de6 includes changes for `main` based tests.
>> 
>> Before: Framework-based tests: 125 = 125 TestNG + 0 JUnit.
>> After: Framework-based tests: 174 = 0 TestNG + 174 JUnit
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get rid of inheritance + zip -> ZIP

Hi Justin,

I think you are pretty close.  Thank you for your efforts here.

A couple of minor suggestions on a pass through today

test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarSecurity.java line 57:

> 55:     static final String userdir = System.getProperty("user.dir", ".");
> 56:     static final File multirelease = new File(userdir, "multi-release.jar");
> 57:     static final File signedmultirelease = new File(userdir, "signed-multi-release.jar");

minor given these are now final, perhaps capitalize them?

test/jdk/java/util/jar/TestJarExtra.java line 77:

> 75:     @Test
> 76:     void jarExtraHeaderOnlyTest() throws IOException {
> 77:         testHeaderOnly();

Any reason not to  collapse testHeaderOnly into this test method vs calling it as I did not see it called twice unless I missed it

test/jdk/java/util/jar/TestJarExtra.java line 117:

> 115: 
> 116:         jos.close();
> 117: 

perhaps clean up the blank lines here if you make another pass through

-------------

PR Review: https://git.openjdk.org/jdk/pull/29828#pullrequestreview-3868448781
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2865668533
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2865703740
PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2865689939

From jlu at openjdk.org  Fri Feb 27 19:52:03 2026
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 27 Feb 2026 19:52:03 GMT
Subject: RFR: 8378111: Migrate java/util/jar tests to JUnit [v4]
In-Reply-To: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
References: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
Message-ID: <uFjvlQpUx8I81bY5Iogv9_hGP_0CD3i6FcUGjChVls0=.a3ff0c8c-87d3-4674-87fd-4d65ad8d5151@github.com>

> This PR migrates the java/util/jar tests to use _JUnit_.
> 
> https://github.com/openjdk/jdk/commit/afe0aeee746bccbbe4bc6c9a8cd2302228ecc2f6 includes changes for _testNG_ based tests.
> https://github.com/openjdk/jdk/commit/c5a7f75840f96fa77ec3ed7faa713990adb84de6 includes changes for `main` based tests.
> 
> Before: Framework-based tests: 125 = 125 TestNG + 0 JUnit.
> After: Framework-based tests: 174 = 0 TestNG + 174 JUnit

Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'master' into junit-java-util-jar
 - Reflect Lance's comments
 - get rid of inheritance + zip -> ZIP
 - Eirik comments
 - Naoto comment
 - Andrey comments
 - main -> JUnit
 - TestNG -> JUnit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29828/files
  - new: https://git.openjdk.org/jdk/pull/29828/files/5bd6c18e..2f8790f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29828&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29828&range=02-03

  Stats: 105399 lines in 936 files changed: 46992 ins; 39117 del; 19290 mod
  Patch: https://git.openjdk.org/jdk/pull/29828.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29828/head:pull/29828

PR: https://git.openjdk.org/jdk/pull/29828

From jlu at openjdk.org  Fri Feb 27 19:52:04 2026
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 27 Feb 2026 19:52:04 GMT
Subject: RFR: 8378111: Migrate java/util/jar tests to JUnit [v3]
In-Reply-To: <E-jL_upP9ONw3pUz55nHbBJpdt2kqUOM9hIl3PasMrg=.36b42f2f-fc3b-44ee-9557-e03a989acf72@github.com>
References: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
 <byA5m9O6m0xMz0JVHfA6coX5fePS0EbZNHTeSfnx7kE=.dfdbe356-474c-45f4-8d2c-ac2c2cce8cfc@github.com>
 <E-jL_upP9ONw3pUz55nHbBJpdt2kqUOM9hIl3PasMrg=.36b42f2f-fc3b-44ee-9557-e03a989acf72@github.com>
Message-ID: <3v-Tvkwze0oTULm2tOpCEOJ02jeefKza5bCnB_BRLwA=.c588ca4e-a75d-4615-8dfc-d685513ca252@github.com>

On Fri, 27 Feb 2026 18:47:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   get rid of inheritance + zip -> ZIP
>
> test/jdk/java/util/jar/TestJarExtra.java line 77:
> 
>> 75:     @Test
>> 76:     void jarExtraHeaderOnlyTest() throws IOException {
>> 77:         testHeaderOnly();
> 
> Any reason not to  collapse testHeaderOnly into this test method vs calling it as I did not see it called twice unless I missed it

Thanks for reviewing Lance. The extra test methods were remnants from the testing structure in previous commits, the indirection can be removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29828#discussion_r2865929115

From lancea at openjdk.org  Fri Feb 27 20:02:23 2026
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 27 Feb 2026 20:02:23 GMT
Subject: RFR: 8378111: Migrate java/util/jar tests to JUnit [v4]
In-Reply-To: <uFjvlQpUx8I81bY5Iogv9_hGP_0CD3i6FcUGjChVls0=.a3ff0c8c-87d3-4674-87fd-4d65ad8d5151@github.com>
References: <2oGWtrqSGEqgFnGglM2Oo-iQXtTrkByIN_6KOhRRQdM=.883493d9-147a-43dd-8465-834a31667aaa@github.com>
 <uFjvlQpUx8I81bY5Iogv9_hGP_0CD3i6FcUGjChVls0=.a3ff0c8c-87d3-4674-87fd-4d65ad8d5151@github.com>
Message-ID: <1_y9IGW5ZKElel8bfEYpLGrj-66aIzgF52oQKAzJcB0=.2a8a2b55-210b-4b99-b1d6-339a6d3ababf@github.com>

On Fri, 27 Feb 2026 19:52:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR migrates the java/util/jar tests to use _JUnit_.
>> 
>> https://github.com/openjdk/jdk/commit/afe0aeee746bccbbe4bc6c9a8cd2302228ecc2f6 includes changes for _testNG_ based tests.
>> https://github.com/openjdk/jdk/commit/c5a7f75840f96fa77ec3ed7faa713990adb84de6 includes changes for `main` based tests.
>> 
>> Before: Framework-based tests: 125 = 125 TestNG + 0 JUnit.
>> After: Framework-based tests: 174 = 0 TestNG + 174 JUnit
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into junit-java-util-jar
>  - Reflect Lance's comments
>  - get rid of inheritance + zip -> ZIP
>  - Eirik comments
>  - Naoto comment
>  - Andrey comments
>  - main -> JUnit
>  - TestNG -> JUnit

thanks for the quick turnaround Justin

I think you should be good to go assuming no issues in Mach5 across the various systems

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29828#pullrequestreview-3868810729

From asemenyuk at openjdk.org  Fri Feb 27 20:13:19 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 27 Feb 2026 20:13:19 GMT
Subject: RFR: 8378798: Test
 tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControlTest.java
 failed: missing IOException
In-Reply-To: <kgCgAoaHNLg1FOMYfSeW-cfkvDvUCL20_aJ6xVMsiOI=.9450a3d5-6332-4bbc-8af5-13c1d0617236@github.com>
References: <kgCgAoaHNLg1FOMYfSeW-cfkvDvUCL20_aJ6xVMsiOI=.9450a3d5-6332-4bbc-8af5-13c1d0617236@github.com>
Message-ID: <RhZhH81wSudG0Ci1uyy-RwBLqZ7AZfNjyfMjgwAFI_E=.20ad2463-73e3-4ae1-8595-9589964c908e@github.com>

On Fri, 27 Feb 2026 20:05:37 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Disable a unit test on Linux: it expects an error condition that is not reliably reproducible.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29960#issuecomment-3974853682

From asemenyuk at openjdk.org  Fri Feb 27 20:13:18 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 27 Feb 2026 20:13:18 GMT
Subject: RFR: 8378798: Test
 tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControlTest.java
 failed: missing IOException
Message-ID: <kgCgAoaHNLg1FOMYfSeW-cfkvDvUCL20_aJ6xVMsiOI=.9450a3d5-6332-4bbc-8af5-13c1d0617236@github.com>

Disable a unit test on Linux: it expects an error condition that is not reliably reproducible.

-------------

Commit messages:
 - CommandOutputControlTest: disable "test_close_streams" test on Linux

Changes: https://git.openjdk.org/jdk/pull/29960/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29960&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378798
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29960.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29960/head:pull/29960

PR: https://git.openjdk.org/jdk/pull/29960

From asemenyuk at openjdk.org  Fri Feb 27 21:11:50 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 27 Feb 2026 21:11:50 GMT
Subject: RFR: 8378867: jpackage references non-existing
 "message.app-image-requires-identifier" l10n key
Message-ID: <GPlYuQlUgLAHsgtl1vs070BHw8MYpKfCiz2IYJJ1j8w=.d6b2c4b0-104a-42f5-9095-2405a6353da5@github.com>

Fix missing l10n key. Add a test to cover the fix.

-------------

Commit messages:
 - MacApplicationBuilder: fix missing "message.app-image-requires-identifier" key

Changes: https://git.openjdk.org/jdk/pull/29905/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29905&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378867
  Stats: 40 lines in 4 files changed: 34 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/29905.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29905/head:pull/29905

PR: https://git.openjdk.org/jdk/pull/29905

From asemenyuk at openjdk.org  Fri Feb 27 21:11:57 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 27 Feb 2026 21:11:57 GMT
Subject: RFR: 8378873: jpackage: remove macOS-specific code from
 jdk.jpackage.internal.ModuleInfo
Message-ID: <cZTbL6QTTzn6e0eN9GErWdvuY2LGTccUqnu1Slg9NtM=.61575538-0679-49ad-8db4-5d02fe7f27b2@github.com>

$subj. Move macOS-specific logic to MacFromOptions class.

-------------

Commit messages:
 - Pass the path to the directory with the standard Java runtime structure into LauncherStartupInfoBuilder#predefinedRuntimeImage()

Changes: https://git.openjdk.org/jdk/pull/29963/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29963&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378873
  Stats: 30 lines in 2 files changed: 16 ins; 11 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/29963.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29963/head:pull/29963

PR: https://git.openjdk.org/jdk/pull/29963

From asemenyuk at openjdk.org  Fri Feb 27 21:37:39 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 27 Feb 2026 21:37:39 GMT
Subject: RFR: 8378874: jpackage: remove redundant messages
Message-ID: <xK1i8GqsaVwOLnbRmQkp97_J5biyfh-CRqzCvq98ghc=.451f4b7e-1bc7-438c-9a20-00b54b18605f@github.com>

On macOS, remove

message.signing.pkg=Warning: For signing PKG, you might need to set "Always Trust" for your certificate using "Keychain Access" tool.

This warning is redundant, as the user should have this type of configuration when using jpackage for any signing.

On Windows, remove

message.use-wix36-features=WiX {0} detected. Enabling advanced cleanup action.

This notification is redundant: The oldest officially available version of WiX is 3.11.

-------------

Commit messages:
 - Update copyright year
 - Remove "message.signing.pkg" warning
 - Remove redundant "message.use-wix36-features" info message

Changes: https://git.openjdk.org/jdk/pull/29907/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29907&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378874
  Stats: 31 lines in 6 files changed: 1 ins; 28 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/29907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29907/head:pull/29907

PR: https://git.openjdk.org/jdk/pull/29907

From asemenyuk at openjdk.org  Fri Feb 27 21:37:40 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 27 Feb 2026 21:37:40 GMT
Subject: RFR: 8378874: jpackage: remove redundant messages
In-Reply-To: <xK1i8GqsaVwOLnbRmQkp97_J5biyfh-CRqzCvq98ghc=.451f4b7e-1bc7-438c-9a20-00b54b18605f@github.com>
References: <xK1i8GqsaVwOLnbRmQkp97_J5biyfh-CRqzCvq98ghc=.451f4b7e-1bc7-438c-9a20-00b54b18605f@github.com>
Message-ID: <6PptY8oo5czeFUlrXnvddEpM4mU_m_-f1i-u6LSGOhg=.09d4f1e2-90ff-4a2f-8fe2-bad560029de2@github.com>

On Wed, 25 Feb 2026 02:11:51 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> On macOS, remove
> 
> message.signing.pkg=Warning: For signing PKG, you might need to set "Always Trust" for your certificate using "Keychain Access" tool.
> 
> This warning is redundant, as the user should have this type of configuration when using jpackage for any signing.
> 
> On Windows, remove
> 
> message.use-wix36-features=WiX {0} detected. Enabling advanced cleanup action.
> 
> This notification is redundant: The oldest officially available version of WiX is 3.11.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29907#issuecomment-3975186260

From lancea at openjdk.org  Fri Feb 27 21:43:45 2026
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 27 Feb 2026 21:43:45 GMT
Subject: RFR: 8377992: (zipfs) Align ZipFileSystem END header validation
 with the ZipFile implementation [v3]
In-Reply-To: <6-UkqPxno7fpp6z_oO9l81t85YxdpsjkL0nr-_qlx0A=.46fd285e-5be7-49e7-a068-f0c4bd536a36@github.com>
References: <1tONCY1QoXxaeUtr3LE4YoZk0UitQ5NqadNJOPFjREQ=.9b237170-fb07-4713-82fb-26b968b268de@github.com>
 <6-UkqPxno7fpp6z_oO9l81t85YxdpsjkL0nr-_qlx0A=.46fd285e-5be7-49e7-a068-f0c4bd536a36@github.com>
Message-ID: <Qr9-aIoiI9RJra1OXpkuZ5ORCDvcDd310UXp7ra27Do=.7d9806e5-8422-46d0-926f-1d8cc07e2765@github.com>

On Fri, 20 Feb 2026 18:28:54 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`.
>> 
>> This brings two validation checks over to `ZipFileSystem`:
>> 
>> * Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746)
>> * Rejection of END headers with a total entry count which cannot fit within the CEN byte array  (JDK-8341625)
>> 
>> Test vector setup in `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is extracted to a new test lib utility class `jdk.test.lib.util.ZipUtils`. `EndOfCenValidation` is then copied to `test/jdk/jdk/nio/zipfs` and adjusted to test `ZipFileSystem` instead of `ZipFile`.
>> 
>> Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries.  Similar adjustments to `ZipFile` was done in JDK-8341625.
>> 
>> `ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dial down on blank lines as vertical space

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29747#pullrequestreview-3869202563

From jlu at openjdk.org  Fri Feb 27 22:07:00 2026
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 27 Feb 2026 22:07:00 GMT
Subject: RFR: 8378723: Locale variant delimiter is unclear
Message-ID: <Wvn8yYuNu5aNOuZ-dm68d864vMfrWKVpBZyUAjrHsPE=.0fce5bd4-e020-45b2-a996-c637b462f99d@github.com>

Locale APIs which accept BCP 47 tags use hyphen for multiple variant subtags. Locale APIs that accept multiple (non BCP 47 subtag) variants use underscores. For example,

`Locale.of` supports multiple variants separated by underscore.
`Locale.forLanguageTag` supports multiple variants separated by hyphen.
`Locale.Builder.setLanguageTag` supports multiple variants separated by hyphen.
`Locale.Builder.setVariant` supports multiple variants separated by either underscore or hyphen. 

The current wording is not detailed enough and implies both formats are interchangeable within `Locale`. This PR updates the wording to make this more apparent. Note that I left the constructor behavior out in the new wording as to not call attention to it.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/29970/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29970&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378723
  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/29970.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29970/head:pull/29970

PR: https://git.openjdk.org/jdk/pull/29970

From duke at openjdk.org  Fri Feb 27 22:10:29 2026
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Fri, 27 Feb 2026 22:10:29 GMT
Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v6]
In-Reply-To: <BURJJZdzfkOLMmZI4fBOh4O2moVznvQkVt3H2KLfOmQ=.3e737cfe-e72e-4523-9d1d-269589b3bd67@github.com>
References: <JOYhlJQ-Gk8MeV6TpLv46ScWxfs1MWvLqNMRtfPC0DY=.edc60cbf-5c16-44e7-b913-68619cbca4bd@github.com>
 <7HNoIEEFVQ124VGD57eXmGgEEL7xNixKYtHRGyPAFPU=.a83912db-8b0c-4901-9e9b-dffaad3ceab1@github.com>
 <BURJJZdzfkOLMmZI4fBOh4O2moVznvQkVt3H2KLfOmQ=.3e737cfe-e72e-4523-9d1d-269589b3bd67@github.com>
Message-ID: <lljqzAbEHbpoauxCtQXxGVFff7wuRMLXOt59vhc7y8U=.3b64db08-548e-40e7-b1da-0733c937a532@github.com>

On Wed, 25 Feb 2026 22:26:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vladimir Yaroslavskiy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8266431: Dual-Pivot Quicksort improvements
>>   
>>   * Resolved IDE warnings
>>   * Set next year 2026
>
> src/java.base/share/classes/java/util/gen-DualPivotQuicksort.sh line 1:
> 
>> 1: #!/bin/bash
> 
> Consider moving this to a make file in make/modules/java.base/gensrc; there are a few other scripts in that directory.

@liach Thank you, I will move src/java.base/share/classes/java/util/gen-DualPivotQuicksort.sh out to the script directory.

And what about test/jdk/java/util/Arrays/gen-Sorting.sh? Move also?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27411#discussion_r2866414230

From asemenyuk at openjdk.org  Fri Feb 27 22:17:18 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 27 Feb 2026 22:17:18 GMT
Subject: RFR: 8378867: jpackage references non-existing
 "message.app-image-requires-identifier" l10n key
In-Reply-To: <GPlYuQlUgLAHsgtl1vs070BHw8MYpKfCiz2IYJJ1j8w=.d6b2c4b0-104a-42f5-9095-2405a6353da5@github.com>
References: <GPlYuQlUgLAHsgtl1vs070BHw8MYpKfCiz2IYJJ1j8w=.d6b2c4b0-104a-42f5-9095-2405a6353da5@github.com>
Message-ID: <0OCEdIePde9XtyqQzRH7QnHhZkfydkSixCDO3s1AUiQ=.6174138d-7f2e-4ef8-a48d-59b26761fc51@github.com>

On Wed, 25 Feb 2026 02:03:57 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix missing l10n key. Add a test to cover the fix.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29905#issuecomment-3975395181

From asemenyuk at openjdk.org  Fri Feb 27 22:23:46 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 27 Feb 2026 22:23:46 GMT
Subject: RFR: 8378876: jpackage: facilitate testing with mocks
Message-ID: <5CRPhhLQ7DWl6ohh_RPrn5cRow0CcodfuWRprgBLXdM=.91aa1d93-ab77-43aa-82d2-62775cc9025e@github.com>

- Decouple jpackage implementation and test helpers from the current OS: replace OperatingSystem.current() calls with parameters and/or fields of type jdk.internal.util.OperatingSystem where feasible.
 - Support running jpackage without making it run actual packaging. jpackage will exit after it parses the command line, validates the options, and builds a model.

-------------

Commit messages:
 - Update copyright year
 - MacDmgSystemEnvironment: support mock testing
 - ToolValidator: remove adding "--version" option by default on Linux platform as it interferes with mock testing
 - PackageBuilder: don't assume install directory of a non-standard package should be absolute
 - TKit: support switching the current OS.
 - unbind from the OperatingSystem.current()
 - StandardOption: add "EXIT_AFTER_CONFIGURATION_PHASE" internal debug option. If in the list of options, jpackage will exit after configuration phase is over and will not run packaging pipeline.

Changes: https://git.openjdk.org/jdk/pull/29908/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29908&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378876
  Stats: 179 lines in 22 files changed: 97 ins; 28 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/29908.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29908/head:pull/29908

PR: https://git.openjdk.org/jdk/pull/29908

From asemenyuk at openjdk.org  Fri Feb 27 22:23:46 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 27 Feb 2026 22:23:46 GMT
Subject: RFR: 8378876: jpackage: facilitate testing with mocks
In-Reply-To: <5CRPhhLQ7DWl6ohh_RPrn5cRow0CcodfuWRprgBLXdM=.91aa1d93-ab77-43aa-82d2-62775cc9025e@github.com>
References: <5CRPhhLQ7DWl6ohh_RPrn5cRow0CcodfuWRprgBLXdM=.91aa1d93-ab77-43aa-82d2-62775cc9025e@github.com>
Message-ID: <hUsXRBnGHXVj48onS5OMiA_5UE_TjHohOYUHKpSVN6o=.fa49d964-46bd-4d2c-9a6b-5224a73ae1d9@github.com>

On Wed, 25 Feb 2026 02:14:33 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Decouple jpackage implementation and test helpers from the current OS: replace OperatingSystem.current() calls with parameters and/or fields of type jdk.internal.util.OperatingSystem where feasible.
>  - Support running jpackage without making it run actual packaging. jpackage will exit after it parses the command line, validates the options, and builds a model.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29908#issuecomment-3975424941

From asemenyuk at openjdk.org  Fri Feb 27 22:42:33 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 27 Feb 2026 22:42:33 GMT
Subject: RFR: 8378877: jpackage: improve rebranding of exe files on Windows
Message-ID: <0GDVhtn8I4mZudWbRwuyPC9ahYH8KWc2PmED1Uworm8=.a3d83a37-d52c-4a53-8440-752518380787@github.com>

Change how jpackage embeds icons, version and other properties in .exe files.
Don't print

Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory <TMPDIR>.


warning. Instead, run the operation with retries.

Additionally, throw JPackageException instead of RuntimeException to report errors; fail if invalid data is passed in the ctor instead of logging and ignoring it.

-------------

Commit messages:
 - ExecutableRebrander: replace the warning about Windows defender with running the rebrander with retries
 - ExecutableRebrander: throw JPackageException instead of RuntimeException to report errors; fail if invalid data is passed in ctor instead of logging and ignoring it

Changes: https://git.openjdk.org/jdk/pull/29906/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29906&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378877
  Stats: 293 lines in 4 files changed: 37 ins; 208 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/29906.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29906/head:pull/29906

PR: https://git.openjdk.org/jdk/pull/29906

From asemenyuk at openjdk.org  Fri Feb 27 22:42:34 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 27 Feb 2026 22:42:34 GMT
Subject: RFR: 8378877: jpackage: improve rebranding of exe files on Windows
In-Reply-To: <0GDVhtn8I4mZudWbRwuyPC9ahYH8KWc2PmED1Uworm8=.a3d83a37-d52c-4a53-8440-752518380787@github.com>
References: <0GDVhtn8I4mZudWbRwuyPC9ahYH8KWc2PmED1Uworm8=.a3d83a37-d52c-4a53-8440-752518380787@github.com>
Message-ID: <C4WeC8b44mp9QE5LekaYwKpra45iVwfS-9OKvW-NHQ4=.efbaf4d5-3f7f-4880-bcef-97de5ea6b7e1@github.com>

On Wed, 25 Feb 2026 02:09:13 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Change how jpackage embeds icons, version and other properties in .exe files.
> Don't print
> 
> Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory <TMPDIR>.
> 
> 
> warning. Instead, run the operation with retries.
> 
> Additionally, throw JPackageException instead of RuntimeException to report errors; fail if invalid data is passed in the ctor instead of logging and ignoring it.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29906#issuecomment-3975563674

From asemenyuk at openjdk.org  Fri Feb 27 22:43:19 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 27 Feb 2026 22:43:19 GMT
Subject: RFR: 8378873: jpackage: remove macOS-specific code from
 jdk.jpackage.internal.ModuleInfo
In-Reply-To: <cZTbL6QTTzn6e0eN9GErWdvuY2LGTccUqnu1Slg9NtM=.61575538-0679-49ad-8db4-5d02fe7f27b2@github.com>
References: <cZTbL6QTTzn6e0eN9GErWdvuY2LGTccUqnu1Slg9NtM=.61575538-0679-49ad-8db4-5d02fe7f27b2@github.com>
Message-ID: <oAoTuSPS1r-Wrk5-6iSJpwbLbDCqx_SbATqn6cFZRTI=.b33d3c19-b882-44ca-9983-69ab5a9157d4@github.com>

On Fri, 27 Feb 2026 20:41:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> $subj. Move macOS-specific logic to MacFromOptions class.

@sashamatveev PTAL

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29963#issuecomment-3975568389

From naoto at openjdk.org  Fri Feb 27 22:49:18 2026
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 27 Feb 2026 22:49:18 GMT
Subject: RFR: 8378723: Locale variant delimiter is unclear
In-Reply-To: <Wvn8yYuNu5aNOuZ-dm68d864vMfrWKVpBZyUAjrHsPE=.0fce5bd4-e020-45b2-a996-c637b462f99d@github.com>
References: <Wvn8yYuNu5aNOuZ-dm68d864vMfrWKVpBZyUAjrHsPE=.0fce5bd4-e020-45b2-a996-c637b462f99d@github.com>
Message-ID: <JIOSEeNqdfpeTqaUt0m7FQ-rWZei7h8yp2paMrXJgTc=.83bee05d-888c-4135-830e-7ba7de2dd44c@github.com>

On Fri, 27 Feb 2026 21:58:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Locale APIs which accept BCP 47 tags use hyphen for multiple variant subtags. Locale APIs that accept multiple (non BCP 47 subtag) variants use underscores. For example,
> 
> `Locale.of` supports multiple variants separated by underscore.
> `Locale.forLanguageTag` supports multiple variants separated by hyphen.
> `Locale.Builder.setLanguageTag` supports multiple variants separated by hyphen.
> `Locale.Builder.setVariant` supports multiple variants separated by either underscore or hyphen. 
> 
> The current wording is not detailed enough and implies both formats are interchangeable within `Locale`. This PR updates the wording to make this more apparent. Note that I left the constructor behavior out in the new wording as to not call attention to it.

src/java.base/share/classes/java/util/Locale.java line 182:

> 180:  *   BCP 47 language tags expect as such. However, {@link Locale.Builder#setVariant(String)}
> 181:  *   also supports underscore ('_') and {@link Locale#of(String, String, String)}
> 182:  *   only supports underscore ('_').</dd>

I think this behavior is to accommodate the JDK's own variants prior to BCP47. So adding something like " for backward compatibility" would be helpful.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29970#discussion_r2866530377

From jlu at openjdk.org  Fri Feb 27 23:11:36 2026
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 27 Feb 2026 23:11:36 GMT
Subject: RFR: 8378723: Locale variant delimiter is unclear [v2]
In-Reply-To: <Wvn8yYuNu5aNOuZ-dm68d864vMfrWKVpBZyUAjrHsPE=.0fce5bd4-e020-45b2-a996-c637b462f99d@github.com>
References: <Wvn8yYuNu5aNOuZ-dm68d864vMfrWKVpBZyUAjrHsPE=.0fce5bd4-e020-45b2-a996-c637b462f99d@github.com>
Message-ID: <2AJAWtu0Kwe5r6Aa0Wc14yYhbNadpw4lhesGErrVDYs=.b192c1ac-44af-4c4b-972b-95e8ec53857e@github.com>

> Locale APIs which accept BCP 47 tags use hyphen for multiple variant subtags. Locale APIs that accept multiple (non BCP 47 subtag) variants use underscores. For example,
> 
> `Locale.of` supports multiple variants separated by underscore.
> `Locale.forLanguageTag` supports multiple variants separated by hyphen.
> `Locale.Builder.setLanguageTag` supports multiple variants separated by hyphen.
> `Locale.Builder.setVariant` supports multiple variants separated by either underscore or hyphen. 
> 
> The current wording is not detailed enough and implies both formats are interchangeable within `Locale`. This PR updates the wording to make this more apparent. Note that I left the constructor behavior out in the new wording as to not call attention to it.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Describe basis for underscore support

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29970/files
  - new: https://git.openjdk.org/jdk/pull/29970/files/bae0ef72..e161204b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29970&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29970&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/29970.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29970/head:pull/29970

PR: https://git.openjdk.org/jdk/pull/29970

From almatvee at openjdk.org  Fri Feb 27 23:13:21 2026
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 27 Feb 2026 23:13:21 GMT
Subject: RFR: 8378798: Test
 tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControlTest.java
 failed: missing IOException
In-Reply-To: <kgCgAoaHNLg1FOMYfSeW-cfkvDvUCL20_aJ6xVMsiOI=.9450a3d5-6332-4bbc-8af5-13c1d0617236@github.com>
References: <kgCgAoaHNLg1FOMYfSeW-cfkvDvUCL20_aJ6xVMsiOI=.9450a3d5-6332-4bbc-8af5-13c1d0617236@github.com>
Message-ID: <HhGqcd8GXTJoqXEOixTMZTll9CPWuuH9lRFKz0iyAEw=.b5b57307-8883-4014-af3a-6e9637e36117@github.com>

On Fri, 27 Feb 2026 20:05:37 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Disable a unit test on Linux: it expects an error condition that is not reliably reproducible.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29960#pullrequestreview-3869502801

From asemenyuk at openjdk.org  Fri Feb 27 23:16:28 2026
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 27 Feb 2026 23:16:28 GMT
Subject: Integrated: 8378798: Test
 tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControlTest.java
 failed: missing IOException
In-Reply-To: <kgCgAoaHNLg1FOMYfSeW-cfkvDvUCL20_aJ6xVMsiOI=.9450a3d5-6332-4bbc-8af5-13c1d0617236@github.com>
References: <kgCgAoaHNLg1FOMYfSeW-cfkvDvUCL20_aJ6xVMsiOI=.9450a3d5-6332-4bbc-8af5-13c1d0617236@github.com>
Message-ID: <-EMk5-gJUVpoB2zw4R8w01WIYKCikfWlxTBbcf3nxfc=.4805f925-bbf9-4ff0-99b6-62317694e0b6@github.com>

On Fri, 27 Feb 2026 20:05:37 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Disable a unit test on Linux: it expects an error condition that is not reliably reproducible.

This pull request has now been integrated.

Changeset: 58a7ccfc
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/58a7ccfca41bf06f6da98ff8b8d58c4ff0f16551
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8378798: Test tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControlTest.java failed: missing IOException

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/29960

From ysuenaga at openjdk.org  Sat Feb 28 00:07:15 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 28 Feb 2026 00:07:15 GMT
Subject: RFR: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to
 intrinsify [v5]
In-Reply-To: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
References: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
Message-ID: <NE_jmfiv59iwbaxM1anxnQX57pLZXpXpEBgnC5sX8b4=.bc418104-7250-4a32-bbb5-30ffc2f7844a@github.com>

> I ran following code with `-Djdk.incubator.vector.DEBUG=true`, however it was not intrinsified.
> 
> 
>   public static void cos(){
>     var rand = new Random();
>     for(int i = 0; i < 1_000_000; i++){
>       var vec = DoubleVector.fromArray(DoubleVector.SPECIES_256, rand.doubles().limit(4).toArray(), 0);
> 
>       vec.lanewise(VectorOperators.COS);
>     }
>   }
> 
> 
> I knew `__jsvml_cos4_ha_l9()` in libjsvml.so should be called in this case (via vector debug log), but it was not hitted even though I set breakpoint in it.
> 
> `LaneType` has been introduced in [JDK-8376187](https://bugs.openjdk.org/browse/JDK-8376187), and `LibraryCallKit::inline_vector_call()` was updated to handle lane type rather than class of element type. However `VectorMathLibrary` wasn't modified.
> 
> I confirmed `__jsvml_cos4_ha_l9()` is called with this fix, and also all jdk/jdk/incubator/vector jtreg tests passed on Linux AMD64.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Rename testcase

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29835/files
  - new: https://git.openjdk.org/jdk/pull/29835/files/f7a533bd..00233d65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29835&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29835&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/29835.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29835/head:pull/29835

PR: https://git.openjdk.org/jdk/pull/29835

From ysuenaga at openjdk.org  Sat Feb 28 00:07:18 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 28 Feb 2026 00:07:18 GMT
Subject: RFR: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to
 intrinsify [v4]
In-Reply-To: <tLZiMTGiuJeuw7vWUEXn3DrPm2xg2WLSqEMZjIwP8VQ=.bb27955c-2386-472b-9a9e-32dd671ab9ca@github.com>
References: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
 <3Cj-8Ae4bGQs6soTjbPTNeOK1p6owLuGAVk72PySAZk=.a1527cf4-bf4d-4e02-89aa-81a578ca2dbb@github.com>
 <tLZiMTGiuJeuw7vWUEXn3DrPm2xg2WLSqEMZjIwP8VQ=.bb27955c-2386-472b-9a9e-32dd671ab9ca@github.com>
Message-ID: <FHQO0QtzsIc9eSSgS13xd_FbHwKtxEuYr0HiC1OgCrk=.59a3c01d-1970-4271-8450-ec8f423b6afd@github.com>

On Fri, 27 Feb 2026 16:50:30 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove unnecesary file
>>  - Update testcase
>>  - Add comment
>
> test/hotspot/jtreg/compiler/vectorapi/TestVectorUnaryOpAndBinaryOp.java line 40:
> 
>> 38:  */
>> 39: 
>> 40: public class TestVectorUnaryOpAndBinaryOp {
> 
> One last comment, sorry did not notice before. Can we rename that to `TestVectorLibraryUnaryOpAndBinaryOp`? (I will approve no need for another review round for this change.)

Fixed, but "ready" label was removed by this change.
@PaulSandoz Could you approve again?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29835#discussion_r2866694355

From psandoz at openjdk.org  Sat Feb 28 00:10:29 2026
From: psandoz at openjdk.org (Paul Sandoz)
Date: Sat, 28 Feb 2026 00:10:29 GMT
Subject: RFR: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to
 intrinsify [v5]
In-Reply-To: <NE_jmfiv59iwbaxM1anxnQX57pLZXpXpEBgnC5sX8b4=.bc418104-7250-4a32-bbb5-30ffc2f7844a@github.com>
References: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
 <NE_jmfiv59iwbaxM1anxnQX57pLZXpXpEBgnC5sX8b4=.bc418104-7250-4a32-bbb5-30ffc2f7844a@github.com>
Message-ID: <zbTeJbrTVjf50m14BzQ0KDOFDXislnroIEhLgPaXutk=.ceca79d3-f5e5-436a-a6c6-dc2eeeaf2723@github.com>

On Sat, 28 Feb 2026 00:07:15 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I ran following code with `-Djdk.incubator.vector.DEBUG=true`, however it was not intrinsified.
>> 
>> 
>>   public static void cos(){
>>     var rand = new Random();
>>     for(int i = 0; i < 1_000_000; i++){
>>       var vec = DoubleVector.fromArray(DoubleVector.SPECIES_256, rand.doubles().limit(4).toArray(), 0);
>> 
>>       vec.lanewise(VectorOperators.COS);
>>     }
>>   }
>> 
>> 
>> I knew `__jsvml_cos4_ha_l9()` in libjsvml.so should be called in this case (via vector debug log), but it was not hitted even though I set breakpoint in it.
>> 
>> `LaneType` has been introduced in [JDK-8376187](https://bugs.openjdk.org/browse/JDK-8376187), and `LibraryCallKit::inline_vector_call()` was updated to handle lane type rather than class of element type. However `VectorMathLibrary` wasn't modified.
>> 
>> I confirmed `__jsvml_cos4_ha_l9()` is called with this fix, and also all jdk/jdk/incubator/vector jtreg tests passed on Linux AMD64.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename testcase

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29835#pullrequestreview-3869646309

From ysuenaga at openjdk.org  Sat Feb 28 03:31:31 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 28 Feb 2026 03:31:31 GMT
Subject: RFR: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to
 intrinsify [v5]
In-Reply-To: <NE_jmfiv59iwbaxM1anxnQX57pLZXpXpEBgnC5sX8b4=.bc418104-7250-4a32-bbb5-30ffc2f7844a@github.com>
References: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
 <NE_jmfiv59iwbaxM1anxnQX57pLZXpXpEBgnC5sX8b4=.bc418104-7250-4a32-bbb5-30ffc2f7844a@github.com>
Message-ID: <wMbHSbm_GAy2AywEioGPytxi87goJkJAxn0ktAD6YAI=.7fd9496a-b3b1-478f-b13f-f0b016f74bd6@github.com>

On Sat, 28 Feb 2026 00:07:15 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I ran following code with `-Djdk.incubator.vector.DEBUG=true`, however it was not intrinsified.
>> 
>> 
>>   public static void cos(){
>>     var rand = new Random();
>>     for(int i = 0; i < 1_000_000; i++){
>>       var vec = DoubleVector.fromArray(DoubleVector.SPECIES_256, rand.doubles().limit(4).toArray(), 0);
>> 
>>       vec.lanewise(VectorOperators.COS);
>>     }
>>   }
>> 
>> 
>> I knew `__jsvml_cos4_ha_l9()` in libjsvml.so should be called in this case (via vector debug log), but it was not hitted even though I set breakpoint in it.
>> 
>> `LaneType` has been introduced in [JDK-8376187](https://bugs.openjdk.org/browse/JDK-8376187), and `LibraryCallKit::inline_vector_call()` was updated to handle lane type rather than class of element type. However `VectorMathLibrary` wasn't modified.
>> 
>> I confirmed `__jsvml_cos4_ha_l9()` is called with this fix, and also all jdk/jdk/incubator/vector jtreg tests passed on Linux AMD64.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename testcase

Thanks both for your help!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29835#issuecomment-3976240516

From ysuenaga at openjdk.org  Sat Feb 28 03:31:33 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 28 Feb 2026 03:31:33 GMT
Subject: Integrated: 8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed
 to intrinsify
In-Reply-To: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
References: <gTH_cJiQDsVSrynthOS1vnVMJ4TTRaoiP6WxhK59vr4=.eb4ecee2-b63e-4bff-b399-f44e4d01923a@github.com>
Message-ID: <oQ5Lx98cc-lsK0bq7rk2fHe-358mhNgm96G7X9aXiZE=.f2b7b8eb-412a-4db5-9a8a-be1fc7057633@github.com>

On Fri, 20 Feb 2026 05:30:00 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I ran following code with `-Djdk.incubator.vector.DEBUG=true`, however it was not intrinsified.
> 
> 
>   public static void cos(){
>     var rand = new Random();
>     for(int i = 0; i < 1_000_000; i++){
>       var vec = DoubleVector.fromArray(DoubleVector.SPECIES_256, rand.doubles().limit(4).toArray(), 0);
> 
>       vec.lanewise(VectorOperators.COS);
>     }
>   }
> 
> 
> I knew `__jsvml_cos4_ha_l9()` in libjsvml.so should be called in this case (via vector debug log), but it was not hitted even though I set breakpoint in it.
> 
> `LaneType` has been introduced in [JDK-8376187](https://bugs.openjdk.org/browse/JDK-8376187), and `LibraryCallKit::inline_vector_call()` was updated to handle lane type rather than class of element type. However `VectorMathLibrary` wasn't modified.
> 
> I confirmed `__jsvml_cos4_ha_l9()` is called with this fix, and also all jdk/jdk/incubator/vector jtreg tests passed on Linux AMD64.

This pull request has now been integrated.

Changeset: 357f29dc
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/357f29dc864552a2c41e61b18ea73d9dda1c9825
Stats:     81 lines in 7 files changed: 68 ins; 0 del; 13 mod

8378312: [VectorAPI] libraryUnaryOp/libraryBinaryOp failed to intrinsify

Reviewed-by: psandoz, sherman

-------------

PR: https://git.openjdk.org/jdk/pull/29835

From eirbjo at openjdk.org  Sat Feb 28 05:44:30 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 28 Feb 2026 05:44:30 GMT
Subject: RFR: 8377992: (zipfs) Align ZipFileSystem END header validation
 with the ZipFile implementation [v3]
In-Reply-To: <6-UkqPxno7fpp6z_oO9l81t85YxdpsjkL0nr-_qlx0A=.46fd285e-5be7-49e7-a068-f0c4bd536a36@github.com>
References: <1tONCY1QoXxaeUtr3LE4YoZk0UitQ5NqadNJOPFjREQ=.9b237170-fb07-4713-82fb-26b968b268de@github.com>
 <6-UkqPxno7fpp6z_oO9l81t85YxdpsjkL0nr-_qlx0A=.46fd285e-5be7-49e7-a068-f0c4bd536a36@github.com>
Message-ID: <EvhB4qwmjcSni3tY4xPPQHa1t6BQPxa7DjIYrAsPczQ=.f96404ff-48aa-493e-a1c5-5b80e9ff62f7@github.com>

On Fri, 20 Feb 2026 18:28:54 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`.
>> 
>> This brings two validation checks over to `ZipFileSystem`:
>> 
>> * Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746)
>> * Rejection of END headers with a total entry count which cannot fit within the CEN byte array  (JDK-8341625)
>> 
>> Test vector setup in `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is extracted to a new test lib utility class `jdk.test.lib.util.ZipUtils`. `EndOfCenValidation` is then copied to `test/jdk/jdk/nio/zipfs` and adjusted to test `ZipFileSystem` instead of `ZipFile`.
>> 
>> Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries.  Similar adjustments to `ZipFile` was done in JDK-8341625.
>> 
>> `ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dial down on blank lines as vertical space

Thanks you Lance!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29747#issuecomment-3976443848

From eirbjo at openjdk.org  Sat Feb 28 05:44:32 2026
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 28 Feb 2026 05:44:32 GMT
Subject: Integrated: 8377992: (zipfs) Align ZipFileSystem END header validation
 with the ZipFile implementation
In-Reply-To: <1tONCY1QoXxaeUtr3LE4YoZk0UitQ5NqadNJOPFjREQ=.9b237170-fb07-4713-82fb-26b968b268de@github.com>
References: <1tONCY1QoXxaeUtr3LE4YoZk0UitQ5NqadNJOPFjREQ=.9b237170-fb07-4713-82fb-26b968b268de@github.com>
Message-ID: <FS3GjcX-ExSjJjDaEakymQTRMWK-JB6AWtFCr5bukuc=.009b27c0-ad96-448e-a441-85c3bc775370@github.com>

On Mon, 16 Feb 2026 15:15:28 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`.
> 
> This brings two validation checks over to `ZipFileSystem`:
> 
> * Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746)
> * Rejection of END headers with a total entry count which cannot fit within the CEN byte array  (JDK-8341625)
> 
> Test vector setup in `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is extracted to a new test lib utility class `jdk.test.lib.util.ZipUtils`. `EndOfCenValidation` is then copied to `test/jdk/jdk/nio/zipfs` and adjusted to test `ZipFileSystem` instead of `ZipFile`.
> 
> Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries.  Similar adjustments to `ZipFile` was done in JDK-8341625.
> 
> `ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`.

This pull request has now been integrated.

Changeset: d62b9f78
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d62b9f78ca4a35bb6c5f665172c7abce4dac56ca
Stats:     692 lines in 5 files changed: 425 ins; 229 del; 38 mod

8377992: (zipfs) Align ZipFileSystem END header validation with the ZipFile implementation

Reviewed-by: lancea

-------------

PR: https://git.openjdk.org/jdk/pull/29747

From stuefe at openjdk.org  Sat Feb 28 06:44:17 2026
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 28 Feb 2026 06:44:17 GMT
Subject: RFR: 8377907: (process) Race in ProcessBuilder can cause JVM hangs
In-Reply-To: <PFoU7RGLCUmRq1WTLCLy50eCKA2_uZ86DEr3179Y9ZQ=.a2a5cd61-72ec-466d-9836-55253db959d6@github.com>
References: <JPOHltHN-kr96XXbnfTXmhgFNNpqcPBi7nbAQ0Ng08c=.4f2a2a3d-0b00-4c76-890f-ea9903607dc2@github.com>
 <PFoU7RGLCUmRq1WTLCLy50eCKA2_uZ86DEr3179Y9ZQ=.a2a5cd61-72ec-466d-9836-55253db959d6@github.com>
Message-ID: <VH3IxHt-jLR4Hz_Rr13wBpOX20ZWIIHyo3zOPBHwcig=.a9ad4db0-aea9-4030-9f45-2404ac850605@github.com>

On Fri, 27 Feb 2026 18:29:43 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Hi Thomas,
> 
> Thanks a lot for finding this issue, describing it in all details and creating regression tests for it.
> 
> From a first glance the changes look OK but I'll have to take a closer look next week.
> 
> I am just a little concerned about the ever increasing code complexity in this area. Have you thought about using Unix domain sockets with `socketpair()` instead of pipes for the parent/child communication? That might be simpler and more portable, although I haven't really tried it out yet.

Hi Volker,

Yes, I thought about it, but I don't think it would improve matters much, and I wanted to keep the patch small. Also, most complexity just shifted. jspawnhelper is much less complex than before. And passing file descriptors via dup2 file action is arguably the canonical solution for these problems.

Complexity reduction will come. We will get rid of the VFORK mode very shortly, and maybe of the fork mode too, since it makes no sense to continue supporting it if posix_spawn works. Also, I plan to investigate the use of file actions more fully - most of what we do in jspawnhelper can be done via file actions in modern libc's (e.g. closing descriptors), and maybe at some point will get rid of the double exec and the jspawnhelper completely.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29939#issuecomment-3976534926

From duke at openjdk.org  Sat Feb 28 13:56:59 2026
From: duke at openjdk.org (Roger Calnan)
Date: Sat, 28 Feb 2026 13:56:59 GMT
Subject: RFR: 8377921: Add anchors to the options in the Core Libs tool man
 pages
Message-ID: <wLBBAUrbU6tSi-KjfSpYe8fH9NeNAAYyyC8poOs57iA=.c310db7f-f05e-4e67-b72b-8f397a0e0cf9@github.com>

adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option

-------------

Commit messages:
 - removed linking for --version
 - update compress option
 - initial update to man pages
 - Update full name

Changes: https://git.openjdk.org/jdk/pull/29978/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29978&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377921
  Stats: 35 lines in 2 files changed: 0 ins; 0 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/29978.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29978/head:pull/29978

PR: https://git.openjdk.org/jdk/pull/29978

From duke at openjdk.org  Sat Feb 28 14:32:00 2026
From: duke at openjdk.org (Roger Calnan)
Date: Sat, 28 Feb 2026 14:32:00 GMT
Subject: RFR: 8377923: Add anchors to the options in the Tools man pages
Message-ID: <r0Ep5KwK_BSA3zdpC6T9lWWPeCdGi5e-51O-Z9KsZhk=.2710b399-24b7-4c96-850b-5003f5c52dc0@github.com>

adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option

-------------

Commit messages:
 - removed link to option already covered by -feedback
 - clean up verbose options
 - only link one of the verbose options
 - removed links for some common options
 - initial update to options
 - Update full name

Changes: https://git.openjdk.org/jdk/pull/29979/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29979&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377923
  Stats: 84 lines in 6 files changed: 0 ins; 0 del; 84 mod
  Patch: https://git.openjdk.org/jdk/pull/29979.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29979/head:pull/29979

PR: https://git.openjdk.org/jdk/pull/29979

From cushon at openjdk.org  Sat Feb 28 18:38:20 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Sat, 28 Feb 2026 18:38:20 GMT
Subject: RFR: 8372353: API to compute the byte length of a String encoded
 in a given Charset [v20]
In-Reply-To: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
References: <QEveH7Ap3F6DIF79jPiruqqpTZrkZktw5TeL7V1QNWs=.df2169b1-1b2c-494c-b8ec-78cba9a46d50@github.com>
Message-ID: <Ik3YhNtHpLMJq9YA3VBHIqGaiuJcKxyuFlsip6icxJ8=.1ff0e9a4-f7f1-4977-a765-494851782ed7@github.com>

> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background.
> 
> ---
> 
> 
> Benchmark                              (encoding)  (stringLength)   Mode  Cnt          Score          Error  Units
> StringLoopJmhBenchmark.getBytes             ASCII              10  thrpt    5  406782650.595 ? 16960032.852  ops/s
> StringLoopJmhBenchmark.getBytes             ASCII             100  thrpt    5  172936926.189 ?  4532029.201  ops/s
> StringLoopJmhBenchmark.getBytes             ASCII            1000  thrpt    5   38830681.232 ?  2413274.766  ops/s
> StringLoopJmhBenchmark.getBytes             ASCII          100000  thrpt    5     458881.155 ?    12818.317  ops/s
> StringLoopJmhBenchmark.getBytes            LATIN1              10  thrpt    5   37193762.990 ?  3962947.391  ops/s
> StringLoopJmhBenchmark.getBytes            LATIN1             100  thrpt    5   55400876.236 ?  1267331.434  ops/s
> StringLoopJmhBenchmark.getBytes            LATIN1            1000  thrpt    5   11104514.001 ?    41718.545  ops/s
> StringLoopJmhBenchmark.getBytes            LATIN1          100000  thrpt    5     182535.414 ?    10296.120  ops/s
> StringLoopJmhBenchmark.getBytes             UTF16              10  thrpt    5  113474681.457 ?  8326589.199  ops/s
> StringLoopJmhBenchmark.getBytes             UTF16             100  thrpt    5   37854103.127 ?  4808526.773  ops/s
> StringLoopJmhBenchmark.getBytes             UTF16            1000  thrpt    5    4139833.009 ?    70636.784  ops/s
> StringLoopJmhBenchmark.getBytes             UTF16          100000  thrpt    5      57644.637 ?     1887.112  ops/s
> StringLoopJmhBenchmark.getBytesLength       ASCII              10  thrpt    5  946701647.247 ? 76938927.141  ops/s
> StringLoopJmhBenchmark.getBytesLength       ASCII             100  thrpt    5  396615374.479 ? 15167234.884  ops/s
> StringLoopJmhBenchmark.getBytesLength       ASCII            1000  thrpt    5  100464784.979 ?   794027.897  ops/s
> StringLoopJmhBenchmark.getBytesLength       ASCII          100000  thrpt    5    1215487.689 ?     1916.468  ops/s
> StringLoopJmhBenchmark.getBytesLength      LATIN1              10  thrpt    5  221265102.323 ? 17013983.056  ops/s
> StringLoopJmhBenchmark.getBytesLength      LATIN1             100  thrpt    5  137617873.887 ?  5842185.781  ops/s
> StringLoopJmhBenchmark.getBytesLength      LATIN1            1000  thrpt    5   92540259.130 ?  3839233.582  ops/s
> StringLoopJmhBenchmark.ge...

Liam Miller-Cushon 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 'origin/master' into strlen
 - Rename to encodedLength
 - Rename to getEncodedLength
 - Merge remote-tracking branch 'origin/master' into strlen
 - Rename getBytesLength to getByteLength
 - Update javadoc to refer to 'this {@code String}', not 'the given String'
 - Clarify that "It" in the javadoc means "This method"
 - Remove paragraph break
 - Add a note about malformed-input and unmappable-character sequences
 - Merge and optimize latin1 and ascii paths
 - ... and 13 more: https://git.openjdk.org/jdk/compare/13cc15d6...357db1d1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28454/files
  - new: https://git.openjdk.org/jdk/pull/28454/files/f9505f60..357db1d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=18-19

  Stats: 10658 lines in 271 files changed: 7553 ins; 1532 del; 1573 mod
  Patch: https://git.openjdk.org/jdk/pull/28454.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454

PR: https://git.openjdk.org/jdk/pull/28454