From wetmore at openjdk.org  Fri Aug  1 00:43:59 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 1 Aug 2025 00:43:59 GMT
Subject: RFR: 8209992: Align SSLSocket and SSLEngine Javadocs [v3]
In-Reply-To: <v08wdQTDWFv-K1M6sGzKSvXh2o_D-We5rRo_UH_UFl0=.88163a58-117f-4121-8b0f-432739578d90@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
 <v08wdQTDWFv-K1M6sGzKSvXh2o_D-We5rRo_UH_UFl0=.88163a58-117f-4121-8b0f-432739578d90@github.com>
Message-ID: <EaQd4t6jdEt07jF2o51WeTOwtAtkABvmINUE-alL-Cg=.f0a6b2cf-3e22-4fed-b033-65e38a8e5177@github.com>

On Thu, 31 Jul 2025 18:53:20 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Add a javadoc paragraph to SSLSocket.startHandshake() and SSLEngine.beginHandshake() methods explaining behavioral differences between TLSv1.3+ and TLSv1.2- versions.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Brad's code review

A couple minor fixes.

I'll approve next round.

src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 1101:

> 1099:      * dependent. For example, in TLSv1.3 calling this method after the
> 1100:      * connection has been established will force a key update. For prior TLS
> 1101:      * versions it will force a renegotiation (re-handshake).

You should delete 1115-1116, as it's duplicating what you have here.

src/java.base/share/classes/javax/net/ssl/SSLSocket.java line 520:

> 518:      * to flow during this handshake.  When the handshake completes, this
> 519:      * will be signaled with an event.
> 520:      * <P>

On line 524, put inside a {@code IOException}

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

PR Review: https://git.openjdk.org/jdk/pull/26484#pullrequestreview-3077251110
PR Review Comment: https://git.openjdk.org/jdk/pull/26484#discussion_r2246633075
PR Review Comment: https://git.openjdk.org/jdk/pull/26484#discussion_r2246634901

From haosun at openjdk.org  Fri Aug  1 01:07:19 2025
From: haosun at openjdk.org (Hao Sun)
Date: Fri, 1 Aug 2025 01:07:19 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v15]
In-Reply-To: <HuXsWjY3SAI9z6YRIPJeWNJQznPcZPbkG8qgWqRHx70=.20a8dc3f-f721-4a2b-9126-d7cf4c1140ec@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <HuXsWjY3SAI9z6YRIPJeWNJQznPcZPbkG8qgWqRHx70=.20a8dc3f-f721-4a2b-9126-d7cf4c1140ec@github.com>
Message-ID: <pYr9JQYqPMwyzKQsUwMen4VUeRivQneH95nccE5T7_g=.aaf8cf9f-b327-4908-a004-6c04e259fc78@github.com>

On Tue, 29 Jul 2025 21:00:44 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
>> 
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
>> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
>> 
>> **SUNX509 KeyManager performance before the change**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> 
>> **SUNX509 KeyManager performance after the change**
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fixes

Hi I found that `test/jdk/javax/management/security/SecurityTest.java` failed after this patch on both AArch64 and x86_64. Filed in https://bugs.openjdk.org/browse/JDK-8364495. I was wondering if you could help take a look at this issue? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-3141799952

From abarashev at openjdk.org  Fri Aug  1 10:15:20 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 1 Aug 2025 10:15:20 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v15]
In-Reply-To: <pYr9JQYqPMwyzKQsUwMen4VUeRivQneH95nccE5T7_g=.aaf8cf9f-b327-4908-a004-6c04e259fc78@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <HuXsWjY3SAI9z6YRIPJeWNJQznPcZPbkG8qgWqRHx70=.20a8dc3f-f721-4a2b-9126-d7cf4c1140ec@github.com>
 <pYr9JQYqPMwyzKQsUwMen4VUeRivQneH95nccE5T7_g=.aaf8cf9f-b327-4908-a004-6c04e259fc78@github.com>
Message-ID: <botxlK5QKf6vhN6fT0_40WWIfSN-8JD3WbHEDhPF_yg=.659ddced-659e-4138-b746-00148eda377d@github.com>

On Fri, 1 Aug 2025 01:04:33 GMT, Hao Sun <haosun at openjdk.org> wrote:

> Hi I found that `test/jdk/javax/management/security/SecurityTest.java` failed after this patch on both AArch64 and x86_64. Filed in https://bugs.openjdk.org/browse/JDK-8364495. I was wondering if you could help take a look at this issue? Thanks.

Hi! It's already fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-3144021668

From abarashev at openjdk.org  Fri Aug  1 15:18:10 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 1 Aug 2025 15:18:10 GMT
Subject: RFR: 8209992: Align SSLSocket and SSLEngine Javadocs [v4]
In-Reply-To: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
Message-ID: <hCWwXOG2sFI3tJy8LpXttN51dQZ4j6wbknWX2sYnAis=.8b064316-85ab-42fa-9b0e-b8b3e3c53e25@github.com>

> Add a javadoc paragraph to SSLSocket.startHandshake() and SSLEngine.beginHandshake() methods explaining behavioral differences between TLSv1.3+ and TLSv1.2- versions.

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

  Address latest review commants

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26484/files
  - new: https://git.openjdk.org/jdk/pull/26484/files/8cf4e12f..5779ff34

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

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

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

From abarashev at openjdk.org  Fri Aug  1 15:18:11 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 1 Aug 2025 15:18:11 GMT
Subject: RFR: 8209992: Align SSLSocket and SSLEngine Javadocs [v3]
In-Reply-To: <EaQd4t6jdEt07jF2o51WeTOwtAtkABvmINUE-alL-Cg=.f0a6b2cf-3e22-4fed-b033-65e38a8e5177@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
 <v08wdQTDWFv-K1M6sGzKSvXh2o_D-We5rRo_UH_UFl0=.88163a58-117f-4121-8b0f-432739578d90@github.com>
 <EaQd4t6jdEt07jF2o51WeTOwtAtkABvmINUE-alL-Cg=.f0a6b2cf-3e22-4fed-b033-65e38a8e5177@github.com>
Message-ID: <LptKwtgCONpcAkrkVNYkF82fGNmhn9TL54xqwpqHTZ4=.a7b519b5-856c-4fa3-85e3-0c2731cbe118@github.com>

On Fri, 1 Aug 2025 00:39:32 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Brad's code review
>
> src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 1101:
> 
>> 1099:      * dependent. For example, in TLSv1.3 calling this method after the
>> 1100:      * connection has been established will force a key update. For prior TLS
>> 1101:      * versions it will force a renegotiation (re-handshake).
> 
> You should delete 1115-1116, as it's duplicating what you have here.

Good catch, done!

> src/java.base/share/classes/javax/net/ssl/SSLSocket.java line 520:
> 
>> 518:      * to flow during this handshake.  When the handshake completes, this
>> 519:      * will be signaled with an event.
>> 520:      * <P>
> 
> On line 524, put inside a {@code IOException}

Done, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26484#discussion_r2248230395
PR Review Comment: https://git.openjdk.org/jdk/pull/26484#discussion_r2248233328

From spurn at amazon.com  Fri Aug  1 15:29:45 2025
From: spurn at amazon.com (Spurling, John)
Date: Fri, 1 Aug 2025 15:29:45 +0000
Subject: Handling multiple in-flight InetAddress.getByName queries for the
 same name at scale
Message-ID: <F82FFD7A-CF48-476D-96E5-A7C849524928@amazon.com>

Large, complicated DNS infrastructure setups coupled with varying application behavior, failure recovery scenarios, and long lived, large scale systems that are slow to migrate can lead to surprising, undesirable behavior when interacting with java.net.InetAddress's implementation of name resolution.

Multiple in-flight requests for the same host using InetAddress.NameServiceAddresses [0] are serialized on a lock [1]. The first request calls the system resolver [2]. Each additional request made before the resolver returns with a response shares the same instance of a NameServiceAddresses, each blocking in InetAdress.NameServiceAddresses.get until it gets the lock. Once all in-flight queries have completed, the InetAddress.NameServiceAddresses dies.

One potential difficulty lies in when the resolver takes longer to complete than the frequency at which name resolution requests are made. Normally, we expect subsequent name resolution requests to take less time than the first request, but that might not be the case. When it isn't, failures can become amplified due to the serialization of all queries on the same host.

Imagine that your DNS infrastructure requires that you disable the networkaddress caches since the minimum enabled value is 1 second, which is too large. If the system resolver takes 1 second, and subsequent resolver calls also take 1 second, and queries are made at a rate of more than one a second, each query will take longer and longer, since each call needs to wait for the resolver to complete, plus the time it spends waiting for the lock. One can see how this might lead to service outages.

There are multiple potential ways to deal with the NameServiceAddresses lock.

One way is to provide finer grained expiry for the cache. Instead of providing the cache timeouts in integer seconds, provide some hook to provide them in milliseconds. Leaving caching enabled but providing smaller timeouts could help provide the right level of control to avoid some of these complicated issues at scale.

Another way is to simply have all in-flight queries return the same result. NameServiceAddresses instances would die more quickly: only the first call to getAddressesFromNameService would be made, the result would be cached in the object. Each subsequent call made during that time would quickly return the result cached in the NameServiceAddresses instance, and the instance would quickly die. New getByName requests would create NameServiceAddresses instances as usual.

Other larger scale rewrites are also possible, but given how battle-tested the current implementation is and the potential dangers here, I imagine something smaller might be more acceptable.

Thoughts?

-john

[0] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/InetAddress.java#L1689C8-L1695C15
[1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/InetAddress.java#L1043
[2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/InetAddress.java#L1060


From ecki at zusammenkunft.net  Fri Aug  1 16:42:55 2025
From: ecki at zusammenkunft.net (ecki)
Date: Fri, 1 Aug 2025 18:42:55 +0200
Subject: Handling multiple in-flight InetAddress.getByName queries for
 the same name at scale
In-Reply-To: <F82FFD7A-CF48-476D-96E5-A7C849524928@amazon.com>
References: <F82FFD7A-CF48-476D-96E5-A7C849524928@amazon.com>
Message-ID: <8F76378C-1390-AB42-9FEC-33B1549D496E@hxcore.ol>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250801/d436a470/attachment-0001.htm>

From wetmore at openjdk.org  Fri Aug  1 20:13:58 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 1 Aug 2025 20:13:58 GMT
Subject: RFR: 8209992: Align SSLSocket and SSLEngine Javadocs [v4]
In-Reply-To: <hCWwXOG2sFI3tJy8LpXttN51dQZ4j6wbknWX2sYnAis=.8b064316-85ab-42fa-9b0e-b8b3e3c53e25@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
 <hCWwXOG2sFI3tJy8LpXttN51dQZ4j6wbknWX2sYnAis=.8b064316-85ab-42fa-9b0e-b8b3e3c53e25@github.com>
Message-ID: <K7wQuY_8jTVtDX2QMeB_gAqcfg26Y43EBkYszmCGUjU=.bc021f52-137c-4757-b913-bf968db3cb55@github.com>

On Fri, 1 Aug 2025 15:18:10 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Add a javadoc paragraph to SSLSocket.startHandshake() and SSLEngine.beginHandshake() methods explaining behavioral differences between TLSv1.3+ and TLSv1.2- versions.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address latest review commants

LGTM.  Thanks for the updates.

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

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26484#pullrequestreview-3080451570

From jpai at openjdk.org  Mon Aug  4 12:32:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 4 Aug 2025 12:32:57 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v5]
In-Reply-To: <RtuN1tYoGPnhKaiz_mblX3DMcHWVPTDbF-lmDpFaoXo=.c5e35618-0979-4aa1-91ef-64ffca65ff2c@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <RtuN1tYoGPnhKaiz_mblX3DMcHWVPTDbF-lmDpFaoXo=.c5e35618-0979-4aa1-91ef-64ffca65ff2c@github.com>
Message-ID: <3T0ZQTcLX_nQ4oUiTzQ29txupSdnwn-HzqXUQorcqdY=.5878558f-749f-487d-9a54-40c8ca8ab92d@github.com>

On Wed, 30 Jul 2025 09:32:17 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply review feedback for `FileChannelPublisherTest`

Hello Volkan, the test updates you have done look good to me. I'll need another day or two to go over the javadoc text and one final brief review of the test.

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

PR Comment: https://git.openjdk.org/jdk/pull/26155#issuecomment-3150456938

From abarashev at openjdk.org  Mon Aug  4 13:59:03 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 4 Aug 2025 13:59:03 GMT
Subject: Integrated: 8209992: Align SSLSocket and SSLEngine Javadocs
In-Reply-To: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
Message-ID: <gxfNgJoKQIV5OanUNCP_fvHt_Zrc-xty888gAzN1knc=.46821ecf-24cb-4952-bd51-e3f267a27d88@github.com>

On Fri, 25 Jul 2025 16:27:42 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> Add a javadoc paragraph to SSLSocket.startHandshake() and SSLEngine.beginHandshake() methods explaining behavioral differences between TLSv1.3+ and TLSv1.2- versions.

This pull request has now been integrated.

Changeset: 6c52b734
Author:    Artur Barashev <abarashev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6c52b73465b0d0daeafc54c3c6cec3062bf490c5
Stats:     29 lines in 2 files changed: 17 ins; 3 del; 9 mod

8209992: Align SSLSocket and SSLEngine Javadocs

Reviewed-by: wetmore

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

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

From vyazici at openjdk.org  Tue Aug  5 10:33:46 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 5 Aug 2025 10:33:46 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v6]
In-Reply-To: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
Message-ID: <BNyl_bylEFuLmk6SzmvKujegcw-hOChFiqNdURvCyOM=.c60a91ee-875d-4a80-85b7-f6ac93c1e0b2@github.com>

> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
> 
>> The file channel will not be closed upon completion. The caller is
>> expected to manage the life cycle of the channel, and close it
>> appropriately when not needed anymore.
> 
> ### Implementation notes
> 
> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.

Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:

 - Verify exceptions using both `send()` and `sendAsync()`
 - Replace usage of `CompletableFuture` with `Future`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26155/files
  - new: https://git.openjdk.org/jdk/pull/26155/files/99503c0b..faa5d24d

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

  Stats: 108 lines in 1 file changed: 89 ins; 9 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/26155.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26155/head:pull/26155

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

From vyazici at openjdk.org  Tue Aug  5 10:43:08 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 5 Aug 2025 10:43:08 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <nnyrhqHZXLgdqW13aYbz8puCM688BbdDLxZi0AwKGLQ=.8d5938ba-b88f-4b88-98af-71ae35253beb@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
 <NQ8GkzuYvVUmP6CrBT61yjTt0B90nDKaPgX8rgG-zoE=.e56b58ef-1d46-4ba5-b413-7927bfbbf370@github.com>
 <iivI8nKd-hVeQbv0zFmP21yvLxFCGMBxMgbtpriiqlQ=.d0b9abe7-f6d3-4412-9177-281054c61c2a@github.com>
 <eXsopp9trwJc8k2e1uNXU_fLscncMF9g1MLiL4wXNJQ=.b9111198-bbf1-41e6-900f-9852eb8178eb@github.com>
 <7j14xvrLzetod3mICHEFATv0_oAB101fSyPCo8asYcc=.2775daeb-0166-4118-9cc4-b7a2345843b7@github.com>
 <nnyrhqHZXLgdqW13aYbz8puCM688BbdDLxZi0AwKGLQ=.8d5938ba-b88f-4b88-98af-71ae35253beb@github.com>
Message-ID: <Xbo6yctJXAJThffoCF5IBvsfryuUIpxplvlpn8QSnlY=.a897afa9-c5d5-43d2-bc31-cfe481f058e5@github.com>

On Thu, 31 Jul 2025 06:30:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> add a test which uses send()

@jaikiran, in faa5d24d831, I've adapted all exception verification tests to take both `send()` and `sendAsync()` into account.

>  both send() and sendAsync() should propagate the same exception

Right. I will discuss this with @dfuch and @Michael-Mc-Mahon.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2253945179

From vyazici at openjdk.org  Tue Aug  5 11:27:16 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 5 Aug 2025 11:27:16 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v7]
In-Reply-To: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
Message-ID: <-sb4AkUVzeIHUo_Aq30bpxunVrDgjEBseviicW_NHCo=.345046be-9fa2-4ca9-adc7-74800924783e@github.com>

> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
> 
>> The file channel will not be closed upon completion. The caller is
>> expected to manage the life cycle of the channel, and close it
>> appropriately when not needed anymore.
> 
> ### Implementation notes
> 
> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.

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

  Revert the last commit: faa5d24d831
  
  The `send()`-vs-`sendAsync()` discrepancy will be addressed separately.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26155/files
  - new: https://git.openjdk.org/jdk/pull/26155/files/faa5d24d..c8a0257a

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

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

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

From dfuchs at openjdk.org  Tue Aug  5 14:35:06 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 5 Aug 2025 14:35:06 GMT
Subject: RFR: 8352502: Response message is null if expect 100 assertion
 fails with non 100 [v3]
In-Reply-To: <irAM7GphyMXZ5917QklArwZwvx7bTxb2-t0O0BHcp6Y=.d18d1a4a-bed5-4b4f-bc44-9e3d3cfd739c@github.com>
References: <Wdwcz-OrrHA0ZkTpjFSZ4e7ThgwHIEtaousm-NYbRVQ=.d170fc75-0dbf-404b-b59b-85ad52b56ca4@github.com>
 <irAM7GphyMXZ5917QklArwZwvx7bTxb2-t0O0BHcp6Y=.d18d1a4a-bed5-4b4f-bc44-9e3d3cfd739c@github.com>
Message-ID: <m9B4hrFKZUvMzzuV2z4SuRAdqomfQLdc5nWweQybnrs=.e5a0c19e-5b98-454b-8768-2f8c3046d451@github.com>

On Thu, 10 Jul 2025 13:28:26 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> Currently if a request has set Expect-Continue and receives a non 100 response the `responseMessage` wouldn't be set.
>> 
>> This PR sets `responseMessage`, it also updates `getResponseMessage` to check if the message has already been set. This should match the way that `responseCode` is currently handled.
>> 
>> I also added a test to cover some possible responses.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding salting and path verification to test

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25999#pullrequestreview-3088574176

From dfuchs at openjdk.org  Tue Aug  5 19:17:35 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 5 Aug 2025 19:17:35 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v12]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <SCsRMYq_YcUXak0vqS9nds-o8JCzef-RS8XmXCWqxkk=.422e19d8-d034-4bd4-a925-63f242f7734c@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 588 commits:

 - merge latest changes from master branch
 - qpack: modify Encoder.header to use DT lock, test headers cleanup.
 - merge latest from master branch
 - merge latest from master branch
 - Include peer's error information in exceptions thrown on connection close
 - Fix error IDs
 - Remove assertion error
 - Remove assertion errors from packet encryption
 - Remove assertion errors from retry packet handling
 - Remove assertion errors from initial key derivation
 - ... and 578 more: https://git.openjdk.org/jdk/compare/d906e450...83f8dad1

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=11
  Stats: 105164 lines in 470 files changed: 102303 ins; 1335 del; 1526 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

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

From jpai at openjdk.org  Fri Aug  8 07:00:29 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 07:00:29 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently fails
 - 24999 handled, expected 25000
Message-ID: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>

Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.

As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.

The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.

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

Commit messages:
 - close the server Executor and thus wait for the HttpHandler(s) to complete before asserting on the counter
 - general clean up and some logging

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

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

From alanb at openjdk.org  Fri Aug  8 07:41:12 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Aug 2025 07:41:12 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000
In-Reply-To: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
Message-ID: <Y4XcSFhve0NXCqC-DD9qHGL6mwuyEMVM1w1joSO8Ojc=.4588f331-a6a7-4e54-9a91-97748760514c@github.com>

On Fri, 8 Aug 2025 06:52:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.
> 
> As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.
> 
> The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.

test/jdk/java/net/vthread/HttpALot.java line 36:

> 34: import java.util.concurrent.atomic.AtomicInteger;
> 35: import com.sun.net.httpserver.HttpServer;
> 36: import jdk.test.lib.net.URIBuilder;

Did you mean to move the imports? Just curious as I usually put the test description at the top to make it easy to find, I guess others prefer it after the imports.

test/jdk/java/net/vthread/HttpALot.java line 98:

> 96:         // go
> 97:         server.start();
> 98:         try (serverExecutor) {

This part looks good, as does checking that the task result is "Hello" as that adds more checking.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26686#discussion_r2262171408
PR Review Comment: https://git.openjdk.org/jdk/pull/26686#discussion_r2262178653

From jpai at openjdk.org  Fri Aug  8 07:45:11 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 07:45:11 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000
In-Reply-To: <Y4XcSFhve0NXCqC-DD9qHGL6mwuyEMVM1w1joSO8Ojc=.4588f331-a6a7-4e54-9a91-97748760514c@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
 <Y4XcSFhve0NXCqC-DD9qHGL6mwuyEMVM1w1joSO8Ojc=.4588f331-a6a7-4e54-9a91-97748760514c@github.com>
Message-ID: <4prrMb_Zq50pD9tSlXGQT78DNv8sTtJciKuxbyHvKuI=.3c629f78-97dd-41db-ba17-bcf44f88899b@github.com>

On Fri, 8 Aug 2025 07:34:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.
>> 
>> As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.
>> 
>> The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.
>
> test/jdk/java/net/vthread/HttpALot.java line 36:
> 
>> 34: import java.util.concurrent.atomic.AtomicInteger;
>> 35: import com.sun.net.httpserver.HttpServer;
>> 36: import jdk.test.lib.net.URIBuilder;
> 
> Did you mean to move the imports? Just curious as I usually put the test description at the top to make it easy to find, I guess others prefer it after the imports.

Hello Alan, I will undo that part. I usually prefer the test definition directly above the class declaration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26686#discussion_r2262185675

From jpai at openjdk.org  Fri Aug  8 07:57:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 07:57:57 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v2]
In-Reply-To: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
Message-ID: <Gq52iVy41lubhPIc0VNBHOu1u3E1zhs_fVwlEGK6ewc=.c4453d83-2299-4f9c-8183-d8d325e753cf@github.com>

> Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.
> 
> As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.
> 
> The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.

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

  Alan's review - move the test definition back to before the imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26686/files
  - new: https://git.openjdk.org/jdk/pull/26686/files/efdbbbb9..30044906

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

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

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

From alanb at openjdk.org  Fri Aug  8 07:57:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Aug 2025 07:57:57 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v2]
In-Reply-To: <4prrMb_Zq50pD9tSlXGQT78DNv8sTtJciKuxbyHvKuI=.3c629f78-97dd-41db-ba17-bcf44f88899b@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
 <Y4XcSFhve0NXCqC-DD9qHGL6mwuyEMVM1w1joSO8Ojc=.4588f331-a6a7-4e54-9a91-97748760514c@github.com>
 <4prrMb_Zq50pD9tSlXGQT78DNv8sTtJciKuxbyHvKuI=.3c629f78-97dd-41db-ba17-bcf44f88899b@github.com>
Message-ID: <7ek13N74iXl2ez8IHQuX4a5LLSSO0UbC_cu4nYtyjNc=.b156132d-6d23-4a75-a379-50cd5ddae67c@github.com>

On Fri, 8 Aug 2025 07:42:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/net/vthread/HttpALot.java line 36:
>> 
>>> 34: import java.util.concurrent.atomic.AtomicInteger;
>>> 35: import com.sun.net.httpserver.HttpServer;
>>> 36: import jdk.test.lib.net.URIBuilder;
>> 
>> Did you mean to move the imports? Just curious as I usually put the test description at the top to make it easy to find, I guess others prefer it after the imports.
>
> Hello Alan, I will undo that part. I usually prefer the test definition directly above the class declaration.

It's okay, I was just trying to see if the test description was changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26686#discussion_r2262200974

From jpai at openjdk.org  Fri Aug  8 07:57:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 07:57:58 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v2]
In-Reply-To: <7ek13N74iXl2ez8IHQuX4a5LLSSO0UbC_cu4nYtyjNc=.b156132d-6d23-4a75-a379-50cd5ddae67c@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
 <Y4XcSFhve0NXCqC-DD9qHGL6mwuyEMVM1w1joSO8Ojc=.4588f331-a6a7-4e54-9a91-97748760514c@github.com>
 <4prrMb_Zq50pD9tSlXGQT78DNv8sTtJciKuxbyHvKuI=.3c629f78-97dd-41db-ba17-bcf44f88899b@github.com>
 <7ek13N74iXl2ez8IHQuX4a5LLSSO0UbC_cu4nYtyjNc=.b156132d-6d23-4a75-a379-50cd5ddae67c@github.com>
Message-ID: <gcYmchR1P84UXpFBxavUXwkJ1hRsWlfviLrd86dno-w=.3c2b8d1f-1485-4c23-a47a-0a1465af841e@github.com>

On Fri, 8 Aug 2025 07:48:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hello Alan, I will undo that part. I usually prefer the test definition directly above the class declaration.
>
> It's okay, I was just trying to see if the test description was changed.

I just happened to revert this part in the PR :) So I'll let it be before the imports, like it was before. No changes to the `@test` definition, except replacing `/**` with the recommended `/*`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26686#discussion_r2262208088

From dfuchs at openjdk.org  Fri Aug  8 09:05:11 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 8 Aug 2025 09:05:11 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v2]
In-Reply-To: <Y4XcSFhve0NXCqC-DD9qHGL6mwuyEMVM1w1joSO8Ojc=.4588f331-a6a7-4e54-9a91-97748760514c@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
 <Y4XcSFhve0NXCqC-DD9qHGL6mwuyEMVM1w1joSO8Ojc=.4588f331-a6a7-4e54-9a91-97748760514c@github.com>
Message-ID: <VJlvKHI5xWindjQETozq36wR4qwAHXa5j4UbZwG4n7U=.17ced730-aa3b-44ae-b4b5-6cd39d928fee@github.com>

On Fri, 8 Aug 2025 07:38:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Alan's review - move the test definition back to before the imports
>
> test/jdk/java/net/vthread/HttpALot.java line 98:
> 
>> 96:         // go
>> 97:         server.start();
>> 98:         try (serverExecutor) {
> 
> This part looks good, as does checking that the task result is "Hello" as that adds more checking.

It would be more correct to close the server executor after server.stop() returns, to make sure the server will not try to use the executor after it's closed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26686#discussion_r2262373491

From jpai at openjdk.org  Fri Aug  8 09:21:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 09:21:59 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v3]
In-Reply-To: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
Message-ID: <ieuUYCreTbw9DjOS7fjETMge_6rnrJqNmEWB13c0uL0=.ba9cc8e0-9f55-4cad-8917-724db280e3b1@github.com>

> Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.
> 
> As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.
> 
> The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.

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

  Daniel's review - close the server Executor after server.stop()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26686/files
  - new: https://git.openjdk.org/jdk/pull/26686/files/30044906..fd5298ca

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

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

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

From jpai at openjdk.org  Fri Aug  8 09:21:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 09:21:59 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v3]
In-Reply-To: <VJlvKHI5xWindjQETozq36wR4qwAHXa5j4UbZwG4n7U=.17ced730-aa3b-44ae-b4b5-6cd39d928fee@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
 <Y4XcSFhve0NXCqC-DD9qHGL6mwuyEMVM1w1joSO8Ojc=.4588f331-a6a7-4e54-9a91-97748760514c@github.com>
 <VJlvKHI5xWindjQETozq36wR4qwAHXa5j4UbZwG4n7U=.17ced730-aa3b-44ae-b4b5-6cd39d928fee@github.com>
Message-ID: <q-2_RUFVzYMLUPXp4_YXM8--M6022P7NsIKPbK0aZ_0=.b396ca5f-f1f5-48c2-b1c9-5b4462c18af1@github.com>

On Fri, 8 Aug 2025 09:02:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/vthread/HttpALot.java line 98:
>> 
>>> 96:         // go
>>> 97:         server.start();
>>> 98:         try (serverExecutor) {
>> 
>> This part looks good, as does checking that the task result is "Hello" as that adds more checking.
>
> It would be more correct to close the server executor after server.stop() returns, to make sure the server will not try to use the executor after it's closed.

Done. I've updated the PR to close the executor after the server is stopped.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26686#discussion_r2262407890

From dfuchs at openjdk.org  Fri Aug  8 09:50:10 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 8 Aug 2025 09:50:10 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v3]
In-Reply-To: <ieuUYCreTbw9DjOS7fjETMge_6rnrJqNmEWB13c0uL0=.ba9cc8e0-9f55-4cad-8917-724db280e3b1@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
 <ieuUYCreTbw9DjOS7fjETMge_6rnrJqNmEWB13c0uL0=.ba9cc8e0-9f55-4cad-8917-724db280e3b1@github.com>
Message-ID: <QBz73txRAswN3EFNWRm25i2rFQaK0wPAm_In3n5d7XQ=.844be743-7ec3-4eab-8b0b-985ea8646f3a@github.com>

On Fri, 8 Aug 2025 09:21:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.
>> 
>> As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.
>> 
>> The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's review - close the server Executor after server.stop()

Thanks Jaikiran! Looks good to me.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26686#pullrequestreview-3100176836

From alanb at openjdk.org  Fri Aug  8 10:32:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Aug 2025 10:32:11 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v3]
In-Reply-To: <ieuUYCreTbw9DjOS7fjETMge_6rnrJqNmEWB13c0uL0=.ba9cc8e0-9f55-4cad-8917-724db280e3b1@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
 <ieuUYCreTbw9DjOS7fjETMge_6rnrJqNmEWB13c0uL0=.ba9cc8e0-9f55-4cad-8917-724db280e3b1@github.com>
Message-ID: <EcFjKANyVet1aYiRDaWCLGyxO3gAi3oxA_890R8DGYc=.3fa7843c-56ed-418b-8d97-c2c474c42531@github.com>

On Fri, 8 Aug 2025 09:21:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.
>> 
>> As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.
>> 
>> The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's review - close the server Executor after server.stop()

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26686#pullrequestreview-3100287567

From vyazici at openjdk.org  Fri Aug  8 12:12:16 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 8 Aug 2025 12:12:16 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v3]
In-Reply-To: <ieuUYCreTbw9DjOS7fjETMge_6rnrJqNmEWB13c0uL0=.ba9cc8e0-9f55-4cad-8917-724db280e3b1@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
 <ieuUYCreTbw9DjOS7fjETMge_6rnrJqNmEWB13c0uL0=.ba9cc8e0-9f55-4cad-8917-724db280e3b1@github.com>
Message-ID: <4sleDanLsDaAWOPXMMQr97C-2BtimzsBBpnJgxYCcfQ=.908102c0-9f17-45db-abfc-d15b48653843@github.com>

On Fri, 8 Aug 2025 09:21:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.
>> 
>> As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.
>> 
>> The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's review - close the server Executor after server.stop()

Marked as reviewed by vyazici (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26686#pullrequestreview-3100570151

From jpai at openjdk.org  Fri Aug  8 13:34:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 13:34:52 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List
Message-ID: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>

Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?

`java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.

The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.

I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.

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

Commit messages:
 - 8365086: CookieStore.getURIs() and get(URI) should return an immutable List
 - 8365086: add a test

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

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

From vyazici at openjdk.org  Fri Aug  8 14:11:11 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 8 Aug 2025 14:11:11 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List
In-Reply-To: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
Message-ID: <Cr7F97rkzkAAfC0pqMiI8IgMVPr7-mSOyrX2ocNHMUQ=.e8e5ce6b-f090-4181-ae67-11d7f3124700@github.com>

On Fri, 8 Aug 2025 13:28:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?
> 
> `java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.
> 
> The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.
> 
> I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.

Marked as reviewed by vyazici (Committer).

test/jdk/java/net/CookieStoreTest.java line 45:

> 43:  * @run junit CookieStoreTest
> 44:  */
> 45: class CookieStoreTest {

Otherwise you get a warning that the comment block should start with a `/**`:

Suggestion:


class CookieStoreTest {

test/jdk/java/net/CookieStoreTest.java line 110:

> 108:         // an element must fail
> 109:         assertThrows(UnsupportedOperationException.class, () -> cookies.add(cookie));
> 110:         assertThrows(UnsupportedOperationException.class, () -> cookies.remove(cookie));

Nit: You can consider factoring this out to a `assertCookieStoreIsImmutable(CookieStore)` method.

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

PR Review: https://git.openjdk.org/jdk/pull/26698#pullrequestreview-3100989703
PR Review Comment: https://git.openjdk.org/jdk/pull/26698#discussion_r2263087979
PR Review Comment: https://git.openjdk.org/jdk/pull/26698#discussion_r2263088219

From jpai at openjdk.org  Fri Aug  8 14:21:13 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 14:21:13 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List
In-Reply-To: <Cr7F97rkzkAAfC0pqMiI8IgMVPr7-mSOyrX2ocNHMUQ=.e8e5ce6b-f090-4181-ae67-11d7f3124700@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <Cr7F97rkzkAAfC0pqMiI8IgMVPr7-mSOyrX2ocNHMUQ=.e8e5ce6b-f090-4181-ae67-11d7f3124700@github.com>
Message-ID: <GFhyCQmZO3GS7VZM1iWHzmFyyonyczNC997YbSq6IA0=.fb64fcf0-f934-4a2a-9c60-d37cd906d67d@github.com>

On Fri, 8 Aug 2025 14:07:28 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?
>> 
>> `java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.
>> 
>> The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.
>> 
>> I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.
>
> test/jdk/java/net/CookieStoreTest.java line 45:
> 
>> 43:  * @run junit CookieStoreTest
>> 44:  */
>> 45: class CookieStoreTest {
> 
> Otherwise you get a warning that the comment block should start with a `/**`:
> 
> Suggestion:
> 
> 
> class CookieStoreTest {

Hello Volkan, is that warning generated by a IDE? I don't see it in IntelliJ:

<img width="704" height="192" alt="ide" src="https://github.com/user-attachments/assets/b45345a2-343a-49ea-ab82-47bd40e6b87d" />

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26698#discussion_r2263124441

From jpai at openjdk.org  Fri Aug  8 14:36:17 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 14:36:17 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v2]
In-Reply-To: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
Message-ID: <_5JgON9h8m_NG0bn0V2mSO0qGQRuHG4WeK4X-4tIGy0=.499d6c41-2043-4e0e-b546-43e04c07377a@github.com>

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?
> 
> `java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.
> 
> The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.
> 
> I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.

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

  Volkan's review - refactor assertions into a method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26698/files
  - new: https://git.openjdk.org/jdk/pull/26698/files/914fde9a..7b92b0a6

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

  Stats: 21 lines in 1 file changed: 6 ins; 9 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26698.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26698/head:pull/26698

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

From jpai at openjdk.org  Fri Aug  8 14:36:18 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 14:36:18 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v2]
In-Reply-To: <Cr7F97rkzkAAfC0pqMiI8IgMVPr7-mSOyrX2ocNHMUQ=.e8e5ce6b-f090-4181-ae67-11d7f3124700@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <Cr7F97rkzkAAfC0pqMiI8IgMVPr7-mSOyrX2ocNHMUQ=.e8e5ce6b-f090-4181-ae67-11d7f3124700@github.com>
Message-ID: <nb5_qJTv1PEHVPANPI9HmAAde22psPiLi3iBFYtUACs=.1b58b456-7d70-4526-bbd3-2227a00243a4@github.com>

On Fri, 8 Aug 2025 14:07:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Volkan's review - refactor assertions into a method
>
> test/jdk/java/net/CookieStoreTest.java line 110:
> 
>> 108:         // an element must fail
>> 109:         assertThrows(UnsupportedOperationException.class, () -> cookies.add(cookie));
>> 110:         assertThrows(UnsupportedOperationException.class, () -> cookies.remove(cookie));
> 
> Nit: You can consider factoring this out to a `assertCookieStoreIsImmutable(CookieStore)` method.

Done. I've moved couple of those assertions to a separate method to be called from each of these test methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26698#discussion_r2263151177

From dfuchs at openjdk.org  Fri Aug  8 14:50:15 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 8 Aug 2025 14:50:15 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v2]
In-Reply-To: <_5JgON9h8m_NG0bn0V2mSO0qGQRuHG4WeK4X-4tIGy0=.499d6c41-2043-4e0e-b546-43e04c07377a@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <_5JgON9h8m_NG0bn0V2mSO0qGQRuHG4WeK4X-4tIGy0=.499d6c41-2043-4e0e-b546-43e04c07377a@github.com>
Message-ID: <-wQhKp-Z2OMwDYlop0KiJUIznsIX1Gr3xJRtURrzXX8=.3320e978-4cd2-4f99-9ec9-2f57076c8664@github.com>

On Fri, 8 Aug 2025 14:36:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?
>> 
>> `java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.
>> 
>> The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.
>> 
>> I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Volkan's review - refactor assertions into a method

LGTM. It may be useful to plan a release note, in case an application is depending on being able to add/remove stuff to/from the returned list, despite the documentation stating they should be immutable. For instance - an application may attempt to clear() the returned list.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26698#pullrequestreview-3101122892

From liach at openjdk.org  Fri Aug  8 17:21:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Aug 2025 17:21:19 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v2]
In-Reply-To: <GFhyCQmZO3GS7VZM1iWHzmFyyonyczNC997YbSq6IA0=.fb64fcf0-f934-4a2a-9c60-d37cd906d67d@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <Cr7F97rkzkAAfC0pqMiI8IgMVPr7-mSOyrX2ocNHMUQ=.e8e5ce6b-f090-4181-ae67-11d7f3124700@github.com>
 <GFhyCQmZO3GS7VZM1iWHzmFyyonyczNC997YbSq6IA0=.fb64fcf0-f934-4a2a-9c60-d37cd906d67d@github.com>
Message-ID: <VbnzY-bfsCQ9LL8NPyUUsV5MzCKyRmkUuwdo9KllhG4=.fd72a940-e302-4b22-b4fc-c26f9f93389d@github.com>

On Fri, 8 Aug 2025 14:18:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/net/CookieStoreTest.java line 45:
>> 
>>> 43:  * @run junit CookieStoreTest
>>> 44:  */
>>> 45: class CookieStoreTest {
>> 
>> Otherwise you get a warning that the comment block should start with a `/**`:
>> 
>> Suggestion:
>> 
>> 
>> class CookieStoreTest {
>
> Hello Volkan, is that warning generated by a IDE? I don't see it in IntelliJ:
> 
> <img width="704" height="192" alt="ide" src="https://github.com/user-attachments/assets/b45345a2-343a-49ea-ab82-47bd40e6b87d" />

I think we usually put the jtreg directive block before the imports.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26698#discussion_r2263621068

From liach at openjdk.org  Fri Aug  8 17:21:20 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Aug 2025 17:21:20 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v2]
In-Reply-To: <_5JgON9h8m_NG0bn0V2mSO0qGQRuHG4WeK4X-4tIGy0=.499d6c41-2043-4e0e-b546-43e04c07377a@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <_5JgON9h8m_NG0bn0V2mSO0qGQRuHG4WeK4X-4tIGy0=.499d6c41-2043-4e0e-b546-43e04c07377a@github.com>
Message-ID: <X8PGgJJzisRXKIoWPIS56FW1hB2hsjfbBFKUME0V2vw=.5c92593f-e7f5-4c43-b54a-d298e6b91d65@github.com>

On Fri, 8 Aug 2025 14:36:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?
>> 
>> `java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.
>> 
>> The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.
>> 
>> I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Volkan's review - refactor assertions into a method

test/jdk/java/net/CookieStoreTest.java line 107:

> 105:         // an element must fail
> 106:         assertThrows(UnsupportedOperationException.class, () -> list.add(elementToAddOrRemove));
> 107:         assertThrows(UnsupportedOperationException.class, () -> list.remove(elementToAddOrRemove));

I think trying `list.set` would be meaningful too, given `Arrays.asList` would pass these two tests but is actually mutable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26698#discussion_r2263622701

From jpai at openjdk.org  Sat Aug  9 02:04:26 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 9 Aug 2025 02:04:26 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v3]
In-Reply-To: <ieuUYCreTbw9DjOS7fjETMge_6rnrJqNmEWB13c0uL0=.ba9cc8e0-9f55-4cad-8917-724db280e3b1@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
 <ieuUYCreTbw9DjOS7fjETMge_6rnrJqNmEWB13c0uL0=.ba9cc8e0-9f55-4cad-8917-724db280e3b1@github.com>
Message-ID: <x5yVGdewwDHTeU2tq3C8h7nxjLsI-n-RDOlZcxbtNDA=.bf3677bd-d849-4527-aae2-b01b9562c38a@github.com>

On Fri, 8 Aug 2025 09:21:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.
>> 
>> As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.
>> 
>> The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's review - close the server Executor after server.stop()

Thank you all for the reviews. tier testing and repeat testing of this change passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26686#issuecomment-3169642053

From jpai at openjdk.org  Sat Aug  9 02:04:27 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 9 Aug 2025 02:04:27 GMT
Subject: Integrated: 8364786: Test java/net/vthread/HttpALot.java
 intermittently fails - 24999 handled, expected 25000
In-Reply-To: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
Message-ID: <KdvfPYhesxPa69HpZaXgiAc90ndFjQCvWtqBSgzSBhs=.93e62818-bc83-4d43-b62f-fd53f61190df@github.com>

On Fri, 8 Aug 2025 06:52:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.
> 
> As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.
> 
> The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.

This pull request has now been integrated.

Changeset: f83454cd
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f83454cd61538b653656ccf81759b3cc7286ed67
Stats:     33 lines in 1 file changed: 19 ins; 2 del; 12 mod

8364786: Test java/net/vthread/HttpALot.java intermittently fails - 24999 handled, expected 25000

Reviewed-by: dfuchs, alanb, vyazici

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

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

From vyazici at openjdk.org  Sat Aug  9 09:19:11 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Sat, 9 Aug 2025 09:19:11 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v2]
In-Reply-To: <VbnzY-bfsCQ9LL8NPyUUsV5MzCKyRmkUuwdo9KllhG4=.fd72a940-e302-4b22-b4fc-c26f9f93389d@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <Cr7F97rkzkAAfC0pqMiI8IgMVPr7-mSOyrX2ocNHMUQ=.e8e5ce6b-f090-4181-ae67-11d7f3124700@github.com>
 <GFhyCQmZO3GS7VZM1iWHzmFyyonyczNC997YbSq6IA0=.fb64fcf0-f934-4a2a-9c60-d37cd906d67d@github.com>
 <VbnzY-bfsCQ9LL8NPyUUsV5MzCKyRmkUuwdo9KllhG4=.fd72a940-e302-4b22-b4fc-c26f9f93389d@github.com>
Message-ID: <woBZ0kFiXUbvKdKddVi6jBaQZKWqtZRwkjonFSvTOro=.754a6851-d4a3-4294-9d0e-2a96cee36936@github.com>

On Fri, 8 Aug 2025 17:17:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hello Volkan, is that warning generated by a IDE? I don't see it in IntelliJ:
>> 
>> <img width="704" height="192" alt="ide" src="https://github.com/user-attachments/assets/b45345a2-343a-49ea-ab82-47bd40e6b87d" />
>
> I think we usually put the jtreg directive block before the imports.

> Is that warning generated by a IDE? I don't see it in IntelliJ:

@jaikiran, I remember seeing it highlighted somewhere, but apparently I am mistaken. Nevermind. It is all good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26698#discussion_r2264622780

From jpai at openjdk.org  Sat Aug  9 12:07:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 9 Aug 2025 12:07:00 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v3]
In-Reply-To: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
Message-ID: <ZpPMfMjL6gj-GULeNKOSrpdvADsMRQB-BaYX77tzgTQ=.4ddaf66f-a296-40bf-b339-2e3c17498023@github.com>

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?
> 
> `java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.
> 
> The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.
> 
> I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.

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

  Chen's review - verify List.set() fails too

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26698/files
  - new: https://git.openjdk.org/jdk/pull/26698/files/7b92b0a6..f6ff8fa0

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

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

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

From jpai at openjdk.org  Sat Aug  9 12:07:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 9 Aug 2025 12:07:01 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v3]
In-Reply-To: <woBZ0kFiXUbvKdKddVi6jBaQZKWqtZRwkjonFSvTOro=.754a6851-d4a3-4294-9d0e-2a96cee36936@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <Cr7F97rkzkAAfC0pqMiI8IgMVPr7-mSOyrX2ocNHMUQ=.e8e5ce6b-f090-4181-ae67-11d7f3124700@github.com>
 <GFhyCQmZO3GS7VZM1iWHzmFyyonyczNC997YbSq6IA0=.fb64fcf0-f934-4a2a-9c60-d37cd906d67d@github.com>
 <VbnzY-bfsCQ9LL8NPyUUsV5MzCKyRmkUuwdo9KllhG4=.fd72a940-e302-4b22-b4fc-c26f9f93389d@github.com>
 <woBZ0kFiXUbvKdKddVi6jBaQZKWqtZRwkjonFSvTOro=.754a6851-d4a3-4294-9d0e-2a96cee36936@github.com>
Message-ID: <gJdi42BHTkz2okVYtN9NvCdxuyCMTvYHd5DKQamXFC0=.6a41ca6f-92f9-4675-9523-55e323d2deb9@github.com>

On Sat, 9 Aug 2025 09:16:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> I think we usually put the jtreg directive block before the imports.
>
>> Is that warning generated by a IDE? I don't see it in IntelliJ:
> 
> @jaikiran, I remember seeing it highlighted somewhere, but apparently I am mistaken. Nevermind. It is all good.

Hello Chen,

> I think we usually put the jtreg directive block before the imports.

It's a mix of before imports and above the class declaration in the JDK repo. I personally prefer just above the class since it's easily visible. Several of the tests in the networking area follow this currently.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26698#discussion_r2264684264

From jpai at openjdk.org  Sat Aug  9 12:07:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 9 Aug 2025 12:07:01 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v2]
In-Reply-To: <X8PGgJJzisRXKIoWPIS56FW1hB2hsjfbBFKUME0V2vw=.5c92593f-e7f5-4c43-b54a-d298e6b91d65@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <_5JgON9h8m_NG0bn0V2mSO0qGQRuHG4WeK4X-4tIGy0=.499d6c41-2043-4e0e-b546-43e04c07377a@github.com>
 <X8PGgJJzisRXKIoWPIS56FW1hB2hsjfbBFKUME0V2vw=.5c92593f-e7f5-4c43-b54a-d298e6b91d65@github.com>
Message-ID: <qfcYiSLocxiWaLfwSDqCx53oyAVazxXhknyeYFmQubk=.08b8c723-0441-46d7-bca5-e49c86d356e5@github.com>

On Fri, 8 Aug 2025 17:18:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Volkan's review - refactor assertions into a method
>
> test/jdk/java/net/CookieStoreTest.java line 107:
> 
>> 105:         // an element must fail
>> 106:         assertThrows(UnsupportedOperationException.class, () -> list.add(elementToAddOrRemove));
>> 107:         assertThrows(UnsupportedOperationException.class, () -> list.remove(elementToAddOrRemove));
> 
> I think trying `list.set` would be meaningful too, given `Arrays.asList` would pass these two tests but is actually mutable.

Done. I've updated the PR to include that additional check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26698#discussion_r2264683740

From swen at openjdk.org  Sat Aug  9 13:03:13 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 9 Aug 2025 13:03:13 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v7]
In-Reply-To: <-sb4AkUVzeIHUo_Aq30bpxunVrDgjEBseviicW_NHCo=.345046be-9fa2-4ca9-adc7-74800924783e@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <-sb4AkUVzeIHUo_Aq30bpxunVrDgjEBseviicW_NHCo=.345046be-9fa2-4ca9-adc7-74800924783e@github.com>
Message-ID: <YF_peW1FnQw4S6PccLilUtHw8i0tYRtiy3Fqun00Z6Q=.b6523457-db6d-40ae-ae5a-2baea10f1806@github.com>

On Tue, 5 Aug 2025 11:27:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert the last commit: faa5d24d831
>   
>   The `send()`-vs-`sendAsync()` discrepancy will be addressed separately.

src/java.net.http/share/classes/java/net/http/HttpRequest.java line 755:

> 753:          */
> 754:         public static BodyPublisher ofFileChannel(FileChannel channel, long offset, long length) throws IOException {
> 755:             Objects.requireNonNull(channel, "channel");

public FileChannelPublisher(FileChannel channel, long offset, long length) throws IOException {
            this.channel = Objects.requireNonNull(channel, "channel");
            // ...

The FileChannelPublisher constructor already has a null value check for the parameter channel, which is redundant

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2264700495

From swen at openjdk.org  Sat Aug  9 13:06:12 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 9 Aug 2025 13:06:12 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v7]
In-Reply-To: <-sb4AkUVzeIHUo_Aq30bpxunVrDgjEBseviicW_NHCo=.345046be-9fa2-4ca9-adc7-74800924783e@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <-sb4AkUVzeIHUo_Aq30bpxunVrDgjEBseviicW_NHCo=.345046be-9fa2-4ca9-adc7-74800924783e@github.com>
Message-ID: <DUILTpCU-z6q2hgVyS80iNQfz5-IIaLhfyeL2p-4e40=.41dc9020-350f-47c2-b6fe-eb959045b202@github.com>

On Tue, 5 Aug 2025 11:27:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert the last commit: faa5d24d831
>   
>   The `send()`-vs-`sendAsync()` discrepancy will be addressed separately.

src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java line 368:

> 366: 
> 367:     public static IllegalArgumentException newIAE(String message, Object... args) {
> 368:         return new IllegalArgumentException(format(message, args));

Suggestion:

        return new IllegalArgumentException(message.formatted(args));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2264701010

From swen at openjdk.org  Sat Aug  9 13:10:15 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 9 Aug 2025 13:10:15 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v7]
In-Reply-To: <-sb4AkUVzeIHUo_Aq30bpxunVrDgjEBseviicW_NHCo=.345046be-9fa2-4ca9-adc7-74800924783e@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <-sb4AkUVzeIHUo_Aq30bpxunVrDgjEBseviicW_NHCo=.345046be-9fa2-4ca9-adc7-74800924783e@github.com>
Message-ID: <pv7A3zwuvix5P9yKLBbbwNstHVsOsHyTxSxnffHkVag=.d2b62a8d-fdfd-4230-8623-7cfaddae77d3@github.com>

On Tue, 5 Aug 2025 11:27:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert the last commit: faa5d24d831
>   
>   The `send()`-vs-`sendAsync()` discrepancy will be addressed separately.

test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 105:

> 103:     private static final ServerRequestPair HTTP2 = ServerRequestPair.of(Version.HTTP_2, false);
> 104: 
> 105:     private static final ServerRequestPair HTTPS2 = ServerRequestPair.of(Version.HTTP_2, true);

Suggestion:

    private static final ServerRequestPair 
            HTTP1  = ServerRequestPair.of(Version.HTTP_1_1, false), 
            HTTPS1 = ServerRequestPair.of(Version.HTTP_1_1, true),
            HTTP2  = ServerRequestPair.of(Version.HTTP_2, false),
            HTTPS2 = ServerRequestPair.of(Version.HTTP_2, true);

This coding style can be considered for declaring multiple consecutive fields of the same type.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2264701902

From liach at openjdk.org  Sat Aug  9 13:13:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 9 Aug 2025 13:13:11 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v3]
In-Reply-To: <ZpPMfMjL6gj-GULeNKOSrpdvADsMRQB-BaYX77tzgTQ=.4ddaf66f-a296-40bf-b339-2e3c17498023@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <ZpPMfMjL6gj-GULeNKOSrpdvADsMRQB-BaYX77tzgTQ=.4ddaf66f-a296-40bf-b339-2e3c17498023@github.com>
Message-ID: <QuDJ57zfKor2PosrVzRlWOqZiNJyDYqOmiDJSgKTF_I=.67b8a46c-a9a3-464c-abfc-6de12f961265@github.com>

On Sat, 9 Aug 2025 12:07:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?
>> 
>> `java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.
>> 
>> The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.
>> 
>> I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen's review - verify List.set() fails too

Code alone looks good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26698#pullrequestreview-3102952053

From jpai at openjdk.org  Sun Aug 10 04:18:17 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 10 Aug 2025 04:18:17 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v2]
In-Reply-To: <-wQhKp-Z2OMwDYlop0KiJUIznsIX1Gr3xJRtURrzXX8=.3320e978-4cd2-4f99-9ec9-2f57076c8664@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <_5JgON9h8m_NG0bn0V2mSO0qGQRuHG4WeK4X-4tIGy0=.499d6c41-2043-4e0e-b546-43e04c07377a@github.com>
 <-wQhKp-Z2OMwDYlop0KiJUIznsIX1Gr3xJRtURrzXX8=.3320e978-4cd2-4f99-9ec9-2f57076c8664@github.com>
Message-ID: <htmBs7DL04WkUDOdmRqynXi-rvY8WHoJqLUZvNiNguY=.6a679df9-871a-45dc-ac79-5e80c1c8f8ed@github.com>

On Fri, 8 Aug 2025 14:47:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> It may be useful to plan a release note, in case an application is depending on being able to add/remove stuff to/from the returned list, despite the documentation stating they should be immutable. For instance - an application may attempt to clear() the returned list.

I've now marked the issue with `release-note=yes`. I'll create one shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/26698#issuecomment-3172353023

From jpai at openjdk.org  Sun Aug 10 04:22:15 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 10 Aug 2025 04:22:15 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v3]
In-Reply-To: <ZpPMfMjL6gj-GULeNKOSrpdvADsMRQB-BaYX77tzgTQ=.4ddaf66f-a296-40bf-b339-2e3c17498023@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <ZpPMfMjL6gj-GULeNKOSrpdvADsMRQB-BaYX77tzgTQ=.4ddaf66f-a296-40bf-b339-2e3c17498023@github.com>
Message-ID: <L9YlTNHP2tkVJDH8DOSt8BplyYjmS8MUb9nq4EzdGbg=.9c425e4b-3efc-4a4b-8f46-058e02086899@github.com>

On Sat, 9 Aug 2025 12:07:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?
>> 
>> `java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.
>> 
>> The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.
>> 
>> I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen's review - verify List.set() fails too

Thank you all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/26698#issuecomment-3172355060

From jpai at openjdk.org  Sun Aug 10 04:25:22 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 10 Aug 2025 04:25:22 GMT
Subject: Integrated: 8365086: CookieStore.getURIs() and get(URI) should return
 an immutable List
In-Reply-To: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
Message-ID: <a7pa2GOG9f1QU3zxKJ-zJejUidXPZRF8DPCezqUF1MM=.7f1c1251-d673-4e04-bac1-3ce31957dc72@github.com>

On Fri, 8 Aug 2025 13:28:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?
> 
> `java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.
> 
> The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.
> 
> I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.

This pull request has now been integrated.

Changeset: 022e29a7
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/022e29a77533aacabd56820d00ecffa9646a8362
Stats:     127 lines in 2 files changed: 119 ins; 4 del; 4 mod

8365086: CookieStore.getURIs() and get(URI) should return an immutable List

Reviewed-by: liach, vyazici, dfuchs

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

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

From vyazici at openjdk.org  Mon Aug 11 07:47:03 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 11 Aug 2025 07:47:03 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v8]
In-Reply-To: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
Message-ID: <rRmsqMqDtcwMpU52rkou98OEkEDQZGEIK1bFAVdBijA=.38b6db88-cf6c-4a35-904a-eb36dbf8e4c3@github.com>

> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
> 
>> The file channel will not be closed upon completion. The caller is
>> expected to manage the life cycle of the channel, and close it
>> appropriately when not needed anymore.
> 
> ### Implementation notes
> 
> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.

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

  Improve style for declaring multiple consecutive fields of the same type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26155/files
  - new: https://git.openjdk.org/jdk/pull/26155/files/c8a0257a..91d3422c

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

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

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

From vyazici at openjdk.org  Mon Aug 11 07:47:07 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 11 Aug 2025 07:47:07 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v7]
In-Reply-To: <YF_peW1FnQw4S6PccLilUtHw8i0tYRtiy3Fqun00Z6Q=.b6523457-db6d-40ae-ae5a-2baea10f1806@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <-sb4AkUVzeIHUo_Aq30bpxunVrDgjEBseviicW_NHCo=.345046be-9fa2-4ca9-adc7-74800924783e@github.com>
 <YF_peW1FnQw4S6PccLilUtHw8i0tYRtiy3Fqun00Z6Q=.b6523457-db6d-40ae-ae5a-2baea10f1806@github.com>
Message-ID: <umPS0ggHDeGzyR_h4AG11OCnJQ_Ps0Zkzuo2B8ss8NI=.7d837c92-e1ec-434a-befa-48241bf3535e@github.com>

On Sat, 9 Aug 2025 13:00:50 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert the last commit: faa5d24d831
>>   
>>   The `send()`-vs-`sendAsync()` discrepancy will be addressed separately.
>
> src/java.net.http/share/classes/java/net/http/HttpRequest.java line 755:
> 
>> 753:          */
>> 754:         public static BodyPublisher ofFileChannel(FileChannel channel, long offset, long length) throws IOException {
>> 755:             Objects.requireNonNull(channel, "channel");
> 
> public FileChannelPublisher(FileChannel channel, long offset, long length) throws IOException {
>             this.channel = Objects.requireNonNull(channel, "channel");
>             // ...
> 
> The FileChannelPublisher constructor already has a null value check for the parameter channel, which is redundant

We should raise an exception at the API boundary, hence this check. Why didn't I validate `offset` and `length` here too? Because doing so would expose implementation details in the interface. Why did I add an extra null check in `FCP::new`? That's also an API boundary, but an internal one. Naturally, these practices can vary depending on performance considerations.

> src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java line 368:
> 
>> 366: 
>> 367:     public static IllegalArgumentException newIAE(String message, Object... args) {
>> 368:         return new IllegalArgumentException(format(message, args));
> 
> Suggestion:
> 
>         return new IllegalArgumentException(message.formatted(args));

While I agree with your reasoning, it is out of the scope of this work.

For the record, I really like `String::formatted`! Yet one should try to avoid it if the associated changes might need to be backported. ?

> test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 105:
> 
>> 103:     private static final ServerRequestPair HTTP2 = ServerRequestPair.of(Version.HTTP_2, false);
>> 104: 
>> 105:     private static final ServerRequestPair HTTPS2 = ServerRequestPair.of(Version.HTTP_2, true);
> 
> Suggestion:
> 
>     private static final ServerRequestPair 
>             HTTP1  = ServerRequestPair.of(Version.HTTP_1_1, false), 
>             HTTPS1 = ServerRequestPair.of(Version.HTTP_1_1, true),
>             HTTP2  = ServerRequestPair.of(Version.HTTP_2, false),
>             HTTPS2 = ServerRequestPair.of(Version.HTTP_2, true);
> 
> This coding style can be considered for declaring multiple consecutive fields of the same type.

Applied in 91d3422. (Did not commit your suggestion due to the _"vertical alignment"_ you employed in the variable names. It is impossible to adhere to in the long run, see `vmIntrinsics.hpp` for an example.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2265922312
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2265925853
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2265925993

From dclarke at openjdk.org  Mon Aug 11 12:00:28 2025
From: dclarke at openjdk.org (Darragh Clarke)
Date: Mon, 11 Aug 2025 12:00:28 GMT
Subject: Integrated: 8352502: Response message is null if expect 100 assertion
 fails with non 100
In-Reply-To: <Wdwcz-OrrHA0ZkTpjFSZ4e7ThgwHIEtaousm-NYbRVQ=.d170fc75-0dbf-404b-b59b-85ad52b56ca4@github.com>
References: <Wdwcz-OrrHA0ZkTpjFSZ4e7ThgwHIEtaousm-NYbRVQ=.d170fc75-0dbf-404b-b59b-85ad52b56ca4@github.com>
Message-ID: <KqVh71p4CIDSuQtRizKMWpwVy7EbPFUzEl0uqLa0xuM=.36f1fd2c-0313-467a-b445-ac2463952e9e@github.com>

On Thu, 26 Jun 2025 10:48:56 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> Currently if a request has set Expect-Continue and receives a non 100 response the `responseMessage` wouldn't be set.
> 
> This PR sets `responseMessage`, it also updates `getResponseMessage` to check if the message has already been set. This should match the way that `responseCode` is currently handled.
> 
> I also added a test to cover some possible responses.

This pull request has now been integrated.

Changeset: 43cfd80c
Author:    Darragh Clarke <dclarke at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43cfd80c1c0493f2f50ffd75461ca75a002e0127
Stats:     205 lines in 3 files changed: 205 ins; 0 del; 0 mod

8352502: Response message is null if expect 100 assertion fails with non 100

Reviewed-by: dfuchs

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

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

From myankelevich at openjdk.org  Mon Aug 11 15:45:17 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 11 Aug 2025 15:45:17 GMT
Subject: RFR: 8249824:
 s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o
 bugid [v5]
In-Reply-To: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
References: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
Message-ID: <aeHaJTVJlvrY6CCK0qfFSFxaq_nBa0N97mX497y7azk=.9c2ab6bc-e9d8-4de9-8dba-1ff272ccae81@github.com>

> * fully automated the test
> * removed the race condition
> * client on a thread and server on a thread options are now run together automatically

Mikhail Yankelevich 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 'master' into JDK-8249824
 - cleanup and update of the code to the current style
 - minor comment changes
 - Apply suggestions from cr
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
 - JDK-8249824: s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o bugid
   
   * fully automated the test
   * removed the race condition
   * client on a thread and server on a thread options are now run together automatically

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23469/files
  - new: https://git.openjdk.org/jdk/pull/23469/files/2bff4a34..ad0e7f3b

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

  Stats: 792793 lines in 10957 files changed: 358230 ins; 363171 del; 71392 mod
  Patch: https://git.openjdk.org/jdk/pull/23469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23469/head:pull/23469

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

From duke at openjdk.org  Tue Aug 12 03:09:22 2025
From: duke at openjdk.org (jwilliams990)
Date: Tue, 12 Aug 2025 03:09:22 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
Message-ID: <dvC1yoBB4BGOI_mkI1HUChns0zahMyaB0--ZAUzT3vw=.f96e9628-e9c5-4409-ba40-8742e2007b43@github.com>

On Mon, 16 Jun 2025 09:44:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.
>> 
>> As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.
>> 
>> The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.
>> 
>> A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - include a test for AsynchronousServerSocketChannel
>  - System.err instead of System.out
>  - trim down code comment
>  -  > 200 instead of >= 200

Hi, Which version of OpenJDK is this change available in? I am running into a situation where Java on Windows drops TCP/HTTP connections, but i don't have this issue on Linux (I have tested with JDK 21.0.8+9).

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

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-3177373009

From jpai at openjdk.org  Tue Aug 12 03:52:18 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 12 Aug 2025 03:52:18 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <dvC1yoBB4BGOI_mkI1HUChns0zahMyaB0--ZAUzT3vw=.f96e9628-e9c5-4409-ba40-8742e2007b43@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
 <dvC1yoBB4BGOI_mkI1HUChns0zahMyaB0--ZAUzT3vw=.f96e9628-e9c5-4409-ba40-8742e2007b43@github.com>
Message-ID: <AZS4tsFgRD447rNUfoGNz45BJbXeEnvUWNxEFzxsTi0=.0f6d5066-8409-4fd8-928c-d9ff25bd015f@github.com>

On Tue, 12 Aug 2025 01:13:57 GMT, jwilliams990 <duke at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - include a test for AsynchronousServerSocketChannel
>>  - System.err instead of System.out
>>  - trim down code comment
>>  -  > 200 instead of >= 200
>
> Hi, Which version of OpenJDK is this change available in? I am running into a situation where Java on Windows drops TCP/HTTP connections, but i don't have this issue on Linux (I have tested with JDK 21.0.8+9).

Hello @jwilliams990 

> Hi, Which version of OpenJDK is this change available in?

This change is currently in the unreleased Java 26 version. It's only available in 26 early access builds https://jdk.java.net/26/ or one has to manually build this JDK repo to use this feature. 

> I am running into a situation where Java on Windows drops TCP/HTTP connections, but i don't have this issue on Linux (I have tested with JDK 21.0.8+9).

Linux too has a limit on the number of backlog connections. I don't know the details of the issue you are running into but it could be unrelated to trying to use a backlog value greater than 200 on Windows, when creating a `ServerSocket`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-3177598778

From duke at openjdk.org  Tue Aug 12 03:59:24 2025
From: duke at openjdk.org (jwilliams990)
Date: Tue, 12 Aug 2025 03:59:24 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <AZS4tsFgRD447rNUfoGNz45BJbXeEnvUWNxEFzxsTi0=.0f6d5066-8409-4fd8-928c-d9ff25bd015f@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
 <dvC1yoBB4BGOI_mkI1HUChns0zahMyaB0--ZAUzT3vw=.f96e9628-e9c5-4409-ba40-8742e2007b43@github.com>
 <AZS4tsFgRD447rNUfoGNz45BJbXeEnvUWNxEFzxsTi0=.0f6d5066-8409-4fd8-928c-d9ff25bd015f@github.com>
Message-ID: <DYkbYAMHfryi3IeoXOSWR6qOc44I8XtFQE-jPvZBc-4=.64ede2db-a757-4d32-bbf1-76a3ee574ce3@github.com>

On Tue, 12 Aug 2025 03:49:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi, Which version of OpenJDK is this change available in? I am running into a situation where Java on Windows drops TCP/HTTP connections, but i don't have this issue on Linux (I have tested with JDK 21.0.8+9).
>
> Hello @jwilliams990 
> 
>> Hi, Which version of OpenJDK is this change available in?
> 
> This change is currently in the unreleased Java 26 version. It's only available in 26 early access builds https://jdk.java.net/26/ or one has to manually build this JDK repo to use this feature. 
> 
>> I am running into a situation where Java on Windows drops TCP/HTTP connections, but i don't have this issue on Linux (I have tested with JDK 21.0.8+9).
> 
> Linux too has a limit on the number of backlog connections. I don't know the details of the issue you are running into but it could be unrelated to trying to use a backlog value greater than 200 on Windows, when creating a `ServerSocket`.

Hi @jaikiran, Thanks for your response. Any chance this could be included in Java 21 LTS in the future? 

The default TCP backlog in Windows is 200. Linux has a default of 4096. The issue i am seeing is when running Apache Tomcat on Windows vs. Linux, Windows shows a very high percentage of connection refused errors vs. Linux.

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

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-3177608798

From jpai at openjdk.org  Tue Aug 12 04:27:16 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 12 Aug 2025 04:27:16 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <AZS4tsFgRD447rNUfoGNz45BJbXeEnvUWNxEFzxsTi0=.0f6d5066-8409-4fd8-928c-d9ff25bd015f@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
 <dvC1yoBB4BGOI_mkI1HUChns0zahMyaB0--ZAUzT3vw=.f96e9628-e9c5-4409-ba40-8742e2007b43@github.com>
 <AZS4tsFgRD447rNUfoGNz45BJbXeEnvUWNxEFzxsTi0=.0f6d5066-8409-4fd8-928c-d9ff25bd015f@github.com>
Message-ID: <KSv6nlwpBobDAmHtjePHjQZ76cy1A4eOVb6aiThRYoQ=.d19ce3f6-3303-4cc8-a5e7-f590891bb44e@github.com>

On Tue, 12 Aug 2025 03:49:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi, Which version of OpenJDK is this change available in? I am running into a situation where Java on Windows drops TCP/HTTP connections, but i don't have this issue on Linux (I have tested with JDK 21.0.8+9).
>
> Hello @jwilliams990 
> 
>> Hi, Which version of OpenJDK is this change available in?
> 
> This change is currently in the unreleased Java 26 version. It's only available in 26 early access builds https://jdk.java.net/26/ or one has to manually build this JDK repo to use this feature. 
> 
>> I am running into a situation where Java on Windows drops TCP/HTTP connections, but i don't have this issue on Linux (I have tested with JDK 21.0.8+9).
> 
> Linux too has a limit on the number of backlog connections. I don't know the details of the issue you are running into but it could be unrelated to trying to use a backlog value greater than 200 on Windows, when creating a `ServerSocket`.

> Hi @jaikiran, Thanks for your response. Any chance this could be included in Java 21 LTS in the future?

Backports to OpenJDK are managed by a separate "jdk-updates" project https://openjdk.org/projects/jdk-updates/. Members of that project decide which changes should be backported (and when).

For this specific change, Java 26 release isn't scheduled for this year. Once it is released and after that version sees usage in real world applications, only then enhancements like these are usually considered for backports. So it's too early to say if/when this change will be backported.

In the meantime, what would be good is if you suspect that the backlog limit is indeed causing this issue on your setup, you could try to use the 26 early access build which is available here https://jdk.java.net/26/ and see if that helps you get past this issue. Are you creating a ServerSocket (or some other construct?) with some explicit value for backlog that is greater than 200?

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

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-3177649481

From duke at openjdk.org  Tue Aug 12 04:33:16 2025
From: duke at openjdk.org (jwilliams990)
Date: Tue, 12 Aug 2025 04:33:16 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <KSv6nlwpBobDAmHtjePHjQZ76cy1A4eOVb6aiThRYoQ=.d19ce3f6-3303-4cc8-a5e7-f590891bb44e@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
 <dvC1yoBB4BGOI_mkI1HUChns0zahMyaB0--ZAUzT3vw=.f96e9628-e9c5-4409-ba40-8742e2007b43@github.com>
 <AZS4tsFgRD447rNUfoGNz45BJbXeEnvUWNxEFzxsTi0=.0f6d5066-8409-4fd8-928c-d9ff25bd015f@github.com>
 <KSv6nlwpBobDAmHtjePHjQZ76cy1A4eOVb6aiThRYoQ=.d19ce3f6-3303-4cc8-a5e7-f590891bb44e@github.com>
Message-ID: <Ft4ycpQmPofFhAHzt_Jz1JtHNqQ1heFJoEcdxMTLfV8=.ca558ed0-26fe-494c-b2fd-39f414e1161c@github.com>

On Tue, 12 Aug 2025 04:24:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello @jwilliams990 
>> 
>>> Hi, Which version of OpenJDK is this change available in?
>> 
>> This change is currently in the unreleased Java 26 version. It's only available in 26 early access builds https://jdk.java.net/26/ or one has to manually build this JDK repo to use this feature. 
>> 
>>> I am running into a situation where Java on Windows drops TCP/HTTP connections, but i don't have this issue on Linux (I have tested with JDK 21.0.8+9).
>> 
>> Linux too has a limit on the number of backlog connections. I don't know the details of the issue you are running into but it could be unrelated to trying to use a backlog value greater than 200 on Windows, when creating a `ServerSocket`.
>
>> Hi @jaikiran, Thanks for your response. Any chance this could be included in Java 21 LTS in the future?
> 
> Backports to OpenJDK are managed by a separate "jdk-updates" project https://openjdk.org/projects/jdk-updates/. Members of that project decide which changes should be backported (and when).
> 
> For this specific change, Java 26 release isn't scheduled for this year. Once it is released and after that version sees usage in real world applications, only then enhancements like these are usually considered for backports. So it's too early to say if/when this change will be backported.
> 
> In the meantime, what would be good is if you suspect that the backlog limit is indeed causing this issue on your setup, you could try to use the 26 early access build which is available here https://jdk.java.net/26/ and see if that helps you get past this issue. Are you creating a ServerSocket (or some other construct?) with some explicit value for backlog that is greater than 200?

Hi @jaikiran, I am running Apache Tomcat on Java. Tomcat has an acceptCount set to a large number (greater than 200). I believe Tomcat creates a ServerSocket with the configured acceptCount, and I suspect that it is not effective on Windows for the reasons mentioned above in this trail.

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

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-3177657942

From jpai at openjdk.org  Tue Aug 12 04:45:16 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 12 Aug 2025 04:45:16 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <KSv6nlwpBobDAmHtjePHjQZ76cy1A4eOVb6aiThRYoQ=.d19ce3f6-3303-4cc8-a5e7-f590891bb44e@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
 <dvC1yoBB4BGOI_mkI1HUChns0zahMyaB0--ZAUzT3vw=.f96e9628-e9c5-4409-ba40-8742e2007b43@github.com>
 <AZS4tsFgRD447rNUfoGNz45BJbXeEnvUWNxEFzxsTi0=.0f6d5066-8409-4fd8-928c-d9ff25bd015f@github.com>
 <KSv6nlwpBobDAmHtjePHjQZ76cy1A4eOVb6aiThRYoQ=.d19ce3f6-3303-4cc8-a5e7-f590891bb44e@github.com>
Message-ID: <r8MGdbeP-bXkjYUbj2l5MVBqjL_N8FAZrS2LKlTbqBI=.d3145098-81b1-4586-a26c-065a87368442@github.com>

On Tue, 12 Aug 2025 04:24:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello @jwilliams990 
>> 
>>> Hi, Which version of OpenJDK is this change available in?
>> 
>> This change is currently in the unreleased Java 26 version. It's only available in 26 early access builds https://jdk.java.net/26/ or one has to manually build this JDK repo to use this feature. 
>> 
>>> I am running into a situation where Java on Windows drops TCP/HTTP connections, but i don't have this issue on Linux (I have tested with JDK 21.0.8+9).
>> 
>> Linux too has a limit on the number of backlog connections. I don't know the details of the issue you are running into but it could be unrelated to trying to use a backlog value greater than 200 on Windows, when creating a `ServerSocket`.
>
>> Hi @jaikiran, Thanks for your response. Any chance this could be included in Java 21 LTS in the future?
> 
> Backports to OpenJDK are managed by a separate "jdk-updates" project https://openjdk.org/projects/jdk-updates/. Members of that project decide which changes should be backported (and when).
> 
> For this specific change, Java 26 release isn't scheduled for this year. Once it is released and after that version sees usage in real world applications, only then enhancements like these are usually considered for backports. So it's too early to say if/when this change will be backported.
> 
> In the meantime, what would be good is if you suspect that the backlog limit is indeed causing this issue on your setup, you could try to use the 26 early access build which is available here https://jdk.java.net/26/ and see if that helps you get past this issue. Are you creating a ServerSocket (or some other construct?) with some explicit value for backlog that is greater than 200?

> Hi @jaikiran, I am running Apache Tomcat on Java. Tomcat has an acceptCount set to a large number (greater than 200). I believe Tomcat creates a ServerSocket with the configured acceptCount, and I suspect that it is not effective on Windows for the reasons mentioned above in this trail.

Thank you for that detail, that's useful to know. Based on what you note and what's documented of that Connector attribute in Tomcat docs - https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#Attributes_Standard%20Implementation_acceptCount, I think what you are suggesting is correct - the backlog might be playing a role here.

If you get a chance to try this with Java 26 early access build, that would be a good experiment to verify that this change does indeed help this use case (I'll be curious to hear how that test goes).

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

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-3177673220

From vyazici at openjdk.org  Tue Aug 12 08:51:25 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 12 Aug 2025 08:51:25 GMT
Subject: RFR: 8249824:
 s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o
 bugid [v5]
In-Reply-To: <aeHaJTVJlvrY6CCK0qfFSFxaq_nBa0N97mX497y7azk=.9c2ab6bc-e9d8-4de9-8dba-1ff272ccae81@github.com>
References: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
 <aeHaJTVJlvrY6CCK0qfFSFxaq_nBa0N97mX497y7azk=.9c2ab6bc-e9d8-4de9-8dba-1ff272ccae81@github.com>
Message-ID: <gn8O8KFqnSncx5RR95m6kT1a-5zUO1_E_kRDFLdnOKE=.9ca84ed4-484e-4dd7-a69d-9c05f21dd8ed@github.com>

On Mon, 11 Aug 2025 15:45:17 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * fully automated the test
>> * removed the race condition
>> * client on a thread and server on a thread options are now run together automatically
>
> Mikhail Yankelevich 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 'master' into JDK-8249824
>  - cleanup and update of the code to the current style
>  - minor comment changes
>  - Apply suggestions from cr
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>  - JDK-8249824: s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o bugid
>    
>    * fully automated the test
>    * removed the race condition
>    * client on a thread and server on a thread options are now run together automatically

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 32:

> 30:  *
> 31:  * @run main/othervm -Dtest.separateThreads=true CloseKeepAliveCached false
> 32:  * @run main/othervm -Dtest.separateThreads=true CloseKeepAliveCached true

If `test.separateThreads` is always `true`, can we remove this property completely?

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 106:

> 104:          */
> 105:         serverReady = true;
> 106:         SSLSocket sslSocket = (SSLSocket) sslServerSocket.accept();

One can say it is a matter of preference, but wrapping all `AutoCloseable`'s (`SSLServerSocket`, `SSLSocket`, `InputStream`, etc.) in a try-with-resources will help with ensuring all resources are correctly closed.

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 120:

> 118:             String x;
> 119:             while ((x = r.readLine()) != null) {
> 120:                 if (x.isEmpty()) {

I guess this can be simplified to `while ((x = r.readLine()) != null && !x.isEmpty())`.

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 135:

> 133:             out.flush();
> 134: 
> 135:             Thread.sleep(50);

Curious: Why do we need this?

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 164:

> 162:             HttpsURLConnection.setDefaultHostnameVerifier(new NameVerifier());
> 163:             http = (HttpsURLConnection) url.openConnection();
> 164:             InputStream is = http.getInputStream();

See my comment above regarding `InputStream` and try-with-resources.

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 316:

> 314:     void startServer(boolean newThread) throws Exception {
> 315:         if (newThread) {
> 316:             serverThread = new Thread(() -> {

Nit: Unsolicited style changes can obstruct backporting and decrease version control hygiene. (This comment applies to changes starting from line 338 too.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2269086136
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2269093354
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2269096196
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2269097406
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2269113381
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2269149826

From duke at openjdk.org  Tue Aug 12 15:29:22 2025
From: duke at openjdk.org (jwilliams990)
Date: Tue, 12 Aug 2025 15:29:22 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <r8MGdbeP-bXkjYUbj2l5MVBqjL_N8FAZrS2LKlTbqBI=.d3145098-81b1-4586-a26c-065a87368442@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
 <dvC1yoBB4BGOI_mkI1HUChns0zahMyaB0--ZAUzT3vw=.f96e9628-e9c5-4409-ba40-8742e2007b43@github.com>
 <AZS4tsFgRD447rNUfoGNz45BJbXeEnvUWNxEFzxsTi0=.0f6d5066-8409-4fd8-928c-d9ff25bd015f@github.com>
 <KSv6nlwpBobDAmHtjePHjQZ76cy1A4eOVb6aiThRYoQ=.d19ce3f6-3303-4cc8-a5e7-f590891bb44e@github.com>
 <r8MGdbeP-bXkjYUbj2l5MVBqjL_N8FAZrS2LKlTbqBI=.d3145098-81b1-4586-a26c-065a87368442@github.com>
Message-ID: <_AytxIFrh0G0z7OHW1VfdBLoSvh6N-38vamSjR-GJRM=.7bbebcae-28a0-4caf-9e22-e0d7ba2b443b@github.com>

On Tue, 12 Aug 2025 04:41:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> Hi @jaikiran, Thanks for your response. Any chance this could be included in Java 21 LTS in the future?
>> 
>> Backports to OpenJDK are managed by a separate "jdk-updates" project https://openjdk.org/projects/jdk-updates/. Members of that project decide which changes should be backported (and when).
>> 
>> For this specific change, Java 26 release isn't scheduled for this year. Once it is released and after that version sees usage in real world applications, only then enhancements like these are usually considered for backports. So it's too early to say if/when this change will be backported.
>> 
>> In the meantime, what would be good is if you suspect that the backlog limit is indeed causing this issue on your setup, you could try to use the 26 early access build which is available here https://jdk.java.net/26/ and see if that helps you get past this issue. Are you creating a ServerSocket (or some other construct?) with some explicit value for backlog that is greater than 200?
>
>> Hi @jaikiran, I am running Apache Tomcat on Java. Tomcat has an acceptCount set to a large number (greater than 200). I believe Tomcat creates a ServerSocket with the configured acceptCount, and I suspect that it is not effective on Windows for the reasons mentioned above in this trail.
> 
> Thank you for that detail, that's useful to know. Based on what you note and what's documented of that Connector attribute in Tomcat docs - https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#Attributes_Standard%20Implementation_acceptCount, I think what you are suggesting is correct - the backlog might be playing a role here.
> 
> If you get a chance to try this with Java 26 early access build, that would be a good experiment to verify that this change does indeed help this use case (I'll be curious to hear how that test goes).

Hi @jaikiran - I have tested with the Java 26 early access build and can report that the issue i faced on Windows OS with TCP/HTTP connection refused errors even at relatively low concurrency has been resolved in this build. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-3179832921

From jpai at openjdk.org  Tue Aug 12 15:38:24 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 12 Aug 2025 15:38:24 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
Message-ID: <azFWNc1DtZlf8oZBzEiavOHQmiyoDnr5Zs_PA8RaaGk=.4c8b9f33-805e-4889-ba3b-29f4bf19c9f4@github.com>

On Mon, 16 Jun 2025 09:44:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.
>> 
>> As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.
>> 
>> The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.
>> 
>> A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - include a test for AsynchronousServerSocketChannel
>  - System.err instead of System.out
>  - trim down code comment
>  -  > 200 instead of >= 200

Thank you very much for running the test and reporting back. It's pleasing to hear that this enhancement addresses a genuine issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-3179884608

From lkorinth at openjdk.org  Tue Aug 12 17:09:32 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 12 Aug 2025 17:09:32 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
Message-ID: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>

This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)

In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).

My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.

These fixes have been created when I have ploughed through test cases:
JDK-8352719: Add an equals sign to the modules statement
JDK-8352709: Remove bad timing annotations from WhileOpTest.java
JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
CODETOOLS-7903961: Make default timeout configurable

After the review, I will update the copyrights.

I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.

I got 4 timing related faults:
1) runtime/Thread/TestThreadDumpMonitorContention.java
   This is probably: https://bugs.openjdk.org/browse/JDK-8361370
2) sun/tools/jhsdb/BasicLauncherTest.java
   I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
3) gc/stress/TestReclaimStringsLeaksMemory.java
   I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
4) sun/security/ssl/X509KeyManager/CertChecking.java
   This is a new test that I got on last rebase. I have added a timeout of 480 to it.

In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.

>From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of default timeout factor", I have taken a few actions:
1) in testing(md|html): interpreted mode -> forced compilation mode
2) in MTTest.java: changed 1200 -> 400 (was 300 to begin with)

I am now re-running tier 1-8.

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

Commit messages:
 - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1

Changes: https://git.openjdk.org/jdk/pull/26749/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8260555
  Stats: 598 lines in 297 files changed: 49 ins; 91 del; 458 mod
  Patch: https://git.openjdk.org/jdk/pull/26749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749

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

From cjplummer at openjdk.org  Tue Aug 12 17:54:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 12 Aug 2025 17:54:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> sun/tools/jhsdb/BasicLauncherTest.java
> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.

@lkorinth Can you send me a link to the failure?

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3180396310

From syan at openjdk.org  Wed Aug 13 01:50:14 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 13 Aug 2025 01:50:14 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

test/hotspot/jtreg/compiler/c1/TestPinnedIntrinsics.java line 25:

> 23: 
> 24: /*
> 25:  * @test

Should we need to update the copyright year for the touch files

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2271883564

From syan at openjdk.org  Wed Aug 13 01:54:16 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 13 Aug 2025 01:54:16 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29:

> 27:  * @requires vm.debug
> 28:  * @summary Test running with StressRecompilation enabled.
> 29:  * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRecompilation

I think the default value(120s) will be enough? On my machine this test use 11.546 senonds to finish.


> grep "elapsed time" tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn
55:elapsed time (seconds): 0.581
66:elapsed time (seconds): 0.575
116:elapsed time (seconds): 3.088
162:elapsed time (seconds): 0.001
173:elapsed time (seconds): 11.546

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2271888024

From sspitsyn at openjdk.org  Wed Aug 13 07:29:11 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Aug 2025 07:29:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

I've reviewed the Serviceability related tweaks and I'm okay with them in general.
But I'm curious if you do not see any timeouts with this anymore.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3114280042

From aturbanov at openjdk.org  Wed Aug 13 09:47:17 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 13 Aug 2025 09:47:17 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

test/langtools/tools/lib/toolbox/ToolBox.java line 480:

> 478: 
> 479:     private static final int RETRY_DELETE_MILLIS = isWindows() ? 500 : 0;
> 480:     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ?  60 * 1000 : 0;

Suggestion:

    private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2272745651

From lkorinth at openjdk.org  Wed Aug 13 13:09:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:09:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>
Message-ID: <RA6T2Udma4QM1EdTUlZ9Y4l6Wo1783yEKYgOPy8UOZY=.7938ce78-45a5-4607-9298-72cf19436662@github.com>

On Wed, 13 Aug 2025 01:47:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> test/hotspot/jtreg/compiler/c1/TestPinnedIntrinsics.java line 25:
> 
>> 23: 
>> 24: /*
>> 25:  * @test
> 
> Should we need to update the copyright year for the touched files

`After the review, I will update the copyrights.`

It is IMO easier to review big changes without the noise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273410872

From lkorinth at openjdk.org  Wed Aug 13 13:21:11 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:21:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>
Message-ID: <4q0047gChugbkkv-W0lis2E8nXVWh8YGVJiBehoojLY=.0b9055a2-f038-4247-82a9-7c60ee9f6637@github.com>

On Tue, 12 Aug 2025 17:52:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > sun/tools/jhsdb/BasicLauncherTest.java
> > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 
> @lkorinth Can you send me a link to the failure?

I sent it to you on email.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3183896453

From erikj at openjdk.org  Wed Aug 13 13:28:18 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 13 Aug 2025 13:28:18 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

make/RunTests.gmk line 939:

> 937: 
> 938:   JTREG_AUTO_PROBLEM_LISTS :=
> 939:   JTREG_AUTO_TIMEOUT_FACTOR := 1 # IT MAKES NO SENCE TO CHANGE IT. Fix individual test cases that time out instead.

I'm not sure about this comment, but if we keep it, please move it to the line above and break lines as appropriate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273468852

From lkorinth at openjdk.org  Wed Aug 13 13:36:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:36:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>
Message-ID: <jX2ocV7Rf3mYq7TYfPkxKQfgucnVdhEDYMB91LwhTtI=.8810fb03-295c-4be5-9771-d7e031390002@github.com>

On Wed, 13 Aug 2025 01:51:44 GMT, SendaoYan <syan at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29:
> 
>> 27:  * @requires vm.debug
>> 28:  * @summary Test running with StressRecompilation enabled.
>> 29:  * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRecompilation
> 
> I think the default value(120s) will be enough? On my machine this test use 11.546 senonds to finish.
> 
> 
>> grep "elapsed time" tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn
> 55:elapsed time (seconds): 0.581
> 66:elapsed time (seconds): 0.575
> 116:elapsed time (seconds): 3.088
> 162:elapsed time (seconds): 0.001
> 173:elapsed time (seconds): 11.546

I have only (to my knowledge) updated test cases that has timed out for me. We have some not very modern test machines that is slower. That in combination with a debug build, in combination with a timeout factor of 0.7 might have made the test time out. Unfortunately I no longer have the logs for this failure so I can not check if the machine was failing because it was low on memory etc. I still think it is reasonable to keep the old timeout of 480. I have no intuitive feeling for how expensive `-XX:+StressRecompilation` is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273488236

From lkorinth at openjdk.org  Wed Aug 13 13:53:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:53:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>
Message-ID: <5nc1SBXnwAOJJvnrbMyPIsre61u--GxMHSffdDf8qUU=.77100025-4b9e-4e0a-b71d-df590df5f9ba@github.com>

On Wed, 13 Aug 2025 07:26:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> I've reviewed the Serviceability related tweaks and I'm okay with them in general. But I'm curious if you do not see any timeouts with this anymore.

I only got the four timeouts described in the description, I got a few other failures as well that was not timeout related. I sent you a link to the test results in an email.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3184026177

From lkorinth at openjdk.org  Wed Aug 13 14:22:08 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:08 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

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

  After suggestions from Erik and Andrey

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/ac47dbdc..dbe42964

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

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

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

From lkorinth at openjdk.org  Wed Aug 13 14:22:10 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:10 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>
Message-ID: <imd2i-VIlFCbEytLUZDyy_1SEU8ebK39Eif8JbdQsTU=.fefa1e8d-027b-445d-be69-07f6c6a475fd@github.com>

On Wed, 13 Aug 2025 13:25:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After suggestions from Erik and Andrey
>
> make/RunTests.gmk line 939:
> 
>> 937: 
>> 938:   JTREG_AUTO_PROBLEM_LISTS :=
>> 939:   JTREG_AUTO_TIMEOUT_FACTOR := 1 # IT MAKES NO SENCE TO CHANGE IT. Fix individual test cases that time out instead.
> 
> I'm not sure about this comment, but if we keep it, please move it to the line above and break lines as appropriate.

I updated it to "Please reach consensus before changing this. It was not easy changing it to a `1`. " I also did not break the comment as it was shorter than line 933 above it. Is it acceptable now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273621868

From lkorinth at openjdk.org  Wed Aug 13 14:22:11 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>
Message-ID: <KRJUnB026z2YmEljJJCHz5JEklLTO2LJfpMvwvt6-5k=.8388ace4-c445-4fdc-a71d-dff5a53cbeb6@github.com>

On Wed, 13 Aug 2025 09:44:33 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After suggestions from Erik and Andrey
>
> test/langtools/tools/lib/toolbox/ToolBox.java line 480:
> 
>> 478: 
>> 479:     private static final int RETRY_DELETE_MILLIS = isWindows() ? 500 : 0;
>> 480:     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ?  60 * 1000 : 0;
> 
> Suggestion:
> 
>     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0;

Fixed!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273614076

From myankelevich at openjdk.org  Thu Aug 14 12:14:48 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 14 Aug 2025 12:14:48 GMT
Subject: RFR: 8249824:
 s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o
 bugid [v6]
In-Reply-To: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
References: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
Message-ID: <iWeGtVvsrO8_8f-cTWXKp1sNTNh2ZyoaEewCeAlLFDA=.1d320ee2-e7ce-418c-bbfd-ee7e79676b6a@github.com>

> * fully automated the test
> * removed the race condition
> * client on a thread and server on a thread options are now run together automatically

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

  addressing comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23469/files
  - new: https://git.openjdk.org/jdk/pull/23469/files/ad0e7f3b..cfc0d7f6

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

  Stats: 75 lines in 1 file changed: 33 ins; 16 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/23469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23469/head:pull/23469

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

From myankelevich at openjdk.org  Thu Aug 14 12:14:58 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Thu, 14 Aug 2025 12:14:58 GMT
Subject: RFR: 8249824:
 s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o
 bugid [v5]
In-Reply-To: <gn8O8KFqnSncx5RR95m6kT1a-5zUO1_E_kRDFLdnOKE=.9ca84ed4-484e-4dd7-a69d-9c05f21dd8ed@github.com>
References: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
 <aeHaJTVJlvrY6CCK0qfFSFxaq_nBa0N97mX497y7azk=.9c2ab6bc-e9d8-4de9-8dba-1ff272ccae81@github.com>
 <gn8O8KFqnSncx5RR95m6kT1a-5zUO1_E_kRDFLdnOKE=.9ca84ed4-484e-4dd7-a69d-9c05f21dd8ed@github.com>
Message-ID: <k3Brdixzt1uDGCM-fb_8RfODNojeF1oXqcGHdKlcWLw=.683a75aa-e845-4cc2-a9e1-bc53f9e5311f@github.com>

On Tue, 12 Aug 2025 08:22:48 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Mikhail Yankelevich 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 'master' into JDK-8249824
>>  - cleanup and update of the code to the current style
>>  - minor comment changes
>>  - Apply suggestions from cr
>>    
>>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>>  - JDK-8249824: s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o bugid
>>    
>>    * fully automated the test
>>    * removed the race condition
>>    * client on a thread and server on a thread options are now run together automatically
>
> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 32:
> 
>> 30:  *
>> 31:  * @run main/othervm -Dtest.separateThreads=true CloseKeepAliveCached false
>> 32:  * @run main/othervm -Dtest.separateThreads=true CloseKeepAliveCached true
> 
> If `test.separateThreads` is always `true`, can we remove this property completely?

The initial manual test was testing both but manually. I have added another `@Test` with the `separeteThreads=false`. This way all combinations of client and server are covered as intended by initial test. 
Thank you for bringing my attention to this!

> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 106:
> 
>> 104:          */
>> 105:         serverReady = true;
>> 106:         SSLSocket sslSocket = (SSLSocket) sslServerSocket.accept();
> 
> One can say it is a matter of preference, but wrapping all `AutoCloseable`'s (`SSLServerSocket`, `SSLSocket`, `InputStream`, etc.) in a try-with-resources will help with ensuring all resources are correctly closed.

Done in next commit

> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 120:
> 
>> 118:             String x;
>> 119:             while ((x = r.readLine()) != null) {
>> 120:                 if (x.isEmpty()) {
> 
> I guess this can be simplified to `while ((x = r.readLine()) != null && !x.isEmpty())`.

I believe this is harder to read at a glance than the current expression, so I'd prefer to keep it

> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 135:
> 
>> 133:             out.flush();
>> 134: 
>> 135:             Thread.sleep(50);
> 
> Curious: Why do we need this?

just a leftover from my own testing, removed in the next commit. Thanks for noticing

> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 164:
> 
>> 162:             HttpsURLConnection.setDefaultHostnameVerifier(new NameVerifier());
>> 163:             http = (HttpsURLConnection) url.openConnection();
>> 164:             InputStream is = http.getInputStream();
> 
> See my comment above regarding `InputStream` and try-with-resources.

Done in next commit

> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 316:
> 
>> 314:     void startServer(boolean newThread) throws Exception {
>> 315:         if (newThread) {
>> 316:             serverThread = new Thread(() -> {
> 
> Nit: Unsolicited style changes can obstruct backporting and decrease version control hygiene. (This comment applies to changes starting from line 338 too.)

Change was requested in the previous comments, so I believe this should be kept

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2276454772
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2276450917
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2276450602
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2276449200
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2276447648
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2276447057

From vyazici at openjdk.org  Thu Aug 14 18:43:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 14 Aug 2025 18:43:34 GMT
Subject: RFR: 8364263: HttpClient: Improve encapsulation of ProxyServer
Message-ID: <TKSLF623aCUmqoCzIi0z-NHwXLWDJi97naG2xuoiy1A=.4929e7d4-83f7-4a39-a20f-bcde4ca1229a@github.com>

Make `ProxyServer` not extend from `Thread`.

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

Commit messages:
 - Make `ProxyServer` not extend from `Thread`

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

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

From vyazici at openjdk.org  Thu Aug 14 18:43:35 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 14 Aug 2025 18:43:35 GMT
Subject: RFR: 8364263: HttpClient: Improve encapsulation of ProxyServer
In-Reply-To: <TKSLF623aCUmqoCzIi0z-NHwXLWDJi97naG2xuoiy1A=.4929e7d4-83f7-4a39-a20f-bcde4ca1229a@github.com>
References: <TKSLF623aCUmqoCzIi0z-NHwXLWDJi97naG2xuoiy1A=.4929e7d4-83f7-4a39-a20f-bcde4ca1229a@github.com>
Message-ID: <FGwEie2KVWERPC16VetqqB1jAe7kO5JyH4b57ythc1w=.c69b254a-05a2-4256-be49-7157bcd81333@github.com>

On Thu, 14 Aug 2025 18:33:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Make `ProxyServer` not extend from `Thread`.

test/jdk/java/net/httpclient/ProxyServer.java line 43:

> 41:  * intended for large numbers of parallel connections.
> 42:  */
> 43: public final class ProxyServer implements Closeable {

Added `final` to enhance the encapsulation

test/jdk/java/net/httpclient/ProxyServer.java line 100:

> 98:     }
> 99: 
> 100:     private ProxyServer(Integer port, Boolean debug, Credentials credentials)

`Credentials` is a `private` class, this ctor should not be exposed.

test/jdk/java/net/httpclient/ProxyServer.java line 110:

> 108:         this.credentials = credentials;
> 109:         connections = new CopyOnWriteArrayList<Connection>();
> 110:         Thread.ofPlatform().name("ProxyListener").daemon().start(this::run);

No need to hold a reference to the `Thread`. It will terminate either at the JVM exit, or via `done` flag checked in the `run()` loop.

test/jdk/java/net/httpclient/ProxyServer.java line 650:

> 648:         boolean debug = args.length > 1 && args[1].equals("-debug");
> 649:         System.out.println("Debugging : " + debug);
> 650:         try (ProxyServer ps = new ProxyServer(port, debug)) {

If we want users to properly wrap `ProxyServer` in try-with-resources, we should be such an example too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26786#discussion_r2277439411
PR Review Comment: https://git.openjdk.org/jdk/pull/26786#discussion_r2277440573
PR Review Comment: https://git.openjdk.org/jdk/pull/26786#discussion_r2277443640
PR Review Comment: https://git.openjdk.org/jdk/pull/26786#discussion_r2277446274

From dnsimon at openjdk.org  Thu Aug 14 19:33:15 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 14 Aug 2025 19:33:15 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
Message-ID: <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>

On Wed, 13 Aug 2025 14:22:08 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   After suggestions from Erik and Andrey

> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.

Would you mind also running tier9 to avoid surprises there.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3189640422

From iklam at openjdk.org  Fri Aug 15 00:20:30 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 15 Aug 2025 00:20:30 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
Message-ID: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>

This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. 

- We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`.
- `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved.
- In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java.

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

Commit messages:
 - tightened SystemDictionary::preload_class()
 - Fixed bugs found in JCK
 - added entry in ProblemList-AotJdk.txt due to 8323727
 - more clean up
 - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap
 - Fixed arm build
 - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap
 - clean up
 - java.net.URL class needs runtimeSetup
 - fixed build
 - ... and 5 more: https://git.openjdk.org/jdk/compare/25480f00...15746239

Changes: https://git.openjdk.org/jdk/pull/26375/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350550
  Stats: 553 lines in 39 files changed: 441 ins; 13 del; 99 mod
  Patch: https://git.openjdk.org/jdk/pull/26375.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375

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

From dfuchs at openjdk.org  Fri Aug 15 09:46:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 15 Aug 2025 09:46:13 GMT
Subject: RFR: 8364263: HttpClient: Improve encapsulation of ProxyServer
In-Reply-To: <TKSLF623aCUmqoCzIi0z-NHwXLWDJi97naG2xuoiy1A=.4929e7d4-83f7-4a39-a20f-bcde4ca1229a@github.com>
References: <TKSLF623aCUmqoCzIi0z-NHwXLWDJi97naG2xuoiy1A=.4929e7d4-83f7-4a39-a20f-bcde4ca1229a@github.com>
Message-ID: <YrcHq03CGsznARNXQeumLCeLm_eDDmTkLxbsp9y1Bj8=.6e601da0-ee4a-453b-a029-d04789bc85bf@github.com>

On Thu, 14 Aug 2025 18:33:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Make `ProxyServer` not extend from `Thread`.

LGTM. Please make sure to run all tests that might be using this class (tier2 should do it) to double check that none of them use methods from Thread - such as calling `proxy.join()`. With this change that would no longer compile.

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

PR Review: https://git.openjdk.org/jdk/pull/26786#pullrequestreview-3123484227

From lkorinth at openjdk.org  Fri Aug 15 11:43:33 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 15 Aug 2025 11:43:33 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

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

  added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/dbe42964..8fa40e7d

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

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

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

From lkorinth at openjdk.org  Fri Aug 15 11:59:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 15 Aug 2025 11:59:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <iWlp9Azqc_MsGBnk-PK8OYZqpcnhSASRJmnz8IgzTQI=.965cedce-3e5a-40e5-9e86-9b1f5c2d2021@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Added three new `/timeout=480` after the last run.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3191343090

From dfuchs at openjdk.org  Fri Aug 15 13:47:12 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 15 Aug 2025 13:47:12 GMT
Subject: RFR: 8364263: HttpClient: Improve encapsulation of ProxyServer
In-Reply-To: <TKSLF623aCUmqoCzIi0z-NHwXLWDJi97naG2xuoiy1A=.4929e7d4-83f7-4a39-a20f-bcde4ca1229a@github.com>
References: <TKSLF623aCUmqoCzIi0z-NHwXLWDJi97naG2xuoiy1A=.4929e7d4-83f7-4a39-a20f-bcde4ca1229a@github.com>
Message-ID: <LdB_taJAo0v61aPrVMLoV9nasb4pHjr6m389SOvoEfk=.b30a7963-3fdc-49f9-9f7d-60838d024280@github.com>

On Thu, 14 Aug 2025 18:33:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Make `ProxyServer` not extend from `Thread`.

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26786#pullrequestreview-3123891979

From syan at openjdk.org  Fri Aug 15 14:08:12 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 15 Aug 2025 14:08:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

make/RunTests.gmk line 940:

> 938:   JTREG_AUTO_PROBLEM_LISTS :=
> 939:   # Please reach consensus before changing this. It was not easy changing it to a `1`.
> 940:   JTREG_AUTO_TIMEOUT_FACTOR := 1

Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5()

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2279056261

From jpai at openjdk.org  Mon Aug 18 05:03:18 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 18 Aug 2025 05:03:18 GMT
Subject: RFR: 8364263: HttpClient: Improve encapsulation of ProxyServer
In-Reply-To: <TKSLF623aCUmqoCzIi0z-NHwXLWDJi97naG2xuoiy1A=.4929e7d4-83f7-4a39-a20f-bcde4ca1229a@github.com>
References: <TKSLF623aCUmqoCzIi0z-NHwXLWDJi97naG2xuoiy1A=.4929e7d4-83f7-4a39-a20f-bcde4ca1229a@github.com>
Message-ID: <VPPdhzco33qae3tCjeIetAO1PKJAZJ3huOxvTgHk3Jo=.4e0adc11-6013-4589-bd91-e61e6f7b8962@github.com>

On Thu, 14 Aug 2025 18:33:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Make `ProxyServer` not extend from `Thread`.

Thank you Volkan for cleaning this up. This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26786#pullrequestreview-3126792400

From vyazici at openjdk.org  Mon Aug 18 08:11:16 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 18 Aug 2025 08:11:16 GMT
Subject: RFR: 8364263: HttpClient: Improve encapsulation of ProxyServer
In-Reply-To: <LdB_taJAo0v61aPrVMLoV9nasb4pHjr6m389SOvoEfk=.b30a7963-3fdc-49f9-9f7d-60838d024280@github.com>
References: <TKSLF623aCUmqoCzIi0z-NHwXLWDJi97naG2xuoiy1A=.4929e7d4-83f7-4a39-a20f-bcde4ca1229a@github.com>
 <LdB_taJAo0v61aPrVMLoV9nasb4pHjr6m389SOvoEfk=.b30a7963-3fdc-49f9-9f7d-60838d024280@github.com>
Message-ID: <SMsbFi1miGRb81YrcD-xn2Ln02mINrTE4h9yOs292OM=.4467847e-665e-4834-8172-d60980ce0af7@github.com>

On Fri, 15 Aug 2025 13:44:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Make `ProxyServer` not extend from `Thread`.
>
> Marked as reviewed by dfuchs (Reviewer).

@dfuch, @jaikiran, thanks so much for the reviews. I've verified that `tier2` passes.

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

PR Comment: https://git.openjdk.org/jdk/pull/26786#issuecomment-3195582937

From vyazici at openjdk.org  Mon Aug 18 08:14:27 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 18 Aug 2025 08:14:27 GMT
Subject: Integrated: 8364263: HttpClient: Improve encapsulation of ProxyServer
In-Reply-To: <TKSLF623aCUmqoCzIi0z-NHwXLWDJi97naG2xuoiy1A=.4929e7d4-83f7-4a39-a20f-bcde4ca1229a@github.com>
References: <TKSLF623aCUmqoCzIi0z-NHwXLWDJi97naG2xuoiy1A=.4929e7d4-83f7-4a39-a20f-bcde4ca1229a@github.com>
Message-ID: <VC38asSoQ4VZ1Lvo0bGoOmTxFihc2rD6A4215tPd4-s=.4db2a443-6189-442b-bc77-f9e888d82da5@github.com>

On Thu, 14 Aug 2025 18:33:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Make `ProxyServer` not extend from `Thread`.

This pull request has now been integrated.

Changeset: 190e1130
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/190e113031bc6ece781fdf0d9f3c853ce324f170
Stats:     20 lines in 1 file changed: 2 ins; 10 del; 8 mod

8364263: HttpClient: Improve encapsulation of ProxyServer

Reviewed-by: dfuchs, jpai

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

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

From lkorinth at openjdk.org  Mon Aug 18 09:10:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:10:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
Message-ID: <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>

On Fri, 15 Aug 2025 14:05:49 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD
>
> make/RunTests.gmk line 940:
> 
>> 938:   JTREG_AUTO_PROBLEM_LISTS :=
>> 939:   # Please reach consensus before changing this. It was not easy changing it to a `1`.
>> 940:   JTREG_AUTO_TIMEOUT_FACTOR := 1
> 
> Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5()

It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2281781536

From lkorinth at openjdk.org  Mon Aug 18 09:18:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:18:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
Message-ID: <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>

On Mon, 18 Aug 2025 09:07:54 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> make/RunTests.gmk line 940:
>> 
>>> 938:   JTREG_AUTO_PROBLEM_LISTS :=
>>> 939:   # Please reach consensus before changing this. It was not easy changing it to a `1`.
>>> 940:   JTREG_AUTO_TIMEOUT_FACTOR := 1
>> 
>> Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5()
>
> It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.

It is also something that can be changed later, in a follow up fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2281802454

From lkorinth at openjdk.org  Mon Aug 18 09:36:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:36:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
 <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>
Message-ID: <3l5I9q7S4O_0gH6mvxy3P21f1JxqcQKNsnBTN7rWhmc=.ddcf4337-dc6e-493d-ae07-5bd4affb9321@github.com>

On Thu, 14 Aug 2025 19:30:30 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> Would you mind also running tier9 to avoid surprises there.

I had problems doing this, and I just want to say that I have not run tier9 (I have talked to Douglas off-list).

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3195900610

From lkorinth at openjdk.org  Mon Aug 18 09:43:14 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:43:14 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <9GMJWT-CNwqDVALuPdRR9EDs5G1c2jUr3y887qw2_EU=.1a7347a2-d1e5-427d-aeda-6924e2db39ba@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

If there are no mayor objections, I will update the copyrights before I leave work today.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3195923727

From dfuchs at openjdk.org  Mon Aug 18 11:38:14 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 18 Aug 2025 11:38:14 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Hi Leo, I played a bit with your changes and I observed intermittent timeout failures for the following tests:


	java/net/httpclient/CancelledResponse.java
	java/net/httpclient/whitebox/FlowTestDriver.java


The	first test failing more frequently. Could you please add /timeout=480 to these two tests as well?

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3196281299

From rriggs at openjdk.org  Mon Aug 18 13:15:11 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Aug 2025 13:15:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Generally, changes with this many changed files are broken down into smaller PRs to make the review easier and more conclusive. In this case, hotspot, jdk, and langtools might have been good groupings.  The reviews could be done in parallel and committed with the final change to jtreg when they are all approved.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3196793327

From lkorinth at openjdk.org  Mon Aug 18 14:34:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 14:34:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@github.com>
Message-ID: <lSUzoh2lhdmeEPYY2eAAGIycS8QSm5_9BLFy7FgOfFw=.f7a8acc4-ead5-4625-9d3c-83a345212193@github.com>

On Mon, 18 Aug 2025 13:12:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Generally, changes with this many changed files are broken down into smaller PRs to make the review easier and more conclusive. In this case, hotspot, jdk, and langtools might have been good groupings. The reviews could be done in parallel and committed with the final change to jtreg when they are all approved.

Noted. I did it so reviewers could se the change "as a whole". Feel free to review a part of the change!

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3197186029

From lmesnik at openjdk.org  Mon Aug 18 15:01:12 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 18 Aug 2025 15:01:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <O_WRSR2Q7KM1CWMYPxfXyFQI3lU9AjTOklWNVYAxvUk=.387e933f-0eed-43d8-a2eb-dbe2dd98cc75@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Thank you for fixing this! I think the changes are good.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3128749995

From michaelm at openjdk.org  Mon Aug 18 15:10:31 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 18 Aug 2025 15:10:31 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v8]
In-Reply-To: <rRmsqMqDtcwMpU52rkou98OEkEDQZGEIK1bFAVdBijA=.38b6db88-cf6c-4a35-904a-eb36dbf8e4c3@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <rRmsqMqDtcwMpU52rkou98OEkEDQZGEIK1bFAVdBijA=.38b6db88-cf6c-4a35-904a-eb36dbf8e4c3@github.com>
Message-ID: <CL6_cgWcwFS2Dg403d7zHOlRJPvN0iOjmCs9O4A-JYo=.cdd859cb-c904-49c8-8453-a6a12912d7de@github.com>

On Mon, 11 Aug 2025 07:47:03 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve style for declaring multiple consecutive fields of the same type

This looks fine to me.

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26155#pullrequestreview-3128782917

From dfuchs at openjdk.org  Mon Aug 18 15:15:32 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 18 Aug 2025 15:15:32 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v8]
In-Reply-To: <rRmsqMqDtcwMpU52rkou98OEkEDQZGEIK1bFAVdBijA=.38b6db88-cf6c-4a35-904a-eb36dbf8e4c3@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <rRmsqMqDtcwMpU52rkou98OEkEDQZGEIK1bFAVdBijA=.38b6db88-cf6c-4a35-904a-eb36dbf8e4c3@github.com>
Message-ID: <KTPjgVPhVPQVsDUJwfZTTEG9il1CNtrWWinLINwnTDs=.9a4555ea-b439-4a75-9a70-9572975b5ae2@github.com>

On Mon, 11 Aug 2025 07:47:03 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve style for declaring multiple consecutive fields of the same type

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26155#pullrequestreview-3128803668

From lkorinth at openjdk.org  Mon Aug 18 16:34:21 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 16:34:21 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

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

  after suggestion from Daniel

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/8fa40e7d..286a2cc6

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

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

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

From lkorinth at openjdk.org  Mon Aug 18 16:34:22 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 16:34:22 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com>
Message-ID: <KNNxBq11P7lT_D16Mzwx-_VHkNITiw5wQbuYCf58yQI=.cdcf7871-b20c-4e44-b10e-c6108e647afb@github.com>

On Mon, 18 Aug 2025 11:34:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi Leo, I played a bit with your changes and I observed intermittent timeout failures for the following tests:
> 
> ```
> 	java/net/httpclient/CancelledResponse.java
> 	java/net/httpclient/whitebox/FlowTestDriver.java
> ```
> 
> The first test failing more frequently. Could you please add /timeout=480 to these two tests as well?

Fixed! Thanks for helping!

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3197614389

From dfuchs at openjdk.org  Mon Aug 18 16:46:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 18 Aug 2025 16:46:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <a3CwlSQwHYj_F3fC30zoiDhXf9G-cn5xK8ZwVFmxBd0=.afdaf352-e494-4bc6-adf2-dc5afa0dd4b9@github.com>

On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   after suggestion from Daniel

Thanks! Changes to JNDI / net / httpclient LGTM.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3197675337

From syan at openjdk.org  Tue Aug 19 03:34:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 19 Aug 2025 03:34:47 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
Message-ID: <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>

On Mon, 18 Aug 2025 09:15:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.
>
> It is also something that can be changed later, in a follow up fix.

Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds too long and it's unacceptable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2283972732

From dholmes at openjdk.org  Tue Aug 19 05:25:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 05:25:40 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
Message-ID: <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>

On Tue, 19 Aug 2025 03:31:55 GMT, SendaoYan <syan at openjdk.org> wrote:

>> It is also something that can be changed later, in a follow up fix.
>
> Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
> If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds is too long and it's unacceptable.

> It is unclear to me if the author meant this to be 2.5 more than normal or 10 more than JTREG default, or a multiplier that seems to work. 

What matters is that the actual timeout, in seconds, remains unchanged, so please address this. Timeouts that are excessively long waste machine resources.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2284090715

From dholmes at openjdk.org  Tue Aug 19 05:49:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 05:49:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>

On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   after suggestion from Daniel

By rough count there are 1300 tests that have an explicit timeout set. This change would reduce the actual applied timeout to a quarter of what was previously used, yet you have only had to bump the timeout value for a fraction of the tests - which I find somewhat (pleasantly) surprising. It may be that many of these timeouts stem from a time when we had much much slower machines, so a refresh might not be a bad thing. It will take some time to see the full effects of this change though.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3199288818

From dholmes at openjdk.org  Tue Aug 19 06:07:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 06:07:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
Message-ID: <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>

On Tue, 19 Aug 2025 05:23:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
>> If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds is too long and it's unacceptable.
>
> DELETED - I confused the timeout with the timeout-factor. New comment below.

No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 

However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2284161138

From syan at openjdk.org  Tue Aug 19 06:40:45 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 19 Aug 2025 06:40:45 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
Message-ID: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>

On Tue, 19 Aug 2025 06:04:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> DELETED - I confused the timeout with the timeout-factor. New comment below.
>
> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
> 
> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.

But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.

The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2284273170

From jpai at openjdk.org  Tue Aug 19 06:42:43 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Aug 2025 06:42:43 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v8]
In-Reply-To: <rRmsqMqDtcwMpU52rkou98OEkEDQZGEIK1bFAVdBijA=.38b6db88-cf6c-4a35-904a-eb36dbf8e4c3@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <rRmsqMqDtcwMpU52rkou98OEkEDQZGEIK1bFAVdBijA=.38b6db88-cf6c-4a35-904a-eb36dbf8e4c3@github.com>
Message-ID: <6w9ioUO1Rm0EHeVLchCK1kz3mWCyC6MJkZLAeLIppfs=.6080f559-6f03-4e3b-9c7b-604817ecf706@github.com>

On Mon, 11 Aug 2025 07:47:03 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve style for declaring multiple consecutive fields of the same type

The implementation and test changes look good to me.

I had some suggestions for the javadoc text. Here's what I had in mind, if Daniel and Michael suggest that the current form in this PR is OK, then it's OK to not change it:


/**
 * {@return a request body publisher whose body is the {@code length}
 * content bytes read from the provided file {@code channel} starting
 * from the specified {@code offset}}
 * <p>
 * This method does not modify the {@code channel}'s position.
 * <p>
 * This method does not close the {@code channel}. The caller is
 * expected to close the {@code channel} when no longer needed.
 *
 * @apiNote
 * This method can be used to either publish just a portion of a
 * file's content as the request body or to publish different portions
 * of the file's content concurrently.
 * The typical approach to concurrently publish different portions of a
 * file's content is to create an instance of {@link FileChannel}
 * and then create multiple {@code HttpRequest}s each of which use
 * a {@code ofFileChannel BodyPublisher} with a different non-overlapping
 * offset and length.
 *
 * @param channel a file channel
 * @param offset the offset of the first byte
 * @param length the number of bytes to read from the file channel
 *
 * @throws IndexOutOfBoundsException if the specified byte range is
 * found to be {@linkplain Objects#checkFromIndexSize(long, long, long)
 * out of bounds} compared with the size of the file referred by the
 * channel
 *
 * @throws IOException if the size of the {@code channel} cannot be
 *                      determined or the {@code channel} is closed
 *
 * @throws NullPointerException if {@code channel} is null
 *
 * @since 26
 */



(Apart from the text changes, do note that the `@throws IOException` specification in that text is intentionally changed to note that it will be thrown if the given channel is closed, in addition to if the size() cannot be determined).

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

PR Comment: https://git.openjdk.org/jdk/pull/26155#issuecomment-3199431572

From vyazici at openjdk.org  Tue Aug 19 08:26:46 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 19 Aug 2025 08:26:46 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v8]
In-Reply-To: <6w9ioUO1Rm0EHeVLchCK1kz3mWCyC6MJkZLAeLIppfs=.6080f559-6f03-4e3b-9c7b-604817ecf706@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <rRmsqMqDtcwMpU52rkou98OEkEDQZGEIK1bFAVdBijA=.38b6db88-cf6c-4a35-904a-eb36dbf8e4c3@github.com>
 <6w9ioUO1Rm0EHeVLchCK1kz3mWCyC6MJkZLAeLIppfs=.6080f559-6f03-4e3b-9c7b-604817ecf706@github.com>
Message-ID: <opW213NDouRCemxAcydDiZk-uzaC8zCSzZmu8pjcQGg=.70e5ef91-50a6-443c-8813-355302fafaa8@github.com>

On Tue, 19 Aug 2025 06:40:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve style for declaring multiple consecutive fields of the same type
>
> The implementation and test changes look good to me.
> 
> I had some suggestions for the javadoc text. Here's what I had in mind, if Daniel and Michael suggest that the current form in this PR is OK, then it's OK to not change it:
> 
> 
> /**
>  * {@return a request body publisher whose body is the {@code length}
>  * content bytes read from the provided file {@code channel} starting
>  * from the specified {@code offset}}
>  * <p>
>  * This method does not modify the {@code channel}'s position.
>  * <p>
>  * This method does not close the {@code channel}. The caller is
>  * expected to close the {@code channel} when no longer needed.
>  *
>  * @apiNote
>  * This method can be used to either publish just a portion of a
>  * file's content as the request body or to publish different portions
>  * of the file's content concurrently.
>  * The typical approach to concurrently publish different portions of a
>  * file's content is to create an instance of {@link FileChannel}
>  * and then create multiple {@code HttpRequest}s each of which use
>  * a {@code ofFileChannel BodyPublisher} with a different non-overlapping
>  * offset and length.
>  *
>  * @param channel a file channel
>  * @param offset the offset of the first byte
>  * @param length the number of bytes to read from the file channel
>  *
>  * @throws IndexOutOfBoundsException if the specified byte range is
>  * found to be {@linkplain Objects#checkFromIndexSize(long, long, long)
>  * out of bounds} compared with the size of the file referred by the
>  * channel
>  *
>  * @throws IOException if the size of the {@code channel} cannot be
>  *                      determined or the {@code channel} is closed
>  *
>  * @throws NullPointerException if {@code channel} is null
>  *
>  * @since 26
>  */
> 
> 
> 
> (Apart from the text changes, do note that the `@throws IOException` specification in that text is intentionally changed to note that it will be thrown if the given channel is closed, in addition to if the size() cannot be determined).

@jaikiran, regarding your spec. suggestion:


          * content bytes read from the provided file {@code channel} starting
          * from the specified {@code offset}}
          * <p>
-         * The {@linkplain FileChannel file channel} will be read using
-         * {@link FileChannel#read(ByteBuffer, long) FileChannel.read(ByteBuffer buffer, long position)},
-         * which does not modify the channel's position. Thus, the same file
-         * channel may be shared between several publishers passed to
-         * concurrent requests.
+         * This method does not modify the {@code channel}'s position.
          * <p>
-         * The file channel will not be closed upon completion. The caller is
-         * expected to manage the life cycle of the channel, and close it
-         * appropriately when not needed anymore.
+         * This method does not close the {@code channel}. The caller is
+         * expected to close the {@code channel} when no longer needed.
+         *
+         * @apiNote
+         * This method can be used to either publish just a portion of a
+         * file's content as the request body or to publish different portions
+         * of the file's content concurrently.
+         * The typical approach to concurrently publish different portions of a
+         * file's content is to create an instance of {@link FileChannel}
+         * and then create multiple {@code HttpRequest}s each of which use
+         * a {@code ofFileChannel BodyPublisher} with a different non-overlapping
+         * offset and length.
          *
          * @param channel a file channel
          * @param offset the offset of the first byte
@@ -744,8 +749,8 @@
          * out of bounds} compared with the size of the file referred by the
          * channel
          *
-         * @throws IOException if the size of the file referred by the provided
-         * channel cannot be read while verifying the specified byte range
+         * @throws IOException if the size of the {@code channel} cannot be
+         *                      determined or the {@code channel} is closed
          *
          * @throws NullPointerException if {@code channel} is null
          *


1. I see you removed the explicit mention of the `FileChannel#read(ByteBuffer, long)` usage. I had placed it intentionally there, as requested by @dfuch, for `FileChannel` can have custom implementations, and we better communicate what `FC` method we use under the hood and with which assumptions.
2. Regarding the _"the size of the {@code channel}"_ expression, maybe a little bit grammar policing, but a channel doesn't have a size, instead, the file referred by the channel has a size ? `FC::size` Javadoc is worded in this way too.

I will wait for the input of @dfuch and/or @Michael-Mc-Mahon, and then submit the CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/26155#issuecomment-3199748167

From lkorinth at openjdk.org  Tue Aug 19 09:02:36 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 19 Aug 2025 09:02:36 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>
Message-ID: <uOH12UfZUHixcxSAx8lP66zvzxKr50yUj8x4_x22Su0=.31769f01-81c4-48b0-9050-f642c562deb5@github.com>

On Tue, 19 Aug 2025 05:47:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

> By rough count there are 1300 tests that have an explicit timeout set. This change would reduce the actual applied timeout to a quarter of what was previously used, yet you have only had to bump the timeout value for a fraction of the tests - which I find somewhat (pleasantly) surprising. It may be that many of these timeouts stem from a time when we had much much slower machines, so a refresh might not be a bad thing. It will take some time to see the full effects of this change though.

Thanks David! And as you said, a few more adjustments will probably be needed when we have run this for a while.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3199869795

From lkorinth at openjdk.org  Tue Aug 19 09:19:45 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 19 Aug 2025 09:19:45 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
Message-ID: <BM1P_203-vMLbBYxbzigREy0NuHWoZqfgQvmGV0SH7I=.bf66ee89-19a9-4212-b800-08e7c835f4de@github.com>

On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
>> 
>> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.
>
> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
> 
> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

I do not think 4x longer timeouts for `-Xcomp` is unreasonable. I also do not want to make this huge change even bigger. If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2284650722

From jpai at openjdk.org  Tue Aug 19 09:20:40 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Aug 2025 09:20:40 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v8]
In-Reply-To: <KTPjgVPhVPQVsDUJwfZTTEG9il1CNtrWWinLINwnTDs=.9a4555ea-b439-4a75-9a70-9572975b5ae2@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <rRmsqMqDtcwMpU52rkou98OEkEDQZGEIK1bFAVdBijA=.38b6db88-cf6c-4a35-904a-eb36dbf8e4c3@github.com>
 <KTPjgVPhVPQVsDUJwfZTTEG9il1CNtrWWinLINwnTDs=.9a4555ea-b439-4a75-9a70-9572975b5ae2@github.com>
Message-ID: <ljkfMwkcn41iZAx3z-cwliQ4GPGopcoe8sbWrNBfmFI=.c3cce326-347d-47c4-a1fb-86e0b51cac0b@github.com>

On Mon, 18 Aug 2025 15:12:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve style for declaring multiple consecutive fields of the same type
>
> Marked as reviewed by dfuchs (Reviewer).

> I see you removed the explicit mention of the FileChannel#read(ByteBuffer, long) usage. I had placed it intentionally there, as requested by @dfuch, for FileChannel can have custom implementations, and we better communicate what FC method we use under the hood and with which assumptions.

I felt that as long as we convey that the `FileChannel's` position isn't altered by the method, then it should be enough for the specification of the API, without having to explain which method the implementation uses. But I'll let Daniel suggest which one he prefers.

>  Regarding the _"the size of the {@code channel}"_ expression, maybe a little bit grammar policing, but a channel doesn't have a size, instead, the file referred by the channel has a size ? `FC::size` Javadoc is worded in this way too.

I think it can be worded something like:

> @throws IOException if the {@linkplain FileChannel#size() channel's size} cannot be determined or the {@code channel} is closed

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

PR Comment: https://git.openjdk.org/jdk/pull/26155#issuecomment-3199936910

From dfuchs at openjdk.org  Tue Aug 19 09:27:47 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Aug 2025 09:27:47 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v8]
In-Reply-To: <rRmsqMqDtcwMpU52rkou98OEkEDQZGEIK1bFAVdBijA=.38b6db88-cf6c-4a35-904a-eb36dbf8e4c3@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <rRmsqMqDtcwMpU52rkou98OEkEDQZGEIK1bFAVdBijA=.38b6db88-cf6c-4a35-904a-eb36dbf8e4c3@github.com>
Message-ID: <khL88E53PNGxU31UJEUbwX9rBEWhhbzVRaQjij3_-W8=.7c3d6b73-3960-42d2-85a1-88e006f73846@github.com>

On Mon, 11 Aug 2025 07:47:03 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve style for declaring multiple consecutive fields of the same type

I'm not sure saying "this method doesn't change the channel position" is appropriate - indeed it's not the method that would potentially change the channel position but the body publisher it returns.

On the one hand, not mentioning explicitely that we use `FileChannel#read(ByteBuffer, long)` doesn't lock us on the implementation; on the other hand it leaves some uncertainty on how we achieve this and whether concurrency would effectively work (we could be locking the channel and resetting its position for instance).

I like the idea of moving that information into an `@apiNote`. Maybe a cross between your suggested change and what Volkan currently has? Also - though uploading non-overlapping portions of the file is how you would usually use the publisher, it is not required that the portions are non-overlapping for concurrency to work correctly.

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

PR Comment: https://git.openjdk.org/jdk/pull/26155#issuecomment-3199960642

From djelinski at openjdk.org  Tue Aug 19 10:00:04 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Aug 2025 10:00:04 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
 <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
Message-ID: <_z_WkScJqZa0sGl-fiivLYz2RjMtrKRpszMfD5KoVV8=.7a6e7075-2c6c-4a97-bdf1-333dcb35fc5c@github.com>

On Thu, 24 Jul 2025 16:59:12 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: fix new HttpHeadersBuilder constructor
>>  - qpack - optimize processing of decoder instruction exceptions
>>  - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
>>  - Avoid speculating about the future in TODOs
>>  - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
>>  - merge latest changes from master branch
>>  - http3: fix typo in UniStreamPair.java
>>  - WriterQueue may leak before the constructor completes
>>  - Limit the number of retries in H3UserInfoTest
>>  - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d
>
> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/ThrowingConsumer.java line 26:
> 
>> 24: 
>> 25: @FunctionalInterface
>> 26: public interface ThrowingConsumer<T, X extends Throwable> {
> 
> This interface is only implemented by Http2Handler. We should remove it.

Removed in f31d9235e852395182034e5c3a826a9112e51b8c

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2284751142

From djelinski at openjdk.org  Tue Aug 19 10:09:58 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Aug 2025 10:09:58 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <BfmSxWK_QlU_xRgeDJ42C6CBn0PAgzINJ57MQG8JMPE=.6ccb4260-d3a5-4295-a09c-efb1f2add293@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
 <BfmSxWK_QlU_xRgeDJ42C6CBn0PAgzINJ57MQG8JMPE=.6ccb4260-d3a5-4295-a09c-efb1f2add293@github.com>
Message-ID: <6tYLAgdx9Uwc1i6d_SLprx-ieRWn1qYjDFdDyyujxbQ=.b078fd44-7975-4b5f-9f74-1160c7c42b3e@github.com>

On Wed, 16 Jul 2025 11:19:42 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: fix new HttpHeadersBuilder constructor
>>  - qpack - optimize processing of decoder instruction exceptions
>>  - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
>>  - Avoid speculating about the future in TODOs
>>  - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
>>  - merge latest changes from master branch
>>  - http3: fix typo in UniStreamPair.java
>>  - WriterQueue may leak before the constructor completes
>>  - Limit the number of retries in H3UserInfoTest
>>  - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d
>
> src/java.net.http/share/classes/jdk/internal/net/http/AltSvcProcessor.java line 164:
> 
>> 162:             // serialized form of an origin (defined in section 6.2 of RFC-6454)
>> 163:             try {
>> 164:                 origin = Origin.fromASCIISerializedForm(frame.getOrigin());
> 
> Do we check if the origin is authoritative before processing the alt service? I don't see that here

Addressed in 2d6d1da0249ce133608624fd83c8c6573d56506a

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2284763893

From djelinski at openjdk.org  Tue Aug 19 10:10:01 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Aug 2025 10:10:01 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <2uIlI67ZuXY_FGElLjUN1wcwoPSdVrQACgyVF7AEbfk=.624e0472-4a35-4c9a-aec8-cc02e28d5632@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <2uIlI67ZuXY_FGElLjUN1wcwoPSdVrQACgyVF7AEbfk=.624e0472-4a35-4c9a-aec8-cc02e28d5632@github.com>
Message-ID: <JRMgb9xlQML3FKbcex2XylamJinAc6aSHnuLu-ayBIs=.3908e778-a98f-49c5-891b-84fcf6714abb@github.com>

On Tue, 1 Jul 2025 11:13:44 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.net.http/share/classes/jdk/internal/net/http/http3/frames/FramesDecoder.java line 143:
> 
>> 141:      * This method doesn't try to do any decoding.
>> 142:      */
>> 143:     public Http3Frame peek() {
> 
> This method is unused. I'll remove it.

Addressed in fe4073ca4939e9870924cfc54f1d6e6091642af3

> src/java.net.http/share/classes/jdk/internal/net/http/http3/streams/UniStreamPair.java line 87:
> 
>> 85:     private final CompletableFuture<QuicStreamWriter> streamWriterCF;
>> 86:     // a queue of ByteBuffers submitted for writing.
>> 87:     // might be null if not used. Only used in QueuingStreamPair.
> 
> It seems to be true. I'll see if I can move it to QueuingStreamPair.

Moved in c2a351ed5cdcaa5c0bdf7e28140a1dfb4e751d56 + 91fb530b350f733789c4deae53c83855d00365b6

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2284775186
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2284771544

From djelinski at openjdk.org  Tue Aug 19 10:31:01 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Aug 2025 10:31:01 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <_KViTKZGBXQP1jf-JCdme4Wwzhc1VxUbIgeIaqCuA3E=.b36c2681-216d-4377-9492-9164eef40b51@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <gJjX2SWnVaY5_Iu8xzVmwlIdgYS8PgPYVHEvOaz00KY=.53ed95dc-6560-48da-8db2-49823788a63c@github.com>
 <_KViTKZGBXQP1jf-JCdme4Wwzhc1VxUbIgeIaqCuA3E=.b36c2681-216d-4377-9492-9164eef40b51@github.com>
Message-ID: <mdU0Lw6Eds9_6ewGzEDUnP9a-j4oAmoDlofBw-v2v8I=.7053de75-94c8-4022-b4bc-592e06935b3e@github.com>

On Mon, 30 Jun 2025 09:45:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 124:
>> 
>>> 122:     // exchange so that it can be aborted/timed out mid setup.
>>> 123:     final class ConnectionAborter {
>>> 124:         // In case of HTTP/3 direct connection we may have
>> 
>> "direct" is usually used to refer to connections that don't use a proxy; since H3 connections never use a proxy, can we drop the "direct" here?
>
> Good point. I will rephrase. We should be speaking of HTTP/3 requests (and not connection) here anyway.

done in ee6a0c4ff95d0fd9924f58d163b7653b7b314bc9

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2284825038

From djelinski at openjdk.org  Tue Aug 19 10:37:07 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Aug 2025 10:37:07 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <0uFs6gr4vZ3wgNvAsWhQfjl1_Wq9njUMcHHO-atXhJ0=.60d8e149-5ca9-4b8f-8268-76ca4b03e31a@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <sZqtNoTLqHcpgpaIQ3htp1aSzrAgGkUyLx7mxR9P8jg=.5bf2e89f-2776-4a82-8eff-83ac07995836@github.com>
 <0uFs6gr4vZ3wgNvAsWhQfjl1_Wq9njUMcHHO-atXhJ0=.60d8e149-5ca9-4b8f-8268-76ca4b03e31a@github.com>
Message-ID: <5D1KMUpI79Z4iv8ogIxo_x2w2YZKkfrpRrvlFpS_mYk=.c611224a-f26f-41fb-98e5-52bcf7f29247@github.com>

On Fri, 27 Jun 2025 12:47:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 121:
>> 
>>> 119:     }
>>> 120: 
>>> 121:     // Keeps track of the underlying connection when establishing an HTTP/2
>> 
>> since this is now used with HTTP/3, should we update this comment?
>
> I have verified the other comments in this class and updated to mention or HTTP/3 in a few places in this class, in my local repo. Will appear the next time I sync this PR.

addressed in a245450023ad189a54dfcb66a4303182fe81c972

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2284836370

From djelinski at openjdk.org  Tue Aug 19 10:37:07 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Aug 2025 10:37:07 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kTIIcfqilyJuMUP65znNS6M7QoUQGpws8bXRmcbC0hQ=.a7fa725f-be22-41c1-b2b3-378ad0695ea9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <kTIIcfqilyJuMUP65znNS6M7QoUQGpws8bXRmcbC0hQ=.a7fa725f-be22-41c1-b2b3-378ad0695ea9@github.com>
Message-ID: <bhw7qD8rn9iN1GnIWbkTCNLSxF9jBysNDNc0vt_i-x4=.3fe07ad0-ac25-44de-be39-896993ddb8a3@github.com>

On Fri, 27 Jun 2025 15:27:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 85:
> 
>> 83: 
>> 84:     // This will be set to true only when it is guaranteed that the server hasn't processed
>> 85:     // the request. Typically this happens when the server explicitly states (through a GOAWAY frame
> 
> Suggestion:
> 
>     // the request. Typically, this happens when the server explicitly states (through a GOAWAY frame

addressed in ee6a0c4ff95d0fd9924f58d163b7653b7b314bc9

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2284839382

From dfuchs at openjdk.org  Tue Aug 19 13:31:04 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Aug 2025 13:31:04 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <rjOdFLUipPEg5WANViULncjttCDE1vafjjR0wzhi4HE=.55628aae-59c2-4d50-848a-771154bcd45c@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
 <rjOdFLUipPEg5WANViULncjttCDE1vafjjR0wzhi4HE=.55628aae-59c2-4d50-848a-771154bcd45c@github.com>
Message-ID: <pa5NKYPprdVCPOfR-MZmJGi_jjZjBa90wdOuopGcGL4=.8899187b-806f-4b32-830d-cd6eaa55fa5a@github.com>

On Thu, 24 Jul 2025 15:20:37 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: fix new HttpHeadersBuilder constructor
>>  - qpack - optimize processing of decoder instruction exceptions
>>  - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
>>  - Avoid speculating about the future in TODOs
>>  - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
>>  - merge latest changes from master branch
>>  - http3: fix typo in UniStreamPair.java
>>  - WriterQueue may leak before the constructor completes
>>  - Limit the number of retries in H3UserInfoTest
>>  - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d
>
> test/jdk/java/net/httpclient/http3/H3SimpleTest.java line 47:
> 
>> 45: /*
>> 46:  * @test
>> 47:  * @summary Basic test to verify HTTP3 requests from HttpClient with security manager enabled
> 
> nothing in this test references the security manager.

Will be updated in the next iteration

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2285279024

From dfuchs at openjdk.org  Tue Aug 19 13:57:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Aug 2025 13:57:13 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
 <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
Message-ID: <MEsc5nZ6yFa1haC_LsDWdL4M-zKKvDb-TGIQBB88LZo=.67f38e94-b307-4a02-90e0-26e89097f801@github.com>

On Thu, 24 Jul 2025 15:31:21 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: fix new HttpHeadersBuilder constructor
>>  - qpack - optimize processing of decoder instruction exceptions
>>  - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
>>  - Avoid speculating about the future in TODOs
>>  - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
>>  - merge latest changes from master branch
>>  - http3: fix typo in UniStreamPair.java
>>  - WriterQueue may leak before the constructor completes
>>  - Limit the number of retries in H3UserInfoTest
>>  - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d
>
> test/jdk/java/net/httpclient/http3/H3UnsupportedSSLParametersTest.java line 42:
> 
>> 40:  * @run junit H3UnsupportedSSLParametersTest
>> 41:  */
>> 42: public class H3UnsupportedSSLParametersTest {
> 
> This test overlaps with H3QuicTLSConnection. Any reason we shouldn't merge them?

I logged https://bugs.openjdk.org/browse/JDK-8365793

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2285352186

From dfuchs at openjdk.org  Tue Aug 19 14:04:08 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Aug 2025 14:04:08 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
 <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
Message-ID: <GFPn5-6oANk9F3Z1PXf4GQyQTgR_c8ef1NiVK0ywISU=.56380351-7f84-4685-b379-d69fd719c00b@github.com>

On Thu, 24 Jul 2025 16:02:44 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: fix new HttpHeadersBuilder constructor
>>  - qpack - optimize processing of decoder instruction exceptions
>>  - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
>>  - Avoid speculating about the future in TODOs
>>  - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
>>  - merge latest changes from master branch
>>  - http3: fix typo in UniStreamPair.java
>>  - WriterQueue may leak before the constructor completes
>>  - Limit the number of retries in H3UserInfoTest
>>  - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d
>
> test/jdk/java/net/httpclient/http3/H3StreamLimitReachedTest.java line 94:
> 
>> 92: import static org.testng.Assert.assertFalse;
>> 93: 
>> 94: public class H3StreamLimitReachedTest implements HttpServerAdapters {
> 
> This test seems to duplicate the checks in `StreamLimitTest`.

Actually it doesn't. Though they might overlap to some extent. The StreamLimitTest test tests the vanilla retry of requests when stream limit is reached. The H3StreamLimitReachedTest tests more complex scenarios for connection reuse (or not reuse) by issuing different requests with different discovery modes, and mixing that with retries caused by stream limit reached. Maybe the issue here is finding a better name (or better summary) for these tests. I logged https://bugs.openjdk.org/browse/JDK-8365794

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2285373543

From dfuchs at openjdk.org  Tue Aug 19 14:25:03 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Aug 2025 14:25:03 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
 <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
Message-ID: <659XlzlcGDRFIXAZ9NIu6ZIStogxpE7ZU3M-uKIIV9Q=.6a607db8-b932-479a-995d-8fa53c52f984@github.com>

On Thu, 24 Jul 2025 17:04:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: fix new HttpHeadersBuilder constructor
>>  - qpack - optimize processing of decoder instruction exceptions
>>  - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
>>  - Avoid speculating about the future in TODOs
>>  - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
>>  - merge latest changes from master branch
>>  - http3: fix typo in UniStreamPair.java
>>  - WriterQueue may leak before the constructor completes
>>  - Limit the number of retries in H3UserInfoTest
>>  - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d
>
> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2RedirectHandler.java line 61:
> 
>> 59:     }
>> 60: 
>> 61:     protected byte[] getResponseBytes() {
> 
> this method doesn't appear to be overridden anywhere. Should we revert these changes?

I have logged a task to revisit http2/RedirectTest to use HttpServerAdapters, like http3/H3RedirectTest does. Once this is done we should be able to delete this class - it has an almost duplicate in HttpServerAdapters.
https://bugs.openjdk.org/browse/JDK-8365795

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2285442041

From dfuchs at openjdk.org  Tue Aug 19 14:32:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Aug 2025 14:32:58 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
 <jVYYh4DLldOeQ4p12PLTvEv0FxftJWNmOigobKwhPOY=.2a4b0373-2ba6-478c-bd9e-a5dea4965354@github.com>
Message-ID: <x4aGnRdJT6-mjJFEebSgMAeJPH90562GHLrYVwB4e08=.a226424e-b4a6-4d1b-a580-04c0688bc54e@github.com>

On Thu, 24 Jul 2025 19:28:16 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: fix new HttpHeadersBuilder constructor
>>  - qpack - optimize processing of decoder instruction exceptions
>>  - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
>>  - Avoid speculating about the future in TODOs
>>  - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
>>  - merge latest changes from master branch
>>  - http3: fix typo in UniStreamPair.java
>>  - WriterQueue may leak before the constructor completes
>>  - Limit the number of retries in H3UserInfoTest
>>  - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d
>
> test/jdk/jdk/internal/net/http/quic/packets/QuicPacketNumbersTest.java line 33:
> 
>> 31:  * @modules java.net.http/jdk.internal.net.http.quic.packets
>> 32:  */
>> 33: public class QuicPacketNumbersTest {
> 
> This test covers the same functions as `quic/PacketNumbersTest.java`; can we remove one?

I logged https://bugs.openjdk.org/browse/JDK-8365796

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2285466697

From dfuchs at openjdk.org  Tue Aug 19 14:48:09 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Aug 2025 14:48:09 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <4kAWa2wgbihXfl3lGOhZJ3sNAFh3RwlPMRT9ZeQpYiY=.68e72d2f-3477-4f01-a4da-4e88ecedd3ed@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
 <4kAWa2wgbihXfl3lGOhZJ3sNAFh3RwlPMRT9ZeQpYiY=.68e72d2f-3477-4f01-a4da-4e88ecedd3ed@github.com>
Message-ID: <8UesLa3azo0QuwwzT7-y1c5ByUBzkYMxe3cTfaGM2Dw=.46c6655e-3f4f-4b32-9a9a-7d20bc8356b6@github.com>

On Thu, 24 Jul 2025 12:21:56 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: fix new HttpHeadersBuilder constructor
>>  - qpack - optimize processing of decoder instruction exceptions
>>  - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
>>  - Avoid speculating about the future in TODOs
>>  - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
>>  - merge latest changes from master branch
>>  - http3: fix typo in UniStreamPair.java
>>  - WriterQueue may leak before the constructor completes
>>  - Limit the number of retries in H3UserInfoTest
>>  - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d
>
> test/jdk/java/net/httpclient/http3/BadCipherSuiteErrorTest.java line 59:
> 
>> 57:  * causing hang problems
>> 58:  */
>> 59: public class BadCipherSuiteErrorTest implements HttpServerAdapters {
> 
> This test overlaps with H3QuicTLSConnection test. Any reason to keep them separate?

http3/BadCipherSuiteErrorTest is a clone of http2/ErrorTest - adapted to replace HTTP/2 specifics with HTTP/3.
The original ErrorTest test had been introduced as a non regression test for JDK-8157105.
I guess we could consider merging BadCipherSuiteErrorTest with H3QuicTLSConnection if we are sure that path is covered. I have logged https://bugs.openjdk.org/browse/JDK-8365800

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2285508994

From dfuchs at openjdk.org  Tue Aug 19 15:08:15 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Aug 2025 15:08:15 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v11]
In-Reply-To: <vr9dbhdfhe_CZkHcwTIY8AaPWVzOmKsthRIuvnvdUFU=.b8c6b4bd-1c52-4371-838a-d9d0d271c8f2@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com>
 <vr9dbhdfhe_CZkHcwTIY8AaPWVzOmKsthRIuvnvdUFU=.b8c6b4bd-1c52-4371-838a-d9d0d271c8f2@github.com>
Message-ID: <6nBDnOO0K3TPubH3Vmr0zZhOV4xWdanspQgz4R4cOtk=.c084b221-a808-4dfd-aa1e-3fd085d4ac33@github.com>

On Wed, 23 Jul 2025 11:00:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: fix new HttpHeadersBuilder constructor
>>  - qpack - optimize processing of decoder instruction exceptions
>>  - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin
>>  - Avoid speculating about the future in TODOs
>>  - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement
>>  - merge latest changes from master branch
>>  - http3: fix typo in UniStreamPair.java
>>  - WriterQueue may leak before the constructor completes
>>  - Limit the number of retries in H3UserInfoTest
>>  - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d
>
> test/jdk/java/net/httpclient/AsFileDownloadTest.java line 453:
> 
>> 451: 
>> 452:         @Override
>> 453:         public void handle(HttpTestExchange t) throws IOException {
> 
> this is almost an exact copy of the method above.

Right. Thanks for spotting that. The right thing to do here would be to refactor the HTTP/2 part of the test to stop using Http2TestServer but use HttpTestServer instead, like the new HTTP/3 part. That would get rid of the almost duplicate. I have logged https://bugs.openjdk.org/browse/JDK-8365802

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2285564303

From vyazici at openjdk.org  Tue Aug 19 15:28:43 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 19 Aug 2025 15:28:43 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v8]
In-Reply-To: <ljkfMwkcn41iZAx3z-cwliQ4GPGopcoe8sbWrNBfmFI=.c3cce326-347d-47c4-a1fb-86e0b51cac0b@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <rRmsqMqDtcwMpU52rkou98OEkEDQZGEIK1bFAVdBijA=.38b6db88-cf6c-4a35-904a-eb36dbf8e4c3@github.com>
 <KTPjgVPhVPQVsDUJwfZTTEG9il1CNtrWWinLINwnTDs=.9a4555ea-b439-4a75-9a70-9572975b5ae2@github.com>
 <ljkfMwkcn41iZAx3z-cwliQ4GPGopcoe8sbWrNBfmFI=.c3cce326-347d-47c4-a1fb-86e0b51cac0b@github.com>
Message-ID: <Krp-luy2_ubLre9HawCvmM7TmQwF7zDPQJy7OUjNlE4=.0708611e-efbb-4f5c-b0b5-cf928a861cef@github.com>

On Tue, 19 Aug 2025 09:18:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Marked as reviewed by dfuchs (Reviewer).
>
>> I see you removed the explicit mention of the FileChannel#read(ByteBuffer, long) usage. I had placed it intentionally there, as requested by @dfuch, for FileChannel can have custom implementations, and we better communicate what FC method we use under the hood and with which assumptions.
> 
> I felt that as long as we convey that the `FileChannel's` position isn't altered by the method, then it should be enough for the specification of the API, without having to explain which method the implementation uses. But I'll let Daniel suggest which one he prefers.
> 
>>  Regarding the _"the size of the {@code channel}"_ expression, maybe a little bit grammar policing, but a channel doesn't have a size, instead, the file referred by the channel has a size ? `FC::size` Javadoc is worded in this way too.
> 
> I think it can be worded something like:
> 
>> @throws IOException if the {@linkplain FileChannel#size() channel's size} cannot be determined or the {@code channel} is closed

In 84d14fc0, improved the `ofFileChannel` Javadoc as suggested by @jaikiran ? did not include the mention of `FC::read` used under the hood.

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

PR Comment: https://git.openjdk.org/jdk/pull/26155#issuecomment-3201212175

From jpai at openjdk.org  Tue Aug 19 15:37:43 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Aug 2025 15:37:43 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v8]
In-Reply-To: <khL88E53PNGxU31UJEUbwX9rBEWhhbzVRaQjij3_-W8=.7c3d6b73-3960-42d2-85a1-88e006f73846@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <rRmsqMqDtcwMpU52rkou98OEkEDQZGEIK1bFAVdBijA=.38b6db88-cf6c-4a35-904a-eb36dbf8e4c3@github.com>
 <khL88E53PNGxU31UJEUbwX9rBEWhhbzVRaQjij3_-W8=.7c3d6b73-3960-42d2-85a1-88e006f73846@github.com>
Message-ID: <hpp2aZhoTzovmNwPhkeZJvM229abufxPg3tSw_gOPyo=.3d86c8f7-f934-431e-af89-3d5e73ee7244@github.com>

On Tue, 19 Aug 2025 09:25:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I'm not sure saying "this method doesn't change the channel position" is appropriate - indeed it's not the method that would potentially change the channel position but the body publisher it returns.

That's a good point. I had overlooked the part that the method implementation merely returns a BodyPublisher which then uses the FileChannel. So perhaps we should say:


This method and the returned {@code BodyPublisher} do not modify the {@code channel}'s position.



> Also - though uploading non-overlapping portions of the file is how you would usually use the publisher, it is not required that the portions are non-overlapping for concurrency to work correctly.

Right. The mention about non-overlapping was more to suggest that an entire file can be split into smaller independent parts as part of the upload. But yes, as you note, it's not mandatory and using overlapping portions too does support concurrent usage of the FileChannel. That mention can be removed if it creates confusion.

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

PR Comment: https://git.openjdk.org/jdk/pull/26155#issuecomment-3201249751

From jpai at openjdk.org  Tue Aug 19 17:01:37 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Aug 2025 17:01:37 GMT
Subject: RFR: 8365811: test/jdk/java/net/CookieHandler/B6644726.java failure -
 "Should have 5 cookies. Got only 4,
 expires probably didn't parse correctly"
Message-ID: <AZ4IE7Seo9Y9xyEaWQsOwzeez5CSFuuwQLDl7Dx6Ddc=.230daab5-3138-4563-9108-eac784c118bd@github.com>

Can I please get a review of this trivial test-only fix which addresses the failure in `test/jdk/java/net/CookieHandler/B6644726.java`? This addresses https://bugs.openjdk.org/browse/JDK-8365811.

The test verifies the behaviour of cookie parsing through the `java.net.CookieStore` API. For that it uses a couple of cookies which have an expiry date set to August 19th 2025 (which is today). The assertions in this test start failing once those 2 cookies expire (which is today).

The fix in this PR updates the cookie expiry year to a date very far in future to prevent such failures.

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

Commit messages:
 - 8365811: test/jdk/java/net/CookieHandler/B6644726.java failure - "Should have 5 cookies. Got only 4, expires probably didn't parse correctly"

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

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

From jpai at openjdk.org  Tue Aug 19 17:10:36 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Aug 2025 17:10:36 GMT
Subject: RFR: 8365811: test/jdk/java/net/CookieHandler/B6644726.java
 failure -
 "Should have 5 cookies. Got only 4, expires probably didn't parse correctly"
In-Reply-To: <AZ4IE7Seo9Y9xyEaWQsOwzeez5CSFuuwQLDl7Dx6Ddc=.230daab5-3138-4563-9108-eac784c118bd@github.com>
References: <AZ4IE7Seo9Y9xyEaWQsOwzeez5CSFuuwQLDl7Dx6Ddc=.230daab5-3138-4563-9108-eac784c118bd@github.com>
Message-ID: <NbFHeIT--whH07bZGEGJr-94mAGUDmCsZv8fww40Y5A=.1aa07af2-e743-4781-bbc6-1084e93dd43b@github.com>

On Tue, 19 Aug 2025 16:53:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial test-only fix which addresses the failure in `test/jdk/java/net/CookieHandler/B6644726.java`? This addresses https://bugs.openjdk.org/browse/JDK-8365811.
> 
> The test verifies the behaviour of cookie parsing through the `java.net.CookieStore` API. For that it uses a couple of cookies which have an expiry date set to August 19th 2025 (which is today). The assertions in this test start failing once those 2 cookies expire (which is today).
> 
> The fix in this PR updates the cookie expiry year to a date very far in future to prevent such failures.

I've verified in our CI that with this change in the PR, the test now passes.

I'll be away shortly. In order to speed up the integration and reduce the CI failures, I'll mark this PR as "integrate delegate" to allow any committer to integrate this, once it is approved.

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

PR Comment: https://git.openjdk.org/jdk/pull/26846#issuecomment-3201537121

From vyazici at openjdk.org  Tue Aug 19 17:14:45 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 19 Aug 2025 17:14:45 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v9]
In-Reply-To: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
Message-ID: <GyK6F5s3jxLDCKWGoE2lYUBMmC2pQSwop3nf8LzmppQ=.215d9e22-4bba-4d2a-b93e-0031ee057a14@github.com>

> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
> 
>> The file channel will not be closed upon completion. The caller is
>> expected to manage the life cycle of the channel, and close it
>> appropriately when not needed anymore.
> 
> ### Implementation notes
> 
> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.

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

  Improve the `ofFileChannel` Javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26155/files
  - new: https://git.openjdk.org/jdk/pull/26155/files/91d3422c..369d5e51

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

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

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

From syan at openjdk.org  Wed Aug 20 02:19:35 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 20 Aug 2025 02:19:35 GMT
Subject: RFR: 8365811: test/jdk/java/net/CookieHandler/B6644726.java
 failure -
 "Should have 5 cookies. Got only 4, expires probably didn't parse correctly"
In-Reply-To: <AZ4IE7Seo9Y9xyEaWQsOwzeez5CSFuuwQLDl7Dx6Ddc=.230daab5-3138-4563-9108-eac784c118bd@github.com>
References: <AZ4IE7Seo9Y9xyEaWQsOwzeez5CSFuuwQLDl7Dx6Ddc=.230daab5-3138-4563-9108-eac784c118bd@github.com>
Message-ID: <44bo2Ku8DcyzCv-OBN5bb6Xo_LikDYIevQV1HvHBjUM=.2b35303e-bd6d-4018-a907-406c4b142e3f@github.com>

On Tue, 19 Aug 2025 16:53:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial test-only fix which addresses the failure in `test/jdk/java/net/CookieHandler/B6644726.java`? This addresses https://bugs.openjdk.org/browse/JDK-8365811.
> 
> The test verifies the behaviour of cookie parsing through the `java.net.CookieStore` API. For that it uses a couple of cookies which have an expiry date set to August 19th 2025 (which is today). The assertions in this test start failing once those 2 cookies expire (which is today).
> 
> The fix in this PR updates the cookie expiry year to a date very far in future to prevent such failures.

This fix works for me.

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

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26846#pullrequestreview-3134564558

From syan at openjdk.org  Wed Aug 20 03:37:39 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 20 Aug 2025 03:37:39 GMT
Subject: RFR: 8365834: Mark java/net/httpclient/ManyRequests.java  as
 intermittent
Message-ID: <0Hf0mVj9zZYJxBD40KKb4QPjdH28hl6h7TPkJW6vIg0=.4e31ed4a-e6e5-4760-96d6-1d0bb0dadd51@github.com>

The test java/net/httpclient/ManyRequests.java has been observed intermittent failure such as https://bugs.openjdk.org/browse/JDK-8327968 and https://bugs.openjdk.org/browse/JDK-8365811. Should we mark this test as `@intermittent`.

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

Commit messages:
 - 8365834: Mark java/net/httpclient/ManyRequests.java as intermittent

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

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

From alanb at openjdk.org  Wed Aug 20 06:06:35 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Aug 2025 06:06:35 GMT
Subject: RFR: 8365811: test/jdk/java/net/CookieHandler/B6644726.java
 failure -
 "Should have 5 cookies. Got only 4, expires probably didn't parse correctly"
In-Reply-To: <AZ4IE7Seo9Y9xyEaWQsOwzeez5CSFuuwQLDl7Dx6Ddc=.230daab5-3138-4563-9108-eac784c118bd@github.com>
References: <AZ4IE7Seo9Y9xyEaWQsOwzeez5CSFuuwQLDl7Dx6Ddc=.230daab5-3138-4563-9108-eac784c118bd@github.com>
Message-ID: <tAGrWJD0LE_2g5b4nX4yRHhGgYX4cmJ_SIuQxAYk2mw=.b4a14a45-83a7-4479-b5ed-e20a42f8fb51@github.com>

On Tue, 19 Aug 2025 16:53:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial test-only fix which addresses the failure in `test/jdk/java/net/CookieHandler/B6644726.java`? This addresses https://bugs.openjdk.org/browse/JDK-8365811.
> 
> The test verifies the behaviour of cookie parsing through the `java.net.CookieStore` API. For that it uses a couple of cookies which have an expiry date set to August 19th 2025 (which is today). The assertions in this test start failing once those 2 cookies expire (which is today).
> 
> The fix in this PR updates the cookie expiry year to a date very far in future to prevent such failures.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26846#pullrequestreview-3134892060

From jpai at openjdk.org  Wed Aug 20 06:10:49 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 20 Aug 2025 06:10:49 GMT
Subject: Integrated: 8365811: test/jdk/java/net/CookieHandler/B6644726.java
 failure -
 "Should have 5 cookies. Got only 4, expires probably didn't parse correctly"
In-Reply-To: <AZ4IE7Seo9Y9xyEaWQsOwzeez5CSFuuwQLDl7Dx6Ddc=.230daab5-3138-4563-9108-eac784c118bd@github.com>
References: <AZ4IE7Seo9Y9xyEaWQsOwzeez5CSFuuwQLDl7Dx6Ddc=.230daab5-3138-4563-9108-eac784c118bd@github.com>
Message-ID: <idybEp34R5aE0j088eLgKJYtaUTjO3NLDKDOZc3oVjU=.f6e70596-0cbe-4707-b091-c31ed6be1aca@github.com>

On Tue, 19 Aug 2025 16:53:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial test-only fix which addresses the failure in `test/jdk/java/net/CookieHandler/B6644726.java`? This addresses https://bugs.openjdk.org/browse/JDK-8365811.
> 
> The test verifies the behaviour of cookie parsing through the `java.net.CookieStore` API. For that it uses a couple of cookies which have an expiry date set to August 19th 2025 (which is today). The assertions in this test start failing once those 2 cookies expire (which is today).
> 
> The fix in this PR updates the cookie expiry year to a date very far in future to prevent such failures.

This pull request has now been integrated.

Changeset: b453eb63
Author:    Jaikiran Pai <jpai at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b453eb63c641e1e69b4aef57a220ebe45b9d1693
Stats:     5 lines in 1 file changed: 1 ins; 0 del; 4 mod

8365811: test/jdk/java/net/CookieHandler/B6644726.java failure - "Should have 5 cookies. Got only 4, expires probably didn't parse correctly"

Reviewed-by: syan, alanb

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

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

From vyazici at openjdk.org  Wed Aug 20 09:43:09 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 20 Aug 2025 09:43:09 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v10]
In-Reply-To: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
Message-ID: <GFPm6YhHPMy2MARfJrRf8gBly9jfSC-2b7N_RIQpY6Q=.7a0196e7-583b-4e91-b137-d2a8e0d88b21@github.com>

> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
> 
>> The file channel will not be closed upon completion. The caller is
>> expected to manage the life cycle of the channel, and close it
>> appropriately when not needed anymore.
> 
> ### Implementation notes
> 
> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.

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

  Improve `@apiNote`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26155/files
  - new: https://git.openjdk.org/jdk/pull/26155/files/369d5e51..e4d9c55c

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

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

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

From dfuchs at openjdk.org  Wed Aug 20 10:06:40 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Aug 2025 10:06:40 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v10]
In-Reply-To: <GFPm6YhHPMy2MARfJrRf8gBly9jfSC-2b7N_RIQpY6Q=.7a0196e7-583b-4e91-b137-d2a8e0d88b21@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <GFPm6YhHPMy2MARfJrRf8gBly9jfSC-2b7N_RIQpY6Q=.7a0196e7-583b-4e91-b137-d2a8e0d88b21@github.com>
Message-ID: <prn3Cpl5hpz4LXVoiXAhHg1jXF1Z7Wac4wd17YoXmr4=.9e15d9d0-83c9-4fce-89fb-1a411548e545@github.com>

On Wed, 20 Aug 2025 09:43:09 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve `@apiNote`

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26155#pullrequestreview-3135793730

From jpai at openjdk.org  Wed Aug 20 11:37:43 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 20 Aug 2025 11:37:43 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v10]
In-Reply-To: <GFPm6YhHPMy2MARfJrRf8gBly9jfSC-2b7N_RIQpY6Q=.7a0196e7-583b-4e91-b137-d2a8e0d88b21@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <GFPm6YhHPMy2MARfJrRf8gBly9jfSC-2b7N_RIQpY6Q=.7a0196e7-583b-4e91-b137-d2a8e0d88b21@github.com>
Message-ID: <rgIPTQz4WE7io0LYSZmXDDh8DquOfxQIiK5frV8YoXo=.13bf22bb-ad2b-47f1-a7b9-8ea92814ae36@github.com>

On Wed, 20 Aug 2025 09:43:09 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve `@apiNote`

The latest state of this PR looks good to me. Thank you Volkan for the patience and taking this to completion.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26155#pullrequestreview-3136182612

From jpai at openjdk.org  Wed Aug 20 11:53:38 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 20 Aug 2025 11:53:38 GMT
Subject: RFR: 8365834: Mark java/net/httpclient/ManyRequests.java  as
 intermittent
In-Reply-To: <0Hf0mVj9zZYJxBD40KKb4QPjdH28hl6h7TPkJW6vIg0=.4e31ed4a-e6e5-4760-96d6-1d0bb0dadd51@github.com>
References: <0Hf0mVj9zZYJxBD40KKb4QPjdH28hl6h7TPkJW6vIg0=.4e31ed4a-e6e5-4760-96d6-1d0bb0dadd51@github.com>
Message-ID: <HAx5G9k5ytrc8dPtOujoSNTJdM17ZOJKxgPdqRCiquo=.72bdfe15-976a-4fa7-a72e-dcc7add1ea78@github.com>

On Wed, 20 Aug 2025 03:30:26 GMT, SendaoYan <syan at openjdk.org> wrote:

> The test java/net/httpclient/ManyRequests.java has been observed intermittent failure such as https://bugs.openjdk.org/browse/JDK-8327968 and https://bugs.openjdk.org/browse/JDK-8365811. Should we mark this test as `@intermittent`.

I think it's OK to add the `intermittent` `@key` to the test definition to allow for some setups to skip running this test. Once the actual issue gets addressed, I think we can remove the `intermittent` key.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26852#pullrequestreview-3136238360

From dholmes at openjdk.org  Wed Aug 20 12:55:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 12:55:43 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
Message-ID: <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>

On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
>> 
>> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.
>
> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
> 
> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

@sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288072431

From dfuchs at openjdk.org  Wed Aug 20 13:55:38 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Aug 2025 13:55:38 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:

 - merge latest changes from master branch
 - merge latest http3 changes
 - Hide internal classes
 - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
 - quic: remove unused fields
 - Make final fields static
 - Remove unused variable
 - merge latest changes from master branch
 - http3: update summary in H3SimpleTest.java
 - http3: review feedback - use copy() instead of thenApply(Function.identity())
 - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=12
  Stats: 105379 lines in 471 files changed: 102511 ins; 1335 del; 1533 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

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

From syan at openjdk.org  Wed Aug 20 14:28:43 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 20 Aug 2025 14:28:43 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
Message-ID: <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnXjSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>

On Wed, 20 Aug 2025 12:53:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
>> 
>> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1
>
> @sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.

Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.

So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).

I do agree this change, what I mean is this change has some side effect.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288361080

From dfuchs at openjdk.org  Wed Aug 20 14:31:03 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Aug 2025 14:31:03 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
Message-ID: <Fqe4NqKF0of-gEK7KNgb56fgGpN22OgyE72Yj2BAomY=.1839272d-29a7-4f70-995b-5953767646ef@github.com>

On Wed, 20 Aug 2025 13:55:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
> 
>  - merge latest changes from master branch
>  - merge latest http3 changes
>  - Hide internal classes
>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>  - quic: remove unused fields
>  - Make final fields static
>  - Remove unused variable
>  - merge latest changes from master branch
>  - http3: update summary in H3SimpleTest.java
>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9

I have updated the PR with commits that address most review feedback. 

Among the changes is also one that simplifies how opting in for HTTP/3 is handled. Before this change our implementation would employ different default strategies depending on whether HTTP/3 was set on the client or on the request. We decided to simplify this by handling the two in the same way: whether HTTP/3 is set on the client or on the request no longer matters, as long as it is set in one of them. In both cases - the strategy will be the same: if a new HTTP/3 connection is needed, the connection will be attempted as specified in Http3DiscoveryMode.ANY, unless a more specific H3_DISCOVERY option is explicitely set on the request.

The corresponding API documentation / implNote in HttpOption.java have been updated accordingly.

There's one sentence in the JEP that will also need to be updated to match this behaviour. The apidiff/specdiff attached to the CSR will also need to be updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/24751#issuecomment-3206660010

From djelinski at openjdk.org  Wed Aug 20 14:42:00 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 20 Aug 2025 14:42:00 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
Message-ID: <RqpubBYkhX4M2mTEjW6ag7umJutDcNRactVm09DP04k=.97579686-8a78-4c8f-9881-231c6193b805@github.com>

On Wed, 20 Aug 2025 13:55:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
> 
>  - merge latest changes from master branch
>  - merge latest http3 changes
>  - Hide internal classes
>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>  - quic: remove unused fields
>  - Make final fields static
>  - Remove unused variable
>  - merge latest changes from master branch
>  - http3: update summary in H3SimpleTest.java
>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3136945016

From abarashev at openjdk.org  Wed Aug 20 15:13:02 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 20 Aug 2025 15:13:02 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
Message-ID: <AMCgVJWdJn_DqzDv5xV98Nynbrn7MEbDIdJZ_u8XDfg=.bf6a8011-876a-40a8-95bf-0cb2169401c6@github.com>

On Wed, 20 Aug 2025 13:55:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
> 
>  - merge latest changes from master branch
>  - merge latest http3 changes
>  - Hide internal classes
>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>  - quic: remove unused fields
>  - Make final fields static
>  - Remove unused variable
>  - merge latest changes from master branch
>  - http3: update summary in H3SimpleTest.java
>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 153:

> 151:         // certificate according to requested SNI extension.
> 152:         //
> 153:         // It is not a really HTTPS endpoint identification.

Please restore the above comment block indenting.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 181:

> 179:         // certificate according to requested SNI extension.
> 180:         //
> 181:         // It is not a really HTTPS endpoint identification.

Same as above, block indenting.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 199:

> 197: 
> 198:     // Gets algorithm constraints of QUIC TLS engine.
> 199:     private AlgorithmConstraints getAlgorithmConstraints(QuicTLSEngineImpl engine) {

This method should be moved to `X509KeyManagerCertChecking` as `protected`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288487671
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288488397
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288491094

From abarashev at openjdk.org  Wed Aug 20 15:18:10 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 20 Aug 2025 15:18:10 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
Message-ID: <cG44tMLYSCLxUQv4RW-dzqRDkhA1piD2T5fMPdAzuTI=.e9423d38-5cbd-497d-8b8d-21a28924bee2@github.com>

On Wed, 20 Aug 2025 13:55:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
> 
>  - merge latest changes from master branch
>  - merge latest http3 changes
>  - Hide internal classes
>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>  - quic: remove unused fields
>  - Make final fields static
>  - Remove unused variable
>  - merge latest changes from master branch
>  - http3: update summary in H3SimpleTest.java
>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 229:

> 227:             // just call the functionally limited
> 228:             // javax.net.ssl.X509KeyManager.chooseClientAlias(...)
> 229:             if (km instanceof X509KeyManagerImpl xkm) {

We no longer need a special case for `X509KeyManagerImpl` as `SunX509KeyManagerImpl` supports algorithm constraints now. See #25016 for details.

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 322:

> 320:                 // and just call the functionally limited
> 321:                 // javax.net.ssl.X509KeyManager.chooseServerAlias(...)
> 322:                 if (km instanceof X509KeyManagerImpl xkm) {

Same as above, `SunX509KeyManagerImp`l supports algorithm constraints now. See https://github.com/openjdk/jdk/pull/25016 for details.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288503211
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288505103

From ihse at openjdk.org  Wed Aug 20 15:19:42 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 15:19:42 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>

On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   after suggestion from Daniel

doc/testing.md line 385:

> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
> 384: certain amount of time will apply this factor. If we run in
> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)

I don't think there is any point linking to the build source code. 

Suggestion:

certain amount of time will apply this factor. If you run in
forced compilation mode (`-Xcomp`) using `make test`, it
will automatically adjust this factor to compensate for the
interpreter not being as fast as JITed code. Defaults to 1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288510800

From abarashev at openjdk.org  Wed Aug 20 15:22:04 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 20 Aug 2025 15:22:04 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
Message-ID: <rZ8PCa5UY337NRqlW1dC1UdQUYXlT9NiRezCT3X5Xkw=.be5fdc48-6848-4558-94ee-7ffa2a38a1ba@github.com>

On Wed, 20 Aug 2025 13:55:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
> 
>  - merge latest changes from master branch
>  - merge latest http3 changes
>  - Hide internal classes
>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>  - quic: remove unused fields
>  - Make final fields static
>  - Remove unused variable
>  - merge latest changes from master branch
>  - http3: update summary in H3SimpleTest.java
>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 1:

> 1: /*

Consider adding `chooseClientAlias` and `chooseServerAlias` methods for `quicTLSEngine` to the default SunX509 key manager which now supports algorithm constraints.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288514104

From ihse at openjdk.org  Wed Aug 20 15:24:39 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 15:24:39 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>

On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   after suggestion from Daniel

It seems to me like there is a need to automatically collect normal test run times automatically, so we can match the timeout given to any individual test with the normal execution time. After all, the purpose of any timeout on tests is to allow the test to execute normally, but not wait too long in case of a problem that causes the test to take too long (or forever) to run.

I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, and very slow tests maybe take 15 minutes on fast machines and 40 minutes on slow. In the first case, anything above 15 seconds is probably sus, and in the second case, anything above 60 is probably not good either (I'm just adding 50% to the max time). 

Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3206865824

From abarashev at openjdk.org  Wed Aug 20 15:36:03 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 20 Aug 2025 15:36:03 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
Message-ID: <oiifer9a57vZpTmTR-Ks4gvvG4t2jzVbJWQ80toqNow=.9f4aaf31-9d4c-48d2-a67a-5c4c401c5862@github.com>

On Wed, 20 Aug 2025 13:55:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
> 
>  - merge latest changes from master branch
>  - merge latest http3 changes
>  - Hide internal classes
>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>  - quic: remove unused fields
>  - Make final fields static
>  - Remove unused variable
>  - merge latest changes from master branch
>  - http3: update summary in H3SimpleTest.java
>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9

src/java.base/share/classes/sun/security/ssl/Alert.java line 1:

> 1: /*

Copyright year.

src/java.base/share/classes/sun/security/ssl/AlpnExtension.java line 1:

> 1: /*

Copyright year.

src/java.base/share/classes/sun/security/ssl/OutputRecord.java line 1:

> 1: /*

Copyright year.

src/java.base/share/classes/sun/security/ssl/QuicEngineOutputRecord.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022, 2024, Oracle and/or its affiliates. All rights reserved.

Copyright year.

src/java.base/share/classes/sun/security/ssl/QuicTransportParametersExtension.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022, 2024, Oracle and/or its affiliates. All rights reserved.

Copyright year.

src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java line 1:

> 1: /*

Copyright year.

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 1:

> 1: /*

Copyright year.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288548443
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288549545
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288551390
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288552162
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288540217
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288545232
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288546200

From abarashev at openjdk.org  Wed Aug 20 15:48:08 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 20 Aug 2025 15:48:08 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <cG44tMLYSCLxUQv4RW-dzqRDkhA1piD2T5fMPdAzuTI=.e9423d38-5cbd-497d-8b8d-21a28924bee2@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
 <cG44tMLYSCLxUQv4RW-dzqRDkhA1piD2T5fMPdAzuTI=.e9423d38-5cbd-497d-8b8d-21a28924bee2@github.com>
Message-ID: <wOe3xzANENy0UGHztrX6Ofb846BBPGJP-W-wMggpnqc=.4958f040-9192-431b-9ce0-2b3c99bfd06c@github.com>

On Wed, 20 Aug 2025 15:14:01 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
>> 
>>  - merge latest changes from master branch
>>  - merge latest http3 changes
>>  - Hide internal classes
>>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>>  - quic: remove unused fields
>>  - Make final fields static
>>  - Remove unused variable
>>  - merge latest changes from master branch
>>  - http3: update summary in H3SimpleTest.java
>>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9
>
> src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 229:
> 
>> 227:             // just call the functionally limited
>> 228:             // javax.net.ssl.X509KeyManager.chooseClientAlias(...)
>> 229:             if (km instanceof X509KeyManagerImpl xkm) {
> 
> We no longer need a special case for `X509KeyManagerImpl` as `SunX509KeyManagerImpl` supports algorithm constraints now. See #25016 for details.

Correction: We can add `chooseClientAlias` and `chooseServerAlias` methods for quicTLSEngine to the default SunX509 key manager and then do `km instanceof X509KeyManagerCertChecking` check here instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288583324

From jpai at openjdk.org  Wed Aug 20 16:25:10 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 20 Aug 2025 16:25:10 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <JeKINmYcmLWz8AVolTvNOTzymhXNuV6w2mguL6VAJYg=.7f38e31b-5a56-48bf-b72e-63f829175234@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <JeKINmYcmLWz8AVolTvNOTzymhXNuV6w2mguL6VAJYg=.7f38e31b-5a56-48bf-b72e-63f829175234@github.com>
Message-ID: <jsG4kdvqj5b_S-jQPeHrGRv24QmdwdsALM-8_Svsc6M=.b121460f-8808-47b1-aff9-4a79f94883f1@github.com>

On Thu, 26 Jun 2025 18:06:03 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.base/share/classes/sun/security/ssl/Finished.java line 852:
> 
>> 850:                     QuicTLSEngineImpl engine =
>> 851:                             (QuicTLSEngineImpl) shc.conContext.transport;
>> 852:                     engine.deriveOneRTTKeys();
> 
> We should not derive the server's 1RTT read keys before processing the client's Finished message.
> 
> Also, we could skip calculating the SSL WriteCipher when QUIC is in use. Also, we're calculating the baseWriteSecret twice (deriveOneRTTKeys calculates the same secret)

We decided to do this as a follow up after the JEP is integrated. In the meantime, in https://github.com/openjdk/jdk/pull/24751/commits/8d22ca7334da8d8b49d0634ea2f23bd409613928, we now introduce a check where the endpoint doesn't decrypt an incoming 1-RTT packet until the TLS handshake is complete. This matches with what the RFC-9001 specifies.

@dfuch, @djelinski I think we can mark this conversation as resolved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288675780

From lkorinth at openjdk.org  Wed Aug 20 16:27:39 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 16:27:39 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
Message-ID: <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>

On Wed, 20 Aug 2025 15:17:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   after suggestion from Daniel
>
> doc/testing.md line 385:
> 
>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>> 384: certain amount of time will apply this factor. If we run in
>> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
> 
> I don't think there is any point linking to the build source code. 
> 
> Suggestion:
> 
> certain amount of time will apply this factor. If you run in
> forced compilation mode (`-Xcomp`) using `make test`, it
> will automatically adjust this factor to compensate for the
> interpreter not being as fast as JITed code. Defaults to 1.

I will remove the link, and I will update my bad text still talking about the interpreter (sorry for that mistake).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288683592

From lkorinth at openjdk.org  Wed Aug 20 17:05:59 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 17:05:59 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

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

  update testing.md, remove makefile link, fix bad text

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/286a2cc6..f24a1e72

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

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

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

From lkorinth at openjdk.org  Wed Aug 20 17:05:59 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 17:05:59 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
 <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>
Message-ID: <2Ba-EiFMVh1-nMHcihw93nZq-TkQNtvHc244Bwe8I40=.cfa54a17-0a3f-465d-a1c3-7560965376d7@github.com>

On Wed, 20 Aug 2025 16:24:43 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> doc/testing.md line 385:
>> 
>>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>>> 384: certain amount of time will apply this factor. If we run in
>>> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
>> 
>> I don't think there is any point linking to the build source code. 
>> 
>> Suggestion:
>> 
>> certain amount of time will apply this factor. If you run in
>> forced compilation mode (`-Xcomp`) using `make test`, it
>> will automatically adjust this factor to compensate for the
>> interpreter not being as fast as JITed code. Defaults to 1.
>
> I will remove the link, and I will update my bad text still talking about the interpreter (sorry for that mistake).

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288793081

From dfuchs at openjdk.org  Wed Aug 20 17:14:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Aug 2025 17:14:55 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <jsG4kdvqj5b_S-jQPeHrGRv24QmdwdsALM-8_Svsc6M=.b121460f-8808-47b1-aff9-4a79f94883f1@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <JeKINmYcmLWz8AVolTvNOTzymhXNuV6w2mguL6VAJYg=.7f38e31b-5a56-48bf-b72e-63f829175234@github.com>
 <jsG4kdvqj5b_S-jQPeHrGRv24QmdwdsALM-8_Svsc6M=.b121460f-8808-47b1-aff9-4a79f94883f1@github.com>
Message-ID: <CL4ae3Ugh4Kyjq8904lR4mY-Wm8H5JdGzAnCuqOiMF0=.0b9603ab-e468-47a4-adb6-da848b69f46a@github.com>

On Wed, 20 Aug 2025 16:21:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/Finished.java line 852:
>> 
>>> 850:                     QuicTLSEngineImpl engine =
>>> 851:                             (QuicTLSEngineImpl) shc.conContext.transport;
>>> 852:                     engine.deriveOneRTTKeys();
>> 
>> We should not derive the server's 1RTT read keys before processing the client's Finished message.
>> 
>> Also, we could skip calculating the SSL WriteCipher when QUIC is in use. Also, we're calculating the baseWriteSecret twice (deriveOneRTTKeys calculates the same secret)
>
> We decided to do this as a follow up after the JEP is integrated. In the meantime, in https://github.com/openjdk/jdk/pull/24751/commits/8d22ca7334da8d8b49d0634ea2f23bd409613928, we now introduce a check where the endpoint doesn't decrypt an incoming 1-RTT packet until the TLS handshake is complete. This matches with what the RFC-9001 specifies.
> 
> @dfuch, @djelinski I think we can mark this conversation as resolved.

Logged as https://bugs.openjdk.org/browse/JDK-8365872 (thanks @jaikiran)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288810658

From abarashev at openjdk.org  Wed Aug 20 18:13:58 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 20 Aug 2025 18:13:58 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
Message-ID: <tkKRHU9wJYvRzrMhMlEodUGE6wFwIt1lH7dN_NyCgEA=.18f8f0a6-b503-4500-b444-6c562e81316c@github.com>

On Wed, 20 Aug 2025 13:55:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
> 
>  - merge latest changes from master branch
>  - merge latest http3 changes
>  - Hide internal classes
>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>  - quic: remove unused fields
>  - Make final fields static
>  - Remove unused variable
>  - merge latest changes from master branch
>  - http3: update summary in H3SimpleTest.java
>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9

src/java.base/share/classes/sun/security/ssl/ServerHello.java line 800:

> 798:             // a ServerHello or a HelloRetryRequest.
> 799:             // (RFC 8446, Appendix D.4)
> 800:             if (clientHello.sessionId.length() != 0) {

What's the reason for this change? A short comment would be helpful.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2288932593

From ihse at openjdk.org  Wed Aug 20 19:36:44 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 19:36:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <Pw1uYaqAPK95BsoZ0xgNA1c3rsXjxHCiz-xACzocwqA=.e6cb7fcf-4438-4e4a-aeef-7d9c707c87c8@github.com>

On Wed, 20 Aug 2025 17:05:59 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update testing.md, remove makefile link, fix bad text

Build changes look good now. Thanks!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3137980952

From dholmes at openjdk.org  Wed Aug 20 21:32:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 21:32:39 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
Message-ID: <j5ndr4sR6OHgBGlCY-e1I-VdfMKpG2GS98Wv2qbshtU=.d5aad200-1bc2-4080-ad71-218c59a7e491@github.com>

On Wed, 20 Aug 2025 15:21:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, 

@magicus unfortunately that is often not the case in practice. We can see many tests that normally run very quickly but occasionally run very slow - minutes versus seconds.

> Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

For this exercise existing explicit timeout values need to be multiplied by 4 to keep the same absolute timeout value. In addition a number of tests that use the implicit default timeout (120*4) now need an explicit timeout (480 generally).

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3208143195

From lkorinth at openjdk.org  Thu Aug 21 09:12:57 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 21 Aug 2025 09:12:57 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnXjSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
 <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnX
 jSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>
Message-ID: <aIb4Lxc_k84vVIu_ljTy8TaLkNu4yJTc_7eZYXW_IUQ=.d64a48ff-0c38-4d81-8100-f1d330e2d7dd@github.com>

On Wed, 20 Aug 2025 14:25:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> @sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.
>
> Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.
> 
> So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).
> 
> I do agree this change, what I mean is this change has some side effect.
> 
>> If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.
> 
> I think I can try it in a new PR.

I want to _warn_ you before you put too much energy into it. Changing the `-Xcomp` timeout factor might have even bigger impact than my change. Also, I have no idea how well that flag is tested in open testing. That is, your change might look good for you --- but might cause havoc for companies doing more extensive testing.

I have still not received green light for integrating my change, because extensive testing is still being run (and other teams are evaluating). I advise against changing the flag. When I evaluate the benefit for the default timeout, it was mainly not the timeout _in itself_ that was the problem, but the fact that most people have no idea that the timeout factor is applied and thus can not create or debug tests in a good way. I hope this helps you, and does not come out as too negative. I just feel that I have put too much energy into this, and I do not hope that struggle for you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2290422272

From djelinski at openjdk.org  Thu Aug 21 09:34:16 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 21 Aug 2025 09:34:16 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <tkKRHU9wJYvRzrMhMlEodUGE6wFwIt1lH7dN_NyCgEA=.18f8f0a6-b503-4500-b444-6c562e81316c@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
 <tkKRHU9wJYvRzrMhMlEodUGE6wFwIt1lH7dN_NyCgEA=.18f8f0a6-b503-4500-b444-6c562e81316c@github.com>
Message-ID: <R_QTo5j8S7_FiSoTvGNFQij-CxwdYf87ZPKeN5ywFcc=.b5d1da62-4942-4b83-99f9-6be065b0ebd8@github.com>

On Wed, 20 Aug 2025 18:11:24 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
>> 
>>  - merge latest changes from master branch
>>  - merge latest http3 changes
>>  - Hide internal classes
>>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>>  - quic: remove unused fields
>>  - Make final fields static
>>  - Remove unused variable
>>  - merge latest changes from master branch
>>  - http3: update summary in H3SimpleTest.java
>>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9
>
> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 800:
> 
>> 798:             // a ServerHello or a HelloRetryRequest.
>> 799:             // (RFC 8446, Appendix D.4)
>> 800:             if (clientHello.sessionId.length() != 0) {
> 
> What's the reason for this change? A short comment would be helpful.

`changeWriteCiphers` changes the write cipher and may send a change_cipher_spec message. `encodeChangeCipherSpec` just sends the message without touching the write cipher.

TLS doesn't need to change the write ciphers when processing a HelloRetry; it's already using null cipher, and there are no keys we could use anyway. QUIC on the other hand encrypts initial packets, and switching to null cipher would be against the spec.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2290472769

From syan at openjdk.org  Thu Aug 21 09:52:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 21 Aug 2025 09:52:54 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <aIb4Lxc_k84vVIu_ljTy8TaLkNu4yJTc_7eZYXW_IUQ=.d64a48ff-0c38-4d81-8100-f1d330e2d7dd@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
 <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnX
 jSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>
 <aIb4Lxc_k84vVIu_ljTy8TaLkNu4yJTc_7eZYXW_IUQ=.d64a48ff-0c38-4d81-8100-f1d330e2d7dd@github.com>
Message-ID: <N_1V36WztAVi1O6SdDaGQXa4b8TGB7xGpz5T1TbxL9I=.ea0293e3-eb0b-4d96-bd40-d5c9c4e3fd1d@github.com>

On Thu, 21 Aug 2025 09:10:26 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.
>> 
>> So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).
>> 
>> I do agree this change, what I mean is this change has some side effect.
>> 
>>> If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.
>> 
>> I think I can try it in a new PR.
>
> I want to _warn_ you before you put too much energy into it. Changing the `-Xcomp` timeout factor might have even bigger impact than my change. Also, I have no idea how well that flag is tested in open testing. That is, your change might look good for you --- but might cause havoc for companies doing more extensive testing.
> 
> I have still not received green light for integrating my change, because extensive testing is still being run (and other teams are evaluating). I advise against changing the flag. When I evaluate the benefit for the default timeout, it was mainly not the timeout _in itself_ that was the problem, but the fact that most people have no idea that the timeout factor is applied and thus can not create or debug tests in a good way. I hope this helps you, and does not come out as too negative. I just feel that I have put too much energy into this, and I do not hope that struggle for you.

@lkorinth Thanks for your advice sincerely. I think you are right, we need more evaluate cautiously before start to change the timeoutFactor for -Xcomp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2290523415

From ihse at openjdk.org  Thu Aug 21 12:21:00 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 21 Aug 2025 12:21:00 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
Message-ID: <zgu5mLb1mA-ca4wxmJJjLNmmq3sJFwWtfjY4yRnmYFQ=.81a024ea-41ce-42cc-9038-3ef40e483793@github.com>

On Wed, 20 Aug 2025 15:21:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   after suggestion from Daniel
>
> It seems to me like there is a need to automatically collect normal test run times automatically, so we can match the timeout given to any individual test with the normal execution time. After all, the purpose of any timeout on tests is to allow the test to execute normally, but not wait too long in case of a problem that causes the test to take too long (or forever) to run.
> 
> I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, and very slow tests maybe take 15 minutes on fast machines and 40 minutes on slow. In the first case, anything above 15 seconds is probably sus, and in the second case, anything above 60 is probably not good either (I'm just adding 50% to the max time). 
> 
> Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

> @magicus unfortunately that is often not the case in practice. We can see many tests that normally run very quickly but occasionally run very slow - minutes versus seconds.

That is surprising and a bit disappointing. I guess it is not worth the effort to try and figure out why this is the case; it could probably vary from test to test and be difficult to track for little gain. Still, it makes you wonder.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3210365303

From heidinga at openjdk.org  Thu Aug 21 15:51:55 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Thu, 21 Aug 2025 15:51:55 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
In-Reply-To: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
Message-ID: <oKv3C0h-ga-CTv4ZoBBDfwNWMGo2mjsSozMubdHCf8o=.2d60e196-443c-4547-bfb4-89cf6c4dbc2f@github.com>

On Thu, 17 Jul 2025 22:38:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. 
> 
> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`.
> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved.
> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java.

src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 96:

> 94:   // later in load_javabase_classes() and load_non_javabase_classes().
> 95:   preload_classes_in_table(AOTLinkedClassTable::for_static_archive()->boot1(), "boot1", Handle(), CHECK);
> 96:   preload_classes_in_table(AOTLinkedClassTable::for_static_archive()->boot2(), "boot2", Handle(), CHECK);

why do we maintain both a `boot1` and `boot2` set here when both are loaded before executing any Java code?  Is the distinction meaningful for preloaded classes given both are loaded into the same classloader?

src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 127:

> 125:           precond(ik->local_interfaces()->at(i)->is_loaded());
> 126:         }
> 127:       });

This debugging check is duplicated in `SystemDictionary::preload_class` in the `#ifdef ASSERT` block.

src/hotspot/share/cds/cdsHeapVerifier.cpp line 241:

> 239:           }
> 240:           if (field_ik == vmClasses::Boolean_klass()) {
> 241:             // TODO: check if is TRUE or FALSE

Are we canonicalizing Boolean.TRUE & Boolean.FALSE and thus don't care if a static field points to them?  And Boolean.TYPE isn't getting the same treatment?

src/hotspot/share/classfile/javaClasses.cpp line 1017:

> 1015: void java_lang_Class::set_mirror_module_field(JavaThread* current, Klass* k, Handle mirror, Handle module) {
> 1016:   if (CDSConfig::is_using_preloaded_classes()) {
> 1017:     oop archived_module = java_lang_Class:: module(mirror());

Suggestion:

    oop archived_module = java_lang_Class::module(mirror());

src/java.base/share/classes/java/net/URL.java line 1768:

> 1766: 
> 1767:     @AOTRuntimeSetup
> 1768:     private static void runtimeSetup() {

Slightly concerned with this for reasons I'm still trying to track down - Mostly around the `URLStreamHandler` that each URL instance holds onto.

Can we create cases were the cached URLStreamHandler for a URL from the assembly phase would be different than the URLStreamHandler looked up in the production run?

src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 407:

> 405:     static class Holder {
> 406:         // All native libraries we've loaded.
> 407:         private static final Set<String> loadedLibraryNames =

I'm concerned about this causing problems if we ever AOT initialize a user class that calls `System.loadLibrary` from its static initializer.

Should we add a check to the `clear()` method above to ensure that only the expected libraries have been loaded during the assembly phase?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2283111220
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2283328974
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2283162998
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2283173361
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2283406179
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2291474398

From heidinga at openjdk.org  Thu Aug 21 15:51:55 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Thu, 21 Aug 2025 15:51:55 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
In-Reply-To: <oKv3C0h-ga-CTv4ZoBBDfwNWMGo2mjsSozMubdHCf8o=.2d60e196-443c-4547-bfb4-89cf6c4dbc2f@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
 <oKv3C0h-ga-CTv4ZoBBDfwNWMGo2mjsSozMubdHCf8o=.2d60e196-443c-4547-bfb4-89cf6c4dbc2f@github.com>
Message-ID: <Fq4GP2D102v1eUpS6wCTR6D55-dJC4pUvHwpkX42-c8=.bded367b-685d-4582-a255-3b9a4de63912@github.com>

On Mon, 18 Aug 2025 20:33:45 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. 
>> 
>> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`.
>> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved.
>> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java.
>
> src/java.base/share/classes/java/net/URL.java line 1768:
> 
>> 1766: 
>> 1767:     @AOTRuntimeSetup
>> 1768:     private static void runtimeSetup() {
> 
> Slightly concerned with this for reasons I'm still trying to track down - Mostly around the `URLStreamHandler` that each URL instance holds onto.
> 
> Can we create cases were the cached URLStreamHandler for a URL from the assembly phase would be different than the URLStreamHandler looked up in the production run?

Are there limits on the types of URLs we allow in the archived heap?  ie: only file or jar?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2288785484

From iklam at openjdk.org  Fri Aug 22 04:13:55 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 22 Aug 2025 04:13:55 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
In-Reply-To: <oKv3C0h-ga-CTv4ZoBBDfwNWMGo2mjsSozMubdHCf8o=.2d60e196-443c-4547-bfb4-89cf6c4dbc2f@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
 <oKv3C0h-ga-CTv4ZoBBDfwNWMGo2mjsSozMubdHCf8o=.2d60e196-443c-4547-bfb4-89cf6c4dbc2f@github.com>
Message-ID: <-as-u0Rcw01OFd4d-huLpncQoxCv1T04qiU8ol8wCic=.9093ccfc-b316-40a8-9fb8-72c96c59536b@github.com>

On Mon, 18 Aug 2025 18:11:11 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. 
>> 
>> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`.
>> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved.
>> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java.
>
> src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 96:
> 
>> 94:   // later in load_javabase_classes() and load_non_javabase_classes().
>> 95:   preload_classes_in_table(AOTLinkedClassTable::for_static_archive()->boot1(), "boot1", Handle(), CHECK);
>> 96:   preload_classes_in_table(AOTLinkedClassTable::for_static_archive()->boot2(), "boot2", Handle(), CHECK);
> 
> why do we maintain both a `boot1` and `boot2` set here when both are loaded before executing any Java code?  Is the distinction meaningful for preloaded classes given both are loaded into the same classloader?

This is still meaningful as the `boot1` classes from the dynamic CDS archive are still loaded at the end of `vmClasses::resolve_all()`, after some bytecodes are executed.

> src/hotspot/share/cds/cdsHeapVerifier.cpp line 241:
> 
>> 239:           }
>> 240:           if (field_ik == vmClasses::Boolean_klass()) {
>> 241:             // TODO: check if is TRUE or FALSE
> 
> Are we canonicalizing Boolean.TRUE & Boolean.FALSE and thus don't care if a static field points to them?  And Boolean.TYPE isn't getting the same treatment?

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2292643055
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2292643019

From iklam at openjdk.org  Fri Aug 22 04:19:52 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 22 Aug 2025 04:19:52 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
In-Reply-To: <Fq4GP2D102v1eUpS6wCTR6D55-dJC4pUvHwpkX42-c8=.bded367b-685d-4582-a255-3b9a4de63912@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
 <oKv3C0h-ga-CTv4ZoBBDfwNWMGo2mjsSozMubdHCf8o=.2d60e196-443c-4547-bfb4-89cf6c4dbc2f@github.com>
 <Fq4GP2D102v1eUpS6wCTR6D55-dJC4pUvHwpkX42-c8=.bded367b-685d-4582-a255-3b9a4de63912@github.com>
Message-ID: <AqxYu9LO9W1acrH6-I141NiI_ZQtvTTnejs3YA6lAAg=.7ee0e783-823b-4269-aae0-c2e4085cc596@github.com>

On Wed, 20 Aug 2025 16:59:45 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/URL.java line 1768:
>> 
>>> 1766: 
>>> 1767:     @AOTRuntimeSetup
>>> 1768:     private static void runtimeSetup() {
>> 
>> Slightly concerned with this for reasons I'm still trying to track down - Mostly around the `URLStreamHandler` that each URL instance holds onto.
>> 
>> Can we create cases were the cached URLStreamHandler for a URL from the assembly phase would be different than the URLStreamHandler looked up in the production run?
>
> Are there limits on the types of URLs we allow in the archived heap?  ie: only file or jar?

This code basically adds an entrypoint in the `SharedSecrets` class for other JDK core lib classes to call into package-private API in this package. It doesn't do anything else.

There are several other classes where we have to do the same `SharedSecrets` set-up.


    @AOTRuntimeSetup
    private static void runtimeSetup() {
        SharedSecrets.setJavaNetURLAccess(
                new JavaNetURLAccess() {
                    @Override
                    public URLStreamHandler getHandler(URL u) {
                        return u.handler;
                    }
                }
        );
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2292648610

From iklam at openjdk.org  Fri Aug 22 04:54:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 22 Aug 2025 04:54:41 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
 [v2]
In-Reply-To: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
Message-ID: <KlMmd18eQ498iYSHH5aG04H2XmWkMVI0NqZeYg_o7OE=.1e41f9c4-f2c1-4619-9d90-db3e8a97edd4@github.com>

> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. 
> 
> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`.
> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved.
> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java.

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

  @DanHeidinga comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26375/files
  - new: https://git.openjdk.org/jdk/pull/26375/files/15746239..b7a191d8

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

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

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

From iklam at openjdk.org  Fri Aug 22 04:54:42 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 22 Aug 2025 04:54:42 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
 [v2]
In-Reply-To: <oKv3C0h-ga-CTv4ZoBBDfwNWMGo2mjsSozMubdHCf8o=.2d60e196-443c-4547-bfb4-89cf6c4dbc2f@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
 <oKv3C0h-ga-CTv4ZoBBDfwNWMGo2mjsSozMubdHCf8o=.2d60e196-443c-4547-bfb4-89cf6c4dbc2f@github.com>
Message-ID: <hWDWxca2fjhNLwzEj6R6wFqiP7EeY26xzVulRClX3ws=.871fcbf4-d85f-458e-a30e-6a049cca8195@github.com>

On Mon, 18 Aug 2025 20:00:40 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @DanHeidinga comments
>
> src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 127:
> 
>> 125:           precond(ik->local_interfaces()->at(i)->is_loaded());
>> 126:         }
>> 127:       });
> 
> This debugging check is duplicated in `SystemDictionary::preload_class` in the `#ifdef ASSERT` block.

I removed this check.

> src/hotspot/share/classfile/javaClasses.cpp line 1017:
> 
>> 1015: void java_lang_Class::set_mirror_module_field(JavaThread* current, Klass* k, Handle mirror, Handle module) {
>> 1016:   if (CDSConfig::is_using_preloaded_classes()) {
>> 1017:     oop archived_module = java_lang_Class:: module(mirror());
> 
> Suggestion:
> 
>     oop archived_module = java_lang_Class::module(mirror());

Fixed.

> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 407:
> 
>> 405:     static class Holder {
>> 406:         // All native libraries we've loaded.
>> 407:         private static final Set<String> loadedLibraryNames =
> 
> I'm concerned about this causing problems if we ever AOT initialize a user class that calls `System.loadLibrary` from its static initializer.
> 
> Should we add a check to the `clear()` method above to ensure that only the expected libraries have been loaded during the assembly phase?

The assembly phase shouldn't execute any user Java code. If that happens, it can result in many undesirable side effects. Loading user native library will be just one example.

I think we need a stronger check -- make sure that no user classes are initialized at the end of the assembly phase. This check should be sufficient because executing code in any class will result in its initialization.

Maybe I should do that in a separate RFE?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2292686203
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2292686311
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2292684206

From prr at openjdk.org  Fri Aug 22 05:54:55 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 05:54:55 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>

On Wed, 20 Aug 2025 17:05:59 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update testing.md, remove makefile link, fix bad text

test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50:

> 48:  * @summary URL.getContent() should return SoundClip for supported formats
> 49:  * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers
> 50:  */

I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds)
Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what  I think (120) is the default to 480.
Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2292765283

From dholmes at openjdk.org  Fri Aug 22 06:38:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 22 Aug 2025 06:38:56 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
Message-ID: <GGszb14v2jX1mI4BbHtgkXQDlgFehKYtLl3yUr0zX40=.1952e76e-0a5c-4be9-944a-505f84d89624@github.com>

On Fri, 22 Aug 2025 05:51:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50:
> 
>> 48:  * @summary URL.getContent() should return SoundClip for supported formats
>> 49:  * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers
>> 50:  */
> 
> I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds)
> Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what  I think (120) is the default to 480.
> Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough.

@prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2292836043

From heidinga at openjdk.org  Fri Aug 22 14:09:51 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 22 Aug 2025 14:09:51 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
 [v2]
In-Reply-To: <AqxYu9LO9W1acrH6-I141NiI_ZQtvTTnejs3YA6lAAg=.7ee0e783-823b-4269-aae0-c2e4085cc596@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
 <oKv3C0h-ga-CTv4ZoBBDfwNWMGo2mjsSozMubdHCf8o=.2d60e196-443c-4547-bfb4-89cf6c4dbc2f@github.com>
 <Fq4GP2D102v1eUpS6wCTR6D55-dJC4pUvHwpkX42-c8=.bded367b-685d-4582-a255-3b9a4de63912@github.com>
 <AqxYu9LO9W1acrH6-I141NiI_ZQtvTTnejs3YA6lAAg=.7ee0e783-823b-4269-aae0-c2e4085cc596@github.com>
Message-ID: <9vSAjwAVs4fC86ZLDThWO411Lx_kcLxmnNZrfqNUR20=.25aebeda-c7a2-4303-b469-7664d4a9ecdf@github.com>

On Fri, 22 Aug 2025 04:16:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Are there limits on the types of URLs we allow in the archived heap?  ie: only file or jar?
>
> This code basically adds an entrypoint in the `SharedSecrets` class for other JDK core lib classes to call into package-private API in this package. It doesn't do anything else.
> 
> There are several other classes where we have to do the same `SharedSecrets` set-up.
> 
> 
>     @AOTRuntimeSetup
>     private static void runtimeSetup() {
>         SharedSecrets.setJavaNetURLAccess(
>                 new JavaNetURLAccess() {
>                     @Override
>                     public URLStreamHandler getHandler(URL u) {
>                         return u.handler;
>                     }
>                 }
>         );
>     }

I'm less worried about this particular `runtimeSetup` implementation and more with what it implies.  Namely that we have URL instances - with particular URLStreamHandlers associated with them - running around in the archived heap.  If in production, a different URLStreamHandler is configured for a given URL, we'll get two different sets of validation logic for assembly time URLs vs production run URLs.

Are we able to limit the protocols that we create URLs for?  I'm reaching for some way to contain the potential issue to something smaller that we can reason about

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2293839048

From heidinga at openjdk.org  Fri Aug 22 14:12:54 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 22 Aug 2025 14:12:54 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
 [v2]
In-Reply-To: <hWDWxca2fjhNLwzEj6R6wFqiP7EeY26xzVulRClX3ws=.871fcbf4-d85f-458e-a30e-6a049cca8195@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
 <oKv3C0h-ga-CTv4ZoBBDfwNWMGo2mjsSozMubdHCf8o=.2d60e196-443c-4547-bfb4-89cf6c4dbc2f@github.com>
 <hWDWxca2fjhNLwzEj6R6wFqiP7EeY26xzVulRClX3ws=.871fcbf4-d85f-458e-a30e-6a049cca8195@github.com>
Message-ID: <ltm75pGvL0GITWbubirMNqlDy17NI45xfa2nxRDGZCg=.a701a33f-6b43-432a-9b6d-d5e254f80cf4@github.com>

On Fri, 22 Aug 2025 04:49:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I think we need a stronger check -- make sure that no user classes are initialized at the end of the assembly phase. This check should be sufficient because executing code in any class will result in its initialization.

That would be a good check.

Do we still assembly-time initialize Enums?  I thought in earlier implementations we had initialized all enum classes but I'm having trouble finding the code now.  If we do, the new "no user class initialized" check may fail on Enums

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2293846625

From ayang at openjdk.org  Fri Aug 22 16:10:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 22 Aug 2025 16:10:58 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>

On Wed, 20 Aug 2025 17:05:59 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update testing.md, remove makefile link, fix bad text

> Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480.

I identified some cases that doesn't follow this. Unclear whether they are intentional.

test/hotspot/jtreg/compiler/tiered/Level2RecompilationTest.java line 36:

> 34:  * @build jdk.test.whitebox.WhiteBox
> 35:  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
> 36:  * @run main/othervm/timeout=960 -Xbootclasspath/a:. -XX:+TieredCompilation

Why not `480` in this case?

test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java line 40:

> 38:  * @requires vm.cds
> 39:  * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds
> 40:  * @run driver/timeout=8000 LotsOfSyntheticClasses

I was expecting `500 * 4 = 2000`, instead of `8000` here.

test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java line 31:

> 29:  * @compile SuspendResume2.java
> 30:  * @run driver jdk.test.lib.FileInstaller . .
> 31:  * @run main/othervm/native/timeout=700

Why `700` instead of `480` in this file?

test/jdk/java/rmi/transport/dgcDeadLock/DGCDeadLock.java line 59:

> 57: public class DGCDeadLock implements Runnable {
> 58:     final static public int HOLD_TARGET_TIME = 25000;
> 59:     public static final double TEST_FAIL_TIME = (HOLD_TARGET_TIME + 30000) * Math.max(TestLibrary.getTimeoutFactor(), 4);

Why `max(...)`? If it's for backwards compatibility, shouldn't it be `(HOLD_TARGET_TIME + 30000)  * 4 * TestLibrary.getTimeoutFactor()`?

test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 60:

> 58:  * @comment skip running this test on 32 bit VM
> 59:  * @requires vm.bits == "64"
> 60:  * @run testng/othervm/timeout=960 -Xmx2g WhiteBoxResizeTest

Why not `480`?

test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java line 34:

> 32:  * @build com.foobar.Utils
> 33:  *        com.bar.*
> 34:  * @run junit/othervm/timeout=960 -Djava.locale.providers=CLDR,SPI LocaleNameProviderTest

Why not `480`?

test/jdk/jdk/jfr/event/oldobject/TestObjectDescription.java line 49:

> 47:  * @library /test/lib /test/jdk
> 48:  * @modules jdk.jfr/jdk.jfr.internal.test
> 49:  * @run main/othervm/timeout=960 -XX:TLABSize=2k jdk.jfr.event.oldobject.TestObjectDescription

Why not `480`?

test/jdk/tools/jpackage/share/InstallDirTest.java line 69:

> 67:  * @compile -Xlint:all -Werror InstallDirTest.java
> 68:  * @requires (jpackage.test.SQETest != null)
> 69:  * @run main/othervm/timeout=4000 -Xmx512m jdk.jpackage.test.Main

Why more than `4x` in this file?

test/langtools/jdk/jshell/HangingRemoteAgent.java line 38:

> 36: class HangingRemoteAgent extends RemoteExecutionControl {
> 37: 
> 38:     private static final int TIMEOUT = (int)(2000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));

why not `Utils.TIMEOUT_FACTOR`?

test/langtools/jdk/jshell/UITesting.java line 148:

> 146:     }
> 147: 
> 148:     private static final long TIMEOUT = (long) (60_000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));

Why not `Utils.TIMEOUT_FACTOR`?

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

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3144985957
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294077875
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294085201
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294089550
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294108202
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294110136
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294113670
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294116148
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294119800
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294128741
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294129243

From prr at openjdk.org  Fri Aug 22 17:20:57 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 17:20:57 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
Message-ID: <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>

On Fri, 22 Aug 2025 05:51:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50:
> 
>> 48:  * @summary URL.getContent() should return SoundClip for supported formats
>> 49:  * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers
>> 50:  */
> 
> I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds)
> Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what  I think (120) is the default to 480.
> Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough.

> @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.

I don't agree.
If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.

I am also questioning whether such a time out was demonstrated for this test.
I've searched the entire history of CI jobs and I don't see where Leo had such a timeout of this test.
I can send you my query off-line so you can check it. Maybe it is incomplete.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294258341

From iklam at openjdk.org  Fri Aug 22 17:24:18 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 22 Aug 2025 17:24:18 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
 [v3]
In-Reply-To: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
Message-ID: <FpZVp2FE1d29D9C8N_VN1EkI1nTMapg4VRoUWxd575U=.c910bba1-0343-4788-966a-12b5bb04755d@github.com>

> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. 
> 
> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`.
> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved.
> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java.

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

  @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26375/files
  - new: https://git.openjdk.org/jdk/pull/26375/files/b7a191d8..ecc2581d

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

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

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

From iklam at openjdk.org  Fri Aug 22 17:24:18 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 22 Aug 2025 17:24:18 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
 [v3]
In-Reply-To: <9vSAjwAVs4fC86ZLDThWO411Lx_kcLxmnNZrfqNUR20=.25aebeda-c7a2-4303-b469-7664d4a9ecdf@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
 <oKv3C0h-ga-CTv4ZoBBDfwNWMGo2mjsSozMubdHCf8o=.2d60e196-443c-4547-bfb4-89cf6c4dbc2f@github.com>
 <Fq4GP2D102v1eUpS6wCTR6D55-dJC4pUvHwpkX42-c8=.bded367b-685d-4582-a255-3b9a4de63912@github.com>
 <AqxYu9LO9W1acrH6-I141NiI_ZQtvTTnejs3YA6lAAg=.7ee0e783-823b-4269-aae0-c2e4085cc596@github.com>
 <9vSAjwAVs4fC86ZLDThWO411Lx_kcLxmnNZrfqNUR20=.25aebeda-c7a2-4303-b469-7664d4a9ecdf@github.com>
Message-ID: <UIF1IKu3P-MJgCilBZ9mB35AKCmk0dKRKM8Es_pzAWM=.374e2132-d75a-415c-8d4b-a6db7456f175@github.com>

On Fri, 22 Aug 2025 14:07:43 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> This code basically adds an entrypoint in the `SharedSecrets` class for other JDK core lib classes to call into package-private API in this package. It doesn't do anything else.
>> 
>> There are several other classes where we have to do the same `SharedSecrets` set-up.
>> 
>> 
>>     @AOTRuntimeSetup
>>     private static void runtimeSetup() {
>>         SharedSecrets.setJavaNetURLAccess(
>>                 new JavaNetURLAccess() {
>>                     @Override
>>                     public URLStreamHandler getHandler(URL u) {
>>                         return u.handler;
>>                     }
>>                 }
>>         );
>>     }
>
> I'm less worried about this particular `runtimeSetup` implementation and more with what it implies.  Namely that we have URL instances - with particular URLStreamHandlers associated with them - running around in the archived heap.  If in production, a different URLStreamHandler is configured for a given URL, we'll get two different sets of validation logic for assembly time URLs vs production run URLs.
> 
> Are we able to limit the protocols that we create URLs for?  I'm reaching for some way to contain the potential issue to something smaller that we can reason about

I added a check that URLs can be cache only if they use the `file` and `jtr` protocols, whose `URLStreamHandlers` cannot be overridden by the application.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2294262042

From iklam at openjdk.org  Fri Aug 22 17:46:14 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 22 Aug 2025 17:46:14 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
 [v4]
In-Reply-To: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
Message-ID: <DUkbGBnMhTdT4C3XTMfkTSoSc0FIh_ybhjVS5gVccaI=.cc432fc0-4b99-46ce-a06a-0ab84798fb4c@github.com>

> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. 
> 
> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`.
> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved.
> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java.

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

  @DanHeidinga comment - add test: user enum types are not initialized in assembly phase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26375/files
  - new: https://git.openjdk.org/jdk/pull/26375/files/ecc2581d..f12ad484

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

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

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

From heidinga at openjdk.org  Fri Aug 22 18:17:54 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 22 Aug 2025 18:17:54 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
 [v3]
In-Reply-To: <FpZVp2FE1d29D9C8N_VN1EkI1nTMapg4VRoUWxd575U=.c910bba1-0343-4788-966a-12b5bb04755d@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
 <FpZVp2FE1d29D9C8N_VN1EkI1nTMapg4VRoUWxd575U=.c910bba1-0343-4788-966a-12b5bb04755d@github.com>
Message-ID: <7rnsi3yhHnntw61prYN3u-Br-Rt_wmSuIxW_AszuHQE=.25abb82a-baee-467b-93af-e8a138182f73@github.com>

On Fri, 22 Aug 2025 17:24:18 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. 
>> 
>> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`.
>> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved.
>> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run

src/hotspot/share/cds/aotOopChecker.cpp line 52:

> 50: // Make sure we are not caching objects with assumptions that can be violated in
> 51: // the production run.
> 52: void AOTOopChecker::check(oop obj) {

Should this also return a `bool` to indicate if the oop failed the check?  It would make it easier to bail out in the caller if the oop was bad.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2294377983

From iklam at openjdk.org  Fri Aug 22 18:35:47 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 22 Aug 2025 18:35:47 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
 [v5]
In-Reply-To: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
Message-ID: <pEUT7PfYv-8CBfDZd7wl832VYF-AyVpvwZZeZdXJZzo=.4abe9cc2-35c6-41bd-b847-8a12a2973ab8@github.com>

> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. 
> 
> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`.
> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved.
> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java.

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

  @DanHeidinga comments -- added comments and asserts about the handling of enums

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26375/files
  - new: https://git.openjdk.org/jdk/pull/26375/files/f12ad484..62014d4f

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

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

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

From iklam at openjdk.org  Fri Aug 22 18:35:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 22 Aug 2025 18:35:48 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
 [v3]
In-Reply-To: <7rnsi3yhHnntw61prYN3u-Br-Rt_wmSuIxW_AszuHQE=.25abb82a-baee-467b-93af-e8a138182f73@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
 <FpZVp2FE1d29D9C8N_VN1EkI1nTMapg4VRoUWxd575U=.c910bba1-0343-4788-966a-12b5bb04755d@github.com>
 <7rnsi3yhHnntw61prYN3u-Br-Rt_wmSuIxW_AszuHQE=.25abb82a-baee-467b-93af-e8a138182f73@github.com>
Message-ID: <pZOktx4T7Jb3GdVk1SndW6UuSmyIdzol7IMijV4QVIA=.1508fb0e-76ff-4b3d-8d79-b00667f3f6a4@github.com>

On Fri, 22 Aug 2025 18:15:28 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run
>
> src/hotspot/share/cds/aotOopChecker.cpp line 52:
> 
>> 50: // Make sure we are not caching objects with assumptions that can be violated in
>> 51: // the production run.
>> 52: void AOTOopChecker::check(oop obj) {
> 
> Should this also return a `bool` to indicate if the oop failed the check?  It would make it easier to bail out in the caller if the oop was bad.

The bail out and error logging needs to be done inside this function (as there might be more than one reason why `obj` is unsafe). 

This is an unrecoverable error -- the caller has already found a bad oop. We cannot just throw away this oop because there are other states that point to this oop.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2294399425

From heidinga at openjdk.org  Fri Aug 22 18:35:48 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 22 Aug 2025 18:35:48 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
 [v3]
In-Reply-To: <pZOktx4T7Jb3GdVk1SndW6UuSmyIdzol7IMijV4QVIA=.1508fb0e-76ff-4b3d-8d79-b00667f3f6a4@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
 <FpZVp2FE1d29D9C8N_VN1EkI1nTMapg4VRoUWxd575U=.c910bba1-0343-4788-966a-12b5bb04755d@github.com>
 <7rnsi3yhHnntw61prYN3u-Br-Rt_wmSuIxW_AszuHQE=.25abb82a-baee-467b-93af-e8a138182f73@github.com>
 <pZOktx4T7Jb3GdVk1SndW6UuSmyIdzol7IMijV4QVIA=.1508fb0e-76ff-4b3d-8d79-b00667f3f6a4@github.com>
Message-ID: <8z2P-jnw8D4OK-pLgWyAniSOSSvGlfQwFJCcXcylu7E=.1da23893-544e-4ddf-ad22-8bd98d9a4ca4@github.com>

On Fri, 22 Aug 2025 18:28:19 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/aotOopChecker.cpp line 52:
>> 
>>> 50: // Make sure we are not caching objects with assumptions that can be violated in
>>> 51: // the production run.
>>> 52: void AOTOopChecker::check(oop obj) {
>> 
>> Should this also return a `bool` to indicate if the oop failed the check?  It would make it easier to bail out in the caller if the oop was bad.
>
> The bail out and error logging needs to be done inside this function (as there might be more than one reason why `obj` is unsafe). 
> 
> This is an unrecoverable error -- the caller has already found a bad oop. We cannot just throw away this oop because there are other states that point to this oop.

The existing error handling - to log and bail out - are 100% right.  We're not throwing an exception so the caller still needs to unwind itself as well and a `return false;` after the `MetaspaceShared::unrecoverable_writing_error();` makes it more obvious how the caller should handle it - it too should bail as early as it can

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2294404235

From iklam at openjdk.org  Fri Aug 22 18:41:53 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 22 Aug 2025 18:41:53 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
 [v3]
In-Reply-To: <8z2P-jnw8D4OK-pLgWyAniSOSSvGlfQwFJCcXcylu7E=.1da23893-544e-4ddf-ad22-8bd98d9a4ca4@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
 <FpZVp2FE1d29D9C8N_VN1EkI1nTMapg4VRoUWxd575U=.c910bba1-0343-4788-966a-12b5bb04755d@github.com>
 <7rnsi3yhHnntw61prYN3u-Br-Rt_wmSuIxW_AszuHQE=.25abb82a-baee-467b-93af-e8a138182f73@github.com>
 <pZOktx4T7Jb3GdVk1SndW6UuSmyIdzol7IMijV4QVIA=.1508fb0e-76ff-4b3d-8d79-b00667f3f6a4@github.com>
 <8z2P-jnw8D4OK-pLgWyAniSOSSvGlfQwFJCcXcylu7E=.1da23893-544e-4ddf-ad22-8bd98d9a4ca4@github.com>
Message-ID: <QNoo12FC_gZgh4ZarP0Xq37FOvrv_Bd6Bm8jdWNCQm8=.4b5d2c16-e0f0-446c-9512-fa67a1552c39@github.com>

On Fri, 22 Aug 2025 18:31:33 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> The bail out and error logging needs to be done inside this function (as there might be more than one reason why `obj` is unsafe). 
>> 
>> This is an unrecoverable error -- the caller has already found a bad oop. We cannot just throw away this oop because there are other states that point to this oop.
>
> The existing error handling - to log and bail out - are 100% right.  We're not throwing an exception so the caller still needs to unwind itself as well and a `return false;` after the `MetaspaceShared::unrecoverable_writing_error();` makes it more obvious how the caller should handle it - it too should bail as early as it can

`MetaspaceShared::unrecoverable_writing_error()` will terminate the VM. So we will never return to the caller.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2294418224

From iklam at openjdk.org  Fri Aug 22 18:41:54 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 22 Aug 2025 18:41:54 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
 [v5]
In-Reply-To: <ltm75pGvL0GITWbubirMNqlDy17NI45xfa2nxRDGZCg=.a701a33f-6b43-432a-9b6d-d5e254f80cf4@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
 <oKv3C0h-ga-CTv4ZoBBDfwNWMGo2mjsSozMubdHCf8o=.2d60e196-443c-4547-bfb4-89cf6c4dbc2f@github.com>
 <hWDWxca2fjhNLwzEj6R6wFqiP7EeY26xzVulRClX3ws=.871fcbf4-d85f-458e-a30e-6a049cca8195@github.com>
 <ltm75pGvL0GITWbubirMNqlDy17NI45xfa2nxRDGZCg=.a701a33f-6b43-432a-9b6d-d5e254f80cf4@github.com>
Message-ID: <gAYl87vp4WUOhA01pJrifm4rIkR96s9FexFpHeFck8w=.6b81f4c9-a790-466a-aa65-9ff84f14693b@github.com>

On Fri, 22 Aug 2025 14:10:02 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> The assembly phase shouldn't execute any user Java code. If that happens, it can result in many undesirable side effects. Loading user native library will be just one example.
>> 
>> I think we need a stronger check -- make sure that no user classes are initialized at the end of the assembly phase. This check should be sufficient because executing code in any class will result in its initialization.
>> 
>> Maybe I should do that in a separate RFE?
>
>> I think we need a stronger check -- make sure that no user classes are initialized at the end of the assembly phase. This check should be sufficient because executing code in any class will result in its initialization.
> 
> That would be a good check.
> 
> Do we still assembly-time initialize Enums?  I thought in earlier implementations we had initialized all enum classes but I'm having trouble finding the code now.  If we do, the new "no user class initialized" check may fail on Enums

With JEP 483, if we find a cached instance of an enum class, this class is automatically marked as aot-initialized. Since we never execute user code (I filed [JDK-8366020](https://bugs.openjdk.org/browse/JDK-8366020) to check this), we won't have any cached instances of user enum classes. One risky area is the handling of enums in MethodTypes, so I added a added a test case to check that user enum types used by a Lambda expression are not initialized in the assembly phase.  See https://github.com/openjdk/jdk/pull/26375/commits/f12ad484639b98a2714d27a7a99ec9a48193656b

I also updated the comments in `HeapShared` and `CDSEnumKlass` about how enums are handled (JEP 483 vs legacy). See https://github.com/openjdk/jdk/pull/26375/commits/62014d4ff1dec5181362ca0c3eb0d89facf10283

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2294414840

From ayang at openjdk.org  Fri Aug 22 18:45:53 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 22 Aug 2025 18:45:53 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
 <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
Message-ID: <ma63halKHu2dawB9OaQ2F8ia9hyvwqywipWy8c6peEw=.e15da36f-3830-4e13-a8d8-8c4ab26e9fe8@github.com>

On Fri, 22 Aug 2025 17:18:40 GMT, Phil Race <prr at openjdk.org> wrote:

> or don't do it.

Adding `/timeout=480` is more or less don't do anything.

The default timeout (if omitting `/timeout=...`) is 120, so:

master: TIMEOUT_FACTOR=4 and /timeout=120 give you actual 480 timeout.
patch:  TIMEOUT_FACTOR=1 and /timeout=480 give you the same timeout.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294425045

From heidinga at openjdk.org  Fri Aug 22 19:16:58 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 22 Aug 2025 19:16:58 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
 [v3]
In-Reply-To: <QNoo12FC_gZgh4ZarP0Xq37FOvrv_Bd6Bm8jdWNCQm8=.4b5d2c16-e0f0-446c-9512-fa67a1552c39@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
 <FpZVp2FE1d29D9C8N_VN1EkI1nTMapg4VRoUWxd575U=.c910bba1-0343-4788-966a-12b5bb04755d@github.com>
 <7rnsi3yhHnntw61prYN3u-Br-Rt_wmSuIxW_AszuHQE=.25abb82a-baee-467b-93af-e8a138182f73@github.com>
 <pZOktx4T7Jb3GdVk1SndW6UuSmyIdzol7IMijV4QVIA=.1508fb0e-76ff-4b3d-8d79-b00667f3f6a4@github.com>
 <8z2P-jnw8D4OK-pLgWyAniSOSSvGlfQwFJCcXcylu7E=.1da23893-544e-4ddf-ad22-8bd98d9a4ca4@github.com>
 <QNoo12FC_gZgh4ZarP0Xq37FOvrv_Bd6Bm8jdWNCQm8=.4b5d2c16-e0f0-446c-9512-fa67a1552c39@github.com>
Message-ID: <PnWq5yTdCbYOmZTCo_x2AdUBMJvg83S5hATzwYnMkY8=.48b08376-b2cb-4176-9fc7-f8b744a3606f@github.com>

On Fri, 22 Aug 2025 18:39:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The existing error handling - to log and bail out - are 100% right.  We're not throwing an exception so the caller still needs to unwind itself as well and a `return false;` after the `MetaspaceShared::unrecoverable_writing_error();` makes it more obvious how the caller should handle it - it too should bail as early as it can
>
> `MetaspaceShared::unrecoverable_writing_error()` will terminate the VM. So we will never return to the caller.

That makes sense.  Thanks for confirming.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2294480616

From heidinga at openjdk.org  Fri Aug 22 19:20:52 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 22 Aug 2025 19:20:52 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
 [v5]
In-Reply-To: <pEUT7PfYv-8CBfDZd7wl832VYF-AyVpvwZZeZdXJZzo=.4abe9cc2-35c6-41bd-b847-8a12a2973ab8@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
 <pEUT7PfYv-8CBfDZd7wl832VYF-AyVpvwZZeZdXJZzo=.4abe9cc2-35c6-41bd-b847-8a12a2973ab8@github.com>
Message-ID: <KrEIPvWhJmQ94VfySF82vPHj5uSSXm0aKGAnjWVKjsk=.401195ea-9575-4b6a-9f16-dcca0b330dd8@github.com>

On Fri, 22 Aug 2025 18:35:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. 
>> 
>> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`.
>> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved.
>> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @DanHeidinga comments -- added comments and asserts about the handling of enums

My concerns have been addressed.  Thanks Ioi

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

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/jdk/pull/26375#pullrequestreview-3145577039

From syan at openjdk.org  Sat Aug 23 02:45:55 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 23 Aug 2025 02:45:55 GMT
Subject: RFR: 8365834: Mark java/net/httpclient/ManyRequests.java  as
 intermittent
In-Reply-To: <HAx5G9k5ytrc8dPtOujoSNTJdM17ZOJKxgPdqRCiquo=.72bdfe15-976a-4fa7-a72e-dcc7add1ea78@github.com>
References: <0Hf0mVj9zZYJxBD40KKb4QPjdH28hl6h7TPkJW6vIg0=.4e31ed4a-e6e5-4760-96d6-1d0bb0dadd51@github.com>
 <HAx5G9k5ytrc8dPtOujoSNTJdM17ZOJKxgPdqRCiquo=.72bdfe15-976a-4fa7-a72e-dcc7add1ea78@github.com>
Message-ID: <dCJqV5E_4y65aNbZLDSoIMEWtHZDVCzp0UtxBmn8Cww=.602df4ec-c4d7-4c1b-88b3-cfffa7b94186@github.com>

On Wed, 20 Aug 2025 11:51:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The test java/net/httpclient/ManyRequests.java has been observed intermittent failure such as https://bugs.openjdk.org/browse/JDK-8327968 and https://bugs.openjdk.org/browse/JDK-8365811. Should we mark this test as `@intermittent`.
>
> I think it's OK to add the `intermittent` `@key` to the test definition to allow for some setups to skip running this test. Once the actual issue gets addressed, I think we can remove the `intermittent` key.

Thankd for the reviews @jaikiran

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

PR Comment: https://git.openjdk.org/jdk/pull/26852#issuecomment-3216149835

From syan at openjdk.org  Sat Aug 23 02:45:55 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 23 Aug 2025 02:45:55 GMT
Subject: Integrated: 8365834: Mark java/net/httpclient/ManyRequests.java  as
 intermittent
In-Reply-To: <0Hf0mVj9zZYJxBD40KKb4QPjdH28hl6h7TPkJW6vIg0=.4e31ed4a-e6e5-4760-96d6-1d0bb0dadd51@github.com>
References: <0Hf0mVj9zZYJxBD40KKb4QPjdH28hl6h7TPkJW6vIg0=.4e31ed4a-e6e5-4760-96d6-1d0bb0dadd51@github.com>
Message-ID: <rQH_XHTsE7a7tReSzt41j1ZukSFpDeHhfsaoPqwEr34=.0bf4f9fa-a2a6-4089-beef-1b544fbc7aa3@github.com>

On Wed, 20 Aug 2025 03:30:26 GMT, SendaoYan <syan at openjdk.org> wrote:

> The test java/net/httpclient/ManyRequests.java has been observed intermittent failure such as https://bugs.openjdk.org/browse/JDK-8327968 and https://bugs.openjdk.org/browse/JDK-8365811. Should we mark this test as `@intermittent`.

This pull request has now been integrated.

Changeset: 09aad0ae
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/09aad0aea8b9f9fda14c5b18ae67b30ffce817d9
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8365834: Mark java/net/httpclient/ManyRequests.java  as intermittent

Reviewed-by: jpai

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

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

From alanb at openjdk.org  Sun Aug 24 09:58:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 24 Aug 2025 09:58:52 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <ma63halKHu2dawB9OaQ2F8ia9hyvwqywipWy8c6peEw=.e15da36f-3830-4e13-a8d8-8c4ab26e9fe8@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
 <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
 <ma63halKHu2dawB9OaQ2F8ia9hyvwqywipWy8c6peEw=.e15da36f-3830-4e13-a8d8-8c4ab26e9fe8@github.com>
Message-ID: <VveE9LwNHbACMKjKW97dxBek0d1JtVSmaLzxJ1d_gKg=.ebe2da86-b1c5-4ca5-890b-693ddbb1dac7@github.com>

On Fri, 22 Aug 2025 18:43:29 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>>> @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.
>> 
>> I don't agree.
>> If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.
>> 
>> I am also questioning whether such a time out was demonstrated for this test.
>> I've searched the entire history of CI jobs and I don't see where Leo had such a timeout of this test.
>> I can send you my query off-line so you can check it. Maybe it is incomplete.
>
>> or don't do it.
> 
> Adding `/timeout=480` is more or less don't do anything.
> 
> The default timeout (if omitting `/timeout=...`) is 120, so:
> 
> master: TIMEOUT_FACTOR=4 and /timeout=120 give you actual 480 timeout.
> patch:  TIMEOUT_FACTOR=1 and /timeout=480 give you the same timeout.

> If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.

There are several comments in this PR pointing out again and again that adding "/timeout=480" doesn't change anything with the new proposed default timeout and timeoutFactor. I was initially puzzled as to why these were being added to a lot of tests but I think Leo's runs with a timeoutFactor of 0.7 explains it. If the timeoutFactor is reduced then we risk timeouts from tests that are run close to the limit today. The method used to find these tests seems reasonable. So I think the approach is good and we should try to help him get this change integrated to avoid needing to keep it up to date while tests change in main line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2296595504

From dholmes at openjdk.org  Sun Aug 24 22:54:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 24 Aug 2025 22:54:03 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <LuiIAYhq4IOB9AQHCcFwiHFw30oK-vW-NzGC9ZuIEMo=.32cc7b1d-7426-42f2-bb6a-608b6f0e84ef@github.com>

On Fri, 22 Aug 2025 15:41:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/hotspot/jtreg/compiler/tiered/Level2RecompilationTest.java line 36:
> 
>> 34:  * @build jdk.test.whitebox.WhiteBox
>> 35:  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
>> 36:  * @run main/othervm/timeout=960 -Xbootclasspath/a:. -XX:+TieredCompilation
> 
> Why not `480` in this case?

Leo also states in the description:

> In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2296840413

From lkorinth at openjdk.org  Mon Aug 25 10:52:01 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 10:52:01 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <LuiIAYhq4IOB9AQHCcFwiHFw30oK-vW-NzGC9ZuIEMo=.32cc7b1d-7426-42f2-bb6a-608b6f0e84ef@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
 <LuiIAYhq4IOB9AQHCcFwiHFw30oK-vW-NzGC9ZuIEMo=.32cc7b1d-7426-42f2-bb6a-608b6f0e84ef@github.com>
Message-ID: <AFdpOMl_1ooSkxayT06rLAB2YAqOdpOVArSwLFhr5RI=.9ad37969-d90c-44e8-8839-2efb60f9f0a0@github.com>

On Sun, 24 Aug 2025 22:51:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/tiered/Level2RecompilationTest.java line 36:
>> 
>>> 34:  * @build jdk.test.whitebox.WhiteBox
>>> 35:  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
>>> 36:  * @run main/othervm/timeout=960 -Xbootclasspath/a:. -XX:+TieredCompilation
>> 
>> Why not `480` in this case?
>
> Leo also states in the description:
> 
>> In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.

In a few places, I have got timeouts after adjusting the timeout value. This is most likely because I have used a timeout factor of 0.7 to minimise "flickering" behaviour before finally changing to a timeout factor of 1. One consequence of this is that a few test cases will have double the original timeout (those test that would not pass a reduction to 0.7). So in all the instances when the timeout factor is exactly two times the size, the reason is that I have realised that I have already adjusted the timeout and I do not want to quad it again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297765975

From lkorinth at openjdk.org  Mon Aug 25 10:52:09 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 10:52:09 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <vSDcN6CwSbjugZPSWSankLFy31FA2rVoSuJidKO-yLQ=.e2955c07-efad-498c-9606-cb9ab46ed327@github.com>

On Fri, 22 Aug 2025 15:44:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java line 40:
> 
>> 38:  * @requires vm.cds
>> 39:  * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds
>> 40:  * @run driver/timeout=8000 LotsOfSyntheticClasses
> 
> I was expecting `500 * 4 = 2000`, instead of `8000` here.

This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)).

> test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 60:
> 
>> 58:  * @comment skip running this test on 32 bit VM
>> 59:  * @requires vm.bits == "64"
>> 60:  * @run testng/othervm/timeout=960 -Xmx2g WhiteBoxResizeTest
> 
> Why not `480`?

This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)).

> test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java line 34:
> 
>> 32:  * @build com.foobar.Utils
>> 33:  *        com.bar.*
>> 34:  * @run junit/othervm/timeout=960 -Djava.locale.providers=CLDR,SPI LocaleNameProviderTest
> 
> Why not `480`?

This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)).

> test/jdk/jdk/jfr/event/oldobject/TestObjectDescription.java line 49:
> 
>> 47:  * @library /test/lib /test/jdk
>> 48:  * @modules jdk.jfr/jdk.jfr.internal.test
>> 49:  * @run main/othervm/timeout=960 -XX:TLABSize=2k jdk.jfr.event.oldobject.TestObjectDescription
> 
> Why not `480`?

This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297768577
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297773391
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297773648
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297774209

From lkorinth at openjdk.org  Mon Aug 25 11:04:00 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 11:04:00 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <nlwJNUKGatY6Irnw2NlsOMfSpPv_kE_dY8mY_cggDy8=.5136bc97-670f-4b23-bbf5-6277ddd7de3d@github.com>

On Fri, 22 Aug 2025 16:06:16 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/langtools/jdk/jshell/HangingRemoteAgent.java line 38:
> 
>> 36: class HangingRemoteAgent extends RemoteExecutionControl {
>> 37: 
>> 38:     private static final int TIMEOUT = (int)(2000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));
> 
> why not `Utils.TIMEOUT_FACTOR`?

There are a few places where I have changed java files that are not jtreg tests themself. The code is used by a jtreg test, but is not the "entry" into a test. Those files have no way to specify `@library` annotations, as no "test annotations" are parsed. It is a pity that a jtreg "library" can not specify dependencies to other "libraries".

> test/langtools/jdk/jshell/UITesting.java line 148:
> 
>> 146:     }
>> 147: 
>> 148:     private static final long TIMEOUT = (long) (60_000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));
> 
> Why not `Utils.TIMEOUT_FACTOR`?

[see above](https://github.com/openjdk/jdk/pull/26749#discussion_r2297800775)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297800775
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297802941

From lkorinth at openjdk.org  Mon Aug 25 11:19:53 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 11:19:53 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <cORbSIzlWv8wgHca57OZ7Mm1wGDOGrYFEoUvNKLjcU0=.00ee4953-8c94-4812-89a5-f710dbe570d1@github.com>

On Wed, 20 Aug 2025 17:05:59 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update testing.md, remove makefile link, fix bad text

I am awaiting Oracle internal feedback if you wonder why I have still not updated copyright and integrated.  Target date for integration is second of September.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3219867507

From lkorinth at openjdk.org  Mon Aug 25 11:43:54 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 11:43:54 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <OrUszFbCpRlysBX8qVV7WF_Zx7Yli6voniXFlh_Zl9s=.a83cd99b-d003-4e8c-99bf-6cedfef51226@github.com>

On Fri, 22 Aug 2025 15:55:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/jdk/java/rmi/transport/dgcDeadLock/DGCDeadLock.java line 59:
> 
>> 57: public class DGCDeadLock implements Runnable {
>> 58:     final static public int HOLD_TARGET_TIME = 25000;
>> 59:     public static final double TEST_FAIL_TIME = (HOLD_TARGET_TIME + 30000) * Math.max(TestLibrary.getTimeoutFactor(), 4);
> 
> Why `max(...)`? If it's for backwards compatibility, shouldn't it be `(HOLD_TARGET_TIME + 30000)  * 4 * TestLibrary.getTimeoutFactor()`?

It is a way to give a "4x" lowest value, while not multiplying a 10x factor with four resulting in a 40x factor. I think (but I am not sure) that it would sometime time out if I only used the given timeout factor and not "guarding" with the max(x, 4).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297876217

From dfuchs at openjdk.org  Mon Aug 25 13:34:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 25 Aug 2025 13:34:51 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v14]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <UyAGYgSRJDMKRCtR1GH8PID6kKqtjwv_bVJjC81xZn4=.6d5eb562-6f64-46ab-8322-c81e49690009@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 628 commits:

 - merge latest changes from master branch
 - http3: minor code cleanup
 - http3: HeadersLowerCaseTest.java should close the clients it creates
 - http3: add missing copyright in Http3ConnectionAccess and make the class final
 - http3: improved test coverage for ImmutableSSLSession
 - http3: make sure that abandonned HTTP/2 connections are closed
 - http3: CustomRequestPublisher.java test should take into account server config
 - Add QUIC support to SunX509 key manager, update copyrights
 - Move getAlgorithmConstraints to X509KeyManagerCertChecking, update to match surrounding code
 - Mark H3ErrorHndlingTest as intermittent
 - ... and 618 more: https://git.openjdk.org/jdk/compare/ae0dac43...719f471d

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=13
  Stats: 105864 lines in 475 files changed: 103026 ins; 1335 del; 1503 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

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

From ayang at openjdk.org  Mon Aug 25 13:50:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 25 Aug 2025 13:50:55 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <OrUszFbCpRlysBX8qVV7WF_Zx7Yli6voniXFlh_Zl9s=.a83cd99b-d003-4e8c-99bf-6cedfef51226@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
 <OrUszFbCpRlysBX8qVV7WF_Zx7Yli6voniXFlh_Zl9s=.a83cd99b-d003-4e8c-99bf-6cedfef51226@github.com>
Message-ID: <plR6IBqt_CP-kbXrzVRQ-ZHQcmVAxFFHDkeXOA-fM5M=.0facc4e4-3564-42d5-978e-8173723f8d07@github.com>

On Mon, 25 Aug 2025 11:40:56 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> while not multiplying a 10x factor with four resulting in a 40x factor.

Why is that undesirable? The base is `(HOLD_TARGET_TIME + 30000)  * 4` and the timeout-factor changes that linearly. Using `max(..., 4)` here may come as a surprise to end users, IMO.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2298163658

From abarashev at openjdk.org  Mon Aug 25 16:01:13 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 25 Aug 2025 16:01:13 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v14]
In-Reply-To: <UyAGYgSRJDMKRCtR1GH8PID6kKqtjwv_bVJjC81xZn4=.6d5eb562-6f64-46ab-8322-c81e49690009@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UyAGYgSRJDMKRCtR1GH8PID6kKqtjwv_bVJjC81xZn4=.6d5eb562-6f64-46ab-8322-c81e49690009@github.com>
Message-ID: <rPE7YqOrQewi8QOa3ntyfpzY5oMAsx53t2L7P2jFNUk=.61bd12b9-d509-47eb-9f4a-f42a9eea32c5@github.com>

On Mon, 25 Aug 2025 13:34:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 628 commits:
> 
>  - merge latest changes from master branch
>  - http3: minor code cleanup
>  - http3: HeadersLowerCaseTest.java should close the clients it creates
>  - http3: add missing copyright in Http3ConnectionAccess and make the class final
>  - http3: improved test coverage for ImmutableSSLSession
>  - http3: make sure that abandonned HTTP/2 connections are closed
>  - http3: CustomRequestPublisher.java test should take into account server config
>  - Add QUIC support to SunX509 key manager, update copyrights
>  - Move getAlgorithmConstraints to X509KeyManagerCertChecking, update to match surrounding code
>  - Mark H3ErrorHndlingTest as intermittent
>  - ... and 618 more: https://git.openjdk.org/jdk/compare/ae0dac43...719f471d

src/java.base/share/classes/sun/security/ssl/X509KeyManagerCertChecking.java line 198:

> 196: 
> 197:     // Gets algorithm constraints of QUIC TLS engine.
> 198:     protected AlgorithmConstraints getAlgorithmConstraints(QuicTLSEngineImpl engine) {

Nit: To keep things consistent, let's move QuicTLSEngineImpl-specific methods under SSLEngine-specific methods here and in both key managers. Same as in `SSLAlgorithmConstraints`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2298492609

From abarashev at openjdk.org  Mon Aug 25 16:04:14 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 25 Aug 2025 16:04:14 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v14]
In-Reply-To: <UyAGYgSRJDMKRCtR1GH8PID6kKqtjwv_bVJjC81xZn4=.6d5eb562-6f64-46ab-8322-c81e49690009@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UyAGYgSRJDMKRCtR1GH8PID6kKqtjwv_bVJjC81xZn4=.6d5eb562-6f64-46ab-8322-c81e49690009@github.com>
Message-ID: <2CFPPrjz4OojwsgHFSq3BgxSa-AHmDreX5lQbOJxkiY=.0432b9e4-1b29-4653-aab2-b2af39d1fa84@github.com>

On Mon, 25 Aug 2025 13:34:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 628 commits:
> 
>  - merge latest changes from master branch
>  - http3: minor code cleanup
>  - http3: HeadersLowerCaseTest.java should close the clients it creates
>  - http3: add missing copyright in Http3ConnectionAccess and make the class final
>  - http3: improved test coverage for ImmutableSSLSession
>  - http3: make sure that abandonned HTTP/2 connections are closed
>  - http3: CustomRequestPublisher.java test should take into account server config
>  - Add QUIC support to SunX509 key manager, update copyrights
>  - Move getAlgorithmConstraints to X509KeyManagerCertChecking, update to match surrounding code
>  - Mark H3ErrorHndlingTest as intermittent
>  - ... and 618 more: https://git.openjdk.org/jdk/compare/ae0dac43...719f471d

src/java.base/share/classes/sun/security/ssl/X509KeyManagerCertChecking.java line 303:

> 301:     abstract String chooseServerAlias(String keyType,
> 302:                                       X500Principal[] issuers,
> 303:                                       QuicTLSEngineImpl quicTLSEngine);

Nit: To avoid any confusion, let's rename these methods to `chooseQuicClientAlias` and `chooseQuicServerAlias`. Also let's move them to the top of the file (under `isCheckingDisabled()` abstract method).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2298500078

From abarashev at openjdk.org  Mon Aug 25 20:38:56 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 25 Aug 2025 20:38:56 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <RqpubBYkhX4M2mTEjW6ag7umJutDcNRactVm09DP04k=.97579686-8a78-4c8f-9881-231c6193b805@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
 <RqpubBYkhX4M2mTEjW6ag7umJutDcNRactVm09DP04k=.97579686-8a78-4c8f-9881-231c6193b805@github.com>
Message-ID: <0_nsPJTwfZ98VGjD67067bzd7aolLEFGNW1xnMpAqfA=.39ff5549-9724-421c-9971-bd9c8b7b8c82@github.com>

On Wed, 20 Aug 2025 14:38:44 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
>> 
>>  - merge latest changes from master branch
>>  - merge latest http3 changes
>>  - Hide internal classes
>>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>>  - quic: remove unused fields
>>  - Make final fields static
>>  - Remove unused variable
>>  - merge latest changes from master branch
>>  - http3: update summary in H3SimpleTest.java
>>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9
>
> Marked as reviewed by djelinski (Reviewer).

Hi @djelinski! I couldn't find any unit tests for new `QuicTLSEngineImpl` functionality added to SSL code, do we have any? Please see tests under `test/jdk/sun/security/ssl/X509KeyManager` for examples.

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

PR Comment: https://git.openjdk.org/jdk/pull/24751#issuecomment-3221662557

From jpai at openjdk.org  Tue Aug 26 11:46:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 26 Aug 2025 11:46:58 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v14]
In-Reply-To: <UyAGYgSRJDMKRCtR1GH8PID6kKqtjwv_bVJjC81xZn4=.6d5eb562-6f64-46ab-8322-c81e49690009@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UyAGYgSRJDMKRCtR1GH8PID6kKqtjwv_bVJjC81xZn4=.6d5eb562-6f64-46ab-8322-c81e49690009@github.com>
Message-ID: <qMyQon3xikveqQkljR1xZ9Scm6lzS4Nq92Ey8MuAUmE=.3ecd56e9-a3ec-4769-bdf2-b4382dd4913d@github.com>

On Mon, 25 Aug 2025 13:34:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 628 commits:
> 
>  - merge latest changes from master branch
>  - http3: minor code cleanup
>  - http3: HeadersLowerCaseTest.java should close the clients it creates
>  - http3: add missing copyright in Http3ConnectionAccess and make the class final
>  - http3: improved test coverage for ImmutableSSLSession
>  - http3: make sure that abandonned HTTP/2 connections are closed
>  - http3: CustomRequestPublisher.java test should take into account server config
>  - Add QUIC support to SunX509 key manager, update copyrights
>  - Move getAlgorithmConstraints to X509KeyManagerCertChecking, update to match surrounding code
>  - Mark H3ErrorHndlingTest as intermittent
>  - ... and 618 more: https://git.openjdk.org/jdk/compare/ae0dac43...719f471d

I haven't reviewed every single file but have reviewed most of those which have the core implementation of this feature. I have skimmed over several of the test files as well. 
This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3155262397

From jpai at openjdk.org  Tue Aug 26 15:03:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 26 Aug 2025 15:03:58 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v14]
In-Reply-To: <UyAGYgSRJDMKRCtR1GH8PID6kKqtjwv_bVJjC81xZn4=.6d5eb562-6f64-46ab-8322-c81e49690009@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UyAGYgSRJDMKRCtR1GH8PID6kKqtjwv_bVJjC81xZn4=.6d5eb562-6f64-46ab-8322-c81e49690009@github.com>
Message-ID: <REv0obvzH2_IS4llfEwU32pdHFFA2sQuttJSXkNVFPE=.157db089-bdad-45f0-a4e1-22dbafd6bb6a@github.com>

On Mon, 25 Aug 2025 13:34:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 628 commits:
> 
>  - merge latest changes from master branch
>  - http3: minor code cleanup
>  - http3: HeadersLowerCaseTest.java should close the clients it creates
>  - http3: add missing copyright in Http3ConnectionAccess and make the class final
>  - http3: improved test coverage for ImmutableSSLSession
>  - http3: make sure that abandonned HTTP/2 connections are closed
>  - http3: CustomRequestPublisher.java test should take into account server config
>  - Add QUIC support to SunX509 key manager, update copyrights
>  - Move getAlgorithmConstraints to X509KeyManagerCertChecking, update to match surrounding code
>  - Mark H3ErrorHndlingTest as intermittent
>  - ... and 618 more: https://git.openjdk.org/jdk/compare/ae0dac43...719f471d

Hello Artur,

> Hi @djelinski! I couldn't find any unit tests for new `QuicTLSEngineImpl` functionality added to SSL code, do we have any? Please see tests under `test/jdk/sun/security/ssl/X509KeyManager` for examples.

Some weeks back I started looking at adding these tests but couldn't make much progress given other work. I spoke to Daniel and others and we feel that this can be done as a follow up work after the JEP integration. I've created https://bugs.openjdk.org/browse/JDK-8366184 to track this work.

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

PR Comment: https://git.openjdk.org/jdk/pull/24751#issuecomment-3224549555

From mdonovan at openjdk.org  Tue Aug 26 17:08:38 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 26 Aug 2025 17:08:38 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <QGduFIVDL1GhGaPhP8KkFjowyEYbUP8FALCUil62La4=.a0da78f8-d9c5-48b9-a054-6649997d3f71@github.com>

On Wed, 20 Aug 2025 17:05:59 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update testing.md, remove makefile link, fix bad text

test/jdk/sun/security/krb5/name/Constructors.java line 28:

> 26:  * @summary Make PrincipalName and Realm immutable
> 27:  * @modules java.security.jgss/sun.security.krb5
> 28:  * @run main/othervm Constructors

Do you know why this test needs the change? It's not doing much (no blocking calls) and on my system runs in about a tenth of a second.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2301616789

From dfuchs at openjdk.org  Tue Aug 26 17:19:41 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 26 Aug 2025 17:19:41 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v15]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <yUVO5Cbp3ssQzLaWVf50_FE7MN_vV-7eo4By-U5n6lY=.db1f12af-6faf-4710-a5d4-e142e95d2197@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 633 commits:

 - merge latest changes from master branch
 - http3: anticipate fix for JDK-8366110
 - http3: extend grace delay for HttpClient GC in InvalidInputStreamSubscriptionRequest.java
 - Artur's review: reorder the methods
 - Artur's review: rename to chooseQuicServerAlias and chooseQuicClientAlias
 - merge latest changes from master branch
 - http3: minor code cleanup
 - http3: HeadersLowerCaseTest.java should close the clients it creates
 - http3: add missing copyright in Http3ConnectionAccess and make the class final
 - http3: improved test coverage for ImmutableSSLSession
 - ... and 623 more: https://git.openjdk.org/jdk/compare/caaef3a0...976561a5

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=14
  Stats: 105866 lines in 475 files changed: 103027 ins; 1335 del; 1504 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

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

From dfuchs at openjdk.org  Tue Aug 26 17:44:01 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 26 Aug 2025 17:44:01 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v13]
In-Reply-To: <oiifer9a57vZpTmTR-Ks4gvvG4t2jzVbJWQ80toqNow=.9f4aaf31-9d4c-48d2-a67a-5c4c401c5862@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <E92owEttJOuK9W9qBIgxEAGp247Y0GcBvjAOD5eEYas=.ed39684b-e1c5-4689-a630-064a86fe5514@github.com>
 <oiifer9a57vZpTmTR-Ks4gvvG4t2jzVbJWQ80toqNow=.9f4aaf31-9d4c-48d2-a67a-5c4c401c5862@github.com>
Message-ID: <82Drm05OvT80-eSu7fJgF_vG-GbrdrEvujirv8mdzsw=.1ad95630-4ca3-40cb-89fd-767d6eb4cff0@github.com>

On Wed, 20 Aug 2025 15:32:55 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 616 commits:
>> 
>>  - merge latest changes from master branch
>>  - merge latest http3 changes
>>  - Hide internal classes
>>  - quic: Do not decrypt 1-RTT packets until the TLS handshake is complete
>>  - quic: remove unused fields
>>  - Make final fields static
>>  - Remove unused variable
>>  - merge latest changes from master branch
>>  - http3: update summary in H3SimpleTest.java
>>  - http3: review feedback - use copy() instead of thenApply(Function.identity())
>>  - ... and 606 more: https://git.openjdk.org/jdk/compare/908f3c96...e0aa68c9
>
> src/java.base/share/classes/sun/security/ssl/QuicEngineOutputRecord.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2022, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Copyright year.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2301688039

From dfuchs at openjdk.org  Tue Aug 26 17:51:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 26 Aug 2025 17:51:56 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v14]
In-Reply-To: <rPE7YqOrQewi8QOa3ntyfpzY5oMAsx53t2L7P2jFNUk=.61bd12b9-d509-47eb-9f4a-f42a9eea32c5@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UyAGYgSRJDMKRCtR1GH8PID6kKqtjwv_bVJjC81xZn4=.6d5eb562-6f64-46ab-8322-c81e49690009@github.com>
 <rPE7YqOrQewi8QOa3ntyfpzY5oMAsx53t2L7P2jFNUk=.61bd12b9-d509-47eb-9f4a-f42a9eea32c5@github.com>
Message-ID: <Rr1BWgwTFFShpXhn_5DKLPgtlAQ3vr_DLMpWt9D_qoE=.702ed792-499c-4613-8e09-941768ad2300@github.com>

On Mon, 25 Aug 2025 15:58:08 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 628 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: minor code cleanup
>>  - http3: HeadersLowerCaseTest.java should close the clients it creates
>>  - http3: add missing copyright in Http3ConnectionAccess and make the class final
>>  - http3: improved test coverage for ImmutableSSLSession
>>  - http3: make sure that abandonned HTTP/2 connections are closed
>>  - http3: CustomRequestPublisher.java test should take into account server config
>>  - Add QUIC support to SunX509 key manager, update copyrights
>>  - Move getAlgorithmConstraints to X509KeyManagerCertChecking, update to match surrounding code
>>  - Mark H3ErrorHndlingTest as intermittent
>>  - ... and 618 more: https://git.openjdk.org/jdk/compare/ae0dac43...719f471d
>
> src/java.base/share/classes/sun/security/ssl/X509KeyManagerCertChecking.java line 198:
> 
>> 196: 
>> 197:     // Gets algorithm constraints of QUIC TLS engine.
>> 198:     protected AlgorithmConstraints getAlgorithmConstraints(QuicTLSEngineImpl engine) {
> 
> Nit: To keep things consistent, let's move QuicTLSEngineImpl-specific methods under SSLEngine-specific methods here and in both key managers. Same as in `SSLAlgorithmConstraints`.

Done.

> src/java.base/share/classes/sun/security/ssl/X509KeyManagerCertChecking.java line 303:
> 
>> 301:     abstract String chooseServerAlias(String keyType,
>> 302:                                       X500Principal[] issuers,
>> 303:                                       QuicTLSEngineImpl quicTLSEngine);
> 
> Nit: To avoid any confusion, let's rename these methods to `chooseQuicClientAlias` and `chooseQuicServerAlias`. Also let's move them to the top of the file (under `isCheckingDisabled()` abstract method).

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2301701835
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2301705046

From abarashev at openjdk.org  Tue Aug 26 19:34:51 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 26 Aug 2025 19:34:51 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v15]
In-Reply-To: <yUVO5Cbp3ssQzLaWVf50_FE7MN_vV-7eo4By-U5n6lY=.db1f12af-6faf-4710-a5d4-e142e95d2197@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <yUVO5Cbp3ssQzLaWVf50_FE7MN_vV-7eo4By-U5n6lY=.db1f12af-6faf-4710-a5d4-e142e95d2197@github.com>
Message-ID: <GUskgmGub7E1o5HxjnBtTVOc1vJK8E2g8IEc0ZAM2BQ=.5c5ab483-3bef-416c-adfb-463cfe59853e@github.com>

On Tue, 26 Aug 2025 17:19:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 633 commits:
> 
>  - merge latest changes from master branch
>  - http3: anticipate fix for JDK-8366110
>  - http3: extend grace delay for HttpClient GC in InvalidInputStreamSubscriptionRequest.java
>  - Artur's review: reorder the methods
>  - Artur's review: rename to chooseQuicServerAlias and chooseQuicClientAlias
>  - merge latest changes from master branch
>  - http3: minor code cleanup
>  - http3: HeadersLowerCaseTest.java should close the clients it creates
>  - http3: add missing copyright in Http3ConnectionAccess and make the class final
>  - http3: improved test coverage for ImmutableSSLSession
>  - ... and 623 more: https://git.openjdk.org/jdk/compare/caaef3a0...976561a5

SSL code looks good. Thanks for making the requested changes! I didn't review the non-SSL code.

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

Marked as reviewed by abarashev (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3157037811

From vyazici at openjdk.org  Wed Aug 27 07:34:54 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 27 Aug 2025 07:34:54 GMT
Subject: RFR: 8362884: [GCC static analyzer] unix NetworkInterface.c addif leak
 on early returns
Message-ID: <U_heKTDoXdo1DIMSHP-TIWVYp7AiyBhTBnwriESsZjo=.280c0622-f694-499d-9851-93cf1692dbce@github.com>

Fixes `NetworkInterface.c::addif` memory leak on early returns. Issue reproduction is difficult ? didn't add a test.

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

Commit messages:
 - Release earlier allocations after `malloc()` failure

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

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

From dfuchs at openjdk.org  Wed Aug 27 09:55:44 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 27 Aug 2025 09:55:44 GMT
Subject: RFR: 8362884: [GCC static analyzer] unix NetworkInterface.c addif
 leak on early returns
In-Reply-To: <U_heKTDoXdo1DIMSHP-TIWVYp7AiyBhTBnwriESsZjo=.280c0622-f694-499d-9851-93cf1692dbce@github.com>
References: <U_heKTDoXdo1DIMSHP-TIWVYp7AiyBhTBnwriESsZjo=.280c0622-f694-499d-9851-93cf1692dbce@github.com>
Message-ID: <ffI60WUjgELEm4EsicCaaIaPMutyYpeYv6zQmZaJ_NI=.c6a5f2aa-f50a-41c5-90b7-f4cdb9c8ab06@github.com>

On Wed, 27 Aug 2025 07:29:11 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Fixes `NetworkInterface.c::addif` memory leak on early returns. Issue reproduction is difficult ? didn't add a test.

The fact that `CHECKED_MALLOC3` relies on the fact that it's being called from within a method that returns a `netif*` pointer and has a `netif* ifs` parameter is a bit smelly, but it was preexisting and I like that this change is kept minimal. So I'd say it looks good to me. 

FWIW: I double checked and it does look like the windows version of this file does not have the same issue that is being fixed here.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26952#pullrequestreview-3159128989

From mdonovan at openjdk.org  Wed Aug 27 11:26:45 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 27 Aug 2025 11:26:45 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4]
In-Reply-To: <xEMRItOXiz4QiIfzOGi5uyciDwMlL_RXN-mqbMWK7D0=.22861fb0-6375-43cc-be8f-04e42d03de5c@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
 <5ZUVLPZoyfEyo4OcY_rdldmlcA3uLFN-Z09bYhoRNWs=.5abd252b-67dc-4b36-b6c4-2a7c842a7752@github.com>
 <JA3afve_1nmCt4tvLBo_6sI4Ze15bCF34qzEAuE3z28=.08077ddc-0b7d-4013-b407-c9475335b1b4@github.com>
 <Zgvh4-Dv0d227pBcvwQJWpslMAYKsFcXgFNLl_fUKkg=.096b15a3-fdb5-40a0-a336-f0638c5abbc0@github.com>
 <3Vzkj4wL99IHs48Ys_zXUzRCiOEm5jjh5Oilop5dSDM=.d945fcf2-3f0b-4e34-8673-96928dc47952@github.com>
 <xEMRItOXiz4QiIfzOGi5uyciDwMlL_RXN-mqbMWK7D0=.22861fb0-6375-43cc-be8f-04e42d03de5c@github.com>
Message-ID: <Y-FLBE7JCYJ9O0e0rgpf4kchn0LbNwoIHil4PMGrxOY=.c164bb08-c114-43f2-9977-581cea193970@github.com>

On Tue, 3 Jun 2025 17:29:13 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> As a constructor, the code would look like this
>> 
>> 
>> public CertificateBuilder(String subjectName,
>>                               PublicKey publicKey, PublicKey caKey, KeyUsage... keyUsages)
>>             throws CertificateException, IOException {
>>         factory = CertificateFactory.getInstance("X.509");
>>         SecureRandom random = new SecureRandom();
>> 
>>         boolean [] keyUsage = new boolean[KeyUsage.values().length];
>>         for (KeyUsage ku : keyUsages) {
>>             keyUsage[ku.ordinal()] = true;
>>         }
>> 
>>         this.subjectName = new X500Principal(subjectName);
>>         this.publicKey = Objects.requireNonNull(publicKey, "Caught null public key");
>>         notBefore = (Date)Date.from(Instant.now().minus(1, ChronoUnit.HOURS));
>>         notAfter = Date.from(Instant.now().plus(1, ChronoUnit.HOURS));
>>         serialNumber = BigInteger.valueOf(random.nextLong(1000000)+1);
>>         byte[] keyIdBytes = new KeyIdentifier(publicKey).getIdentifier();
>>         Extension e = new SubjectKeyIdentifierExtension(keyIdBytes);
>>         extensions.put(e.getId(), e);
>> 
>>         KeyIdentifier kid = new KeyIdentifier(caKey);
>>         e = new AuthorityKeyIdentifierExtension(kid, null, null);
>>         extensions.put(e.getId(), e);
>> 
>>         if (keyUsages.length != 0) {
>>             e = new KeyUsageExtension(keyUsage);
>>             extensions.put(e.getId(), e);
>>         }
>>     }
>> 
>> 
>> 
>>>   it also means I can't use this method to to create a certificate with a longer, or shorter validity period
>> 
>> There are methods to set the not-before and not-after fields. Any field set in this static method can be changed:
>> 
>> `
>> newCertificateBuilder(...).notAfter(Date.from(Instant.now().plus(10, TimeUnit.YEARS)));
>> `
>> 
>> I don't like using `Date` here and would be happy to overload it to take `Instant` as well.
>
>> As a constructor, the code would look like this
> 
> <snip>
> 
> Ah, I see. Well technically you could call the set methods from the ctor but you would get `this-escape` compiler warnings, which you probably want to avoid.
> 
>> > it also means I can't use this method to to create a certificate with a longer, or shorter validity period
>> 
>> There are methods to set the not-before and not-after fields. Any field set in this static method can be changed:
>> 
>> `newCertificateBuilder(...).notAfter(Date.from(Instant.now().plus(10, TimeUnit.YEARS)));`
>> 
>> I don't like using `Date` here and would be happy to overload it to take `Instant` as well.
> 
> Yes, but I don't think the static method which is generically named `newCertificateBuilder` should be hard-coding a one hour validity period, that detail should be either in a different method (my preference) or this method should be named more clearly like `oneHourCertificateBuilder`. I realize this is just a test method, but this is a nicely designed API that has been very useful so I would prefer if we keep the flexibility.

I removed the default one-hour validity from the builder method and created a `setOneHourValidity()` method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2303642791

From vyazici at openjdk.org  Thu Aug 28 09:56:43 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 28 Aug 2025 09:56:43 GMT
Subject: RFR: 8362884: [GCC static analyzer] unix NetworkInterface.c addif
 leak on early returns
In-Reply-To: <U_heKTDoXdo1DIMSHP-TIWVYp7AiyBhTBnwriESsZjo=.280c0622-f694-499d-9851-93cf1692dbce@github.com>
References: <U_heKTDoXdo1DIMSHP-TIWVYp7AiyBhTBnwriESsZjo=.280c0622-f694-499d-9851-93cf1692dbce@github.com>
Message-ID: <q7G5gXdLtCPlSYbFMMiryJoXBkyMY4jEjRyDfVpcZwU=.6d4894eb-e7be-41f8-b679-919dea3f91ae@github.com>

On Wed, 27 Aug 2025 07:29:11 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Fixes `NetworkInterface.c::addif` memory leak on early returns. Issue reproduction is difficult ? didn't add a test.

@MBaesken, would you mind checking if this PR fixes the `-fanalyzer` warning against `NetworkInterface.c::addif`, please?

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

PR Comment: https://git.openjdk.org/jdk/pull/26952#issuecomment-3232800653

From mbaesken at openjdk.org  Thu Aug 28 12:39:41 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 28 Aug 2025 12:39:41 GMT
Subject: RFR: 8362884: [GCC static analyzer] unix NetworkInterface.c addif
 leak on early returns
In-Reply-To: <q7G5gXdLtCPlSYbFMMiryJoXBkyMY4jEjRyDfVpcZwU=.6d4894eb-e7be-41f8-b679-919dea3f91ae@github.com>
References: <U_heKTDoXdo1DIMSHP-TIWVYp7AiyBhTBnwriESsZjo=.280c0622-f694-499d-9851-93cf1692dbce@github.com>
 <q7G5gXdLtCPlSYbFMMiryJoXBkyMY4jEjRyDfVpcZwU=.6d4894eb-e7be-41f8-b679-919dea3f91ae@github.com>
Message-ID: <TZDwmJ2e7wZaf-6_qEGXTT8cKROtS-a_uZ8v9aInT_c=.780eef1e-a55e-4637-bee9-1e8f8154ea84@github.com>

On Thu, 28 Aug 2025 09:54:26 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> @MBaesken, would you mind checking if this PR fixes the `-fanalyzer` warning against `NetworkInterface.c::addif`, please?

I checked and your patch fixes the '-fanalyzer' warning.

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

PR Comment: https://git.openjdk.org/jdk/pull/26952#issuecomment-3233335698

From mbaesken at openjdk.org  Thu Aug 28 12:42:42 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 28 Aug 2025 12:42:42 GMT
Subject: RFR: 8362884: [GCC static analyzer] unix NetworkInterface.c addif
 leak on early returns
In-Reply-To: <U_heKTDoXdo1DIMSHP-TIWVYp7AiyBhTBnwriESsZjo=.280c0622-f694-499d-9851-93cf1692dbce@github.com>
References: <U_heKTDoXdo1DIMSHP-TIWVYp7AiyBhTBnwriESsZjo=.280c0622-f694-499d-9851-93cf1692dbce@github.com>
Message-ID: <3PzRM4D3Q6NnyCYepZMDkmHlJV0rFqegtSjLixO3Reo=.d8b40518-f1b7-49fd-913e-8f58b4a9cc47@github.com>

On Wed, 27 Aug 2025 07:29:11 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Fixes `NetworkInterface.c::addif` memory leak on early returns. Issue reproduction is difficult ? didn't add a test.

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26952#pullrequestreview-3164694482

From lkorinth at openjdk.org  Thu Aug 28 13:05:51 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 28 Aug 2025 13:05:51 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
 <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
Message-ID: <EJdxiot32oUpUVtRSTMTXFSFI9pOkmb17vwLGEKmuK0=.a14f9df8-b05a-4a59-a5c0-039070d059ff@github.com>

On Fri, 22 Aug 2025 17:18:40 GMT, Phil Race <prr at openjdk.org> wrote:

> > @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.
> 
> I don't agree. If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.
> 
> I am also questioning whether such a time out was demonstrated for this test. I've searched the entire history of CI jobs and I don't see where Leo had such a timeout of this test. I can send you my query off-line so you can check it. Maybe it is incomplete.

I will revert this change. Thanks for finding it. I think the timeout was found in a local run with a timeout factor of 0.5 and a local fix to "CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE". CI history tells me that the run time of the test is stable and that we have a margin.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2307351823

From lkorinth at openjdk.org  Thu Aug 28 13:12:45 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 28 Aug 2025 13:12:45 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v6]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <mygrl66-jtLOCitZE1y7w005QUUFmtZ0QDWPO5FD8pQ=.9558b892-2b3a-4c1e-b898-51b86d61beb0@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:

 - revert added timeout, it is not needed
 - feedback from Mark Sheppard

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/f24a1e72..365454d2

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

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

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

From lkorinth at openjdk.org  Thu Aug 28 13:12:46 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 28 Aug 2025 13:12:46 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <O2hQ5ow7drkJOD-QiVkoDFa9ChZmv3WEOTqLgH3r8lQ=.b12f1c30-cfe8-4797-a964-67429193f9d9@github.com>

On Wed, 20 Aug 2025 17:05:59 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update testing.md, remove makefile link, fix bad text

I have added some updates. I will try to merge latest, update copyrights and run tests over the weekend.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3233444166

From iklam at openjdk.org  Thu Aug 28 21:17:42 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 28 Aug 2025 21:17:42 GMT
Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap
 [v6]
In-Reply-To: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
References: <uit1RSrMnoZnFk1XjlF8pLe0dEw-lTjhwZ51NNfQA-c=.479fc39b-d20b-4ba2-bfbc-4081c937e33a@github.com>
Message-ID: <c5_0aVbS2w6wSUdFZNoBahFalXg88EqSuz6HyrKD4mA=.000a5e8e-ffe8-45f4-8dba-a4f3f81b064e@github.com>

> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. 
> 
> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`.
> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved.
> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java.

Ioi Lam 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 branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap
 - @DanHeidinga comments -- added comments and asserts about the handling of enums
 - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase
 - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run
 - @DanHeidinga comments
 - tightened SystemDictionary::preload_class()
 - Fixed bugs found in JCK
 - added entry in ProblemList-AotJdk.txt due to 8323727
 - more clean up
 - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap
 - ... and 10 more: https://git.openjdk.org/jdk/compare/075ddef8...1a8ea501

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

Changes: https://git.openjdk.org/jdk/pull/26375/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=05
  Stats: 712 lines in 44 files changed: 597 ins; 13 del; 102 mod
  Patch: https://git.openjdk.org/jdk/pull/26375.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375

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

From vyazici at openjdk.org  Fri Aug 29 06:15:49 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 29 Aug 2025 06:15:49 GMT
Subject: Integrated: 8362884: [GCC static analyzer] unix NetworkInterface.c
 addif leak on early returns
In-Reply-To: <U_heKTDoXdo1DIMSHP-TIWVYp7AiyBhTBnwriESsZjo=.280c0622-f694-499d-9851-93cf1692dbce@github.com>
References: <U_heKTDoXdo1DIMSHP-TIWVYp7AiyBhTBnwriESsZjo=.280c0622-f694-499d-9851-93cf1692dbce@github.com>
Message-ID: <B1dYGxTh4dKIQgO_xW7N0-kyybr23BEYCl6Z58USPOY=.d087e202-587f-4010-a3fc-e12e37787b9b@github.com>

On Wed, 27 Aug 2025 07:29:11 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Fixes `NetworkInterface.c::addif` memory leak on early returns. Issue reproduction is difficult ? didn't add a test.

This pull request has now been integrated.

Changeset: a2da75a6
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a2da75a6b69f56be41741bffba2c6874a93dfa40
Stats:     14 lines in 1 file changed: 11 ins; 0 del; 3 mod

8362884: [GCC static analyzer] unix NetworkInterface.c addif leak on early returns

Reviewed-by: dfuchs, mbaesken

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

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

From vyazici at openjdk.org  Fri Aug 29 06:15:49 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 29 Aug 2025 06:15:49 GMT
Subject: RFR: 8362884: [GCC static analyzer] unix NetworkInterface.c addif
 leak on early returns
In-Reply-To: <U_heKTDoXdo1DIMSHP-TIWVYp7AiyBhTBnwriESsZjo=.280c0622-f694-499d-9851-93cf1692dbce@github.com>
References: <U_heKTDoXdo1DIMSHP-TIWVYp7AiyBhTBnwriESsZjo=.280c0622-f694-499d-9851-93cf1692dbce@github.com>
Message-ID: <2dAfV0_LdoJYNfczUXjvRZzIYIoRQnouAbgAghPBC7Q=.16d981b7-dbc3-438d-b1a7-e5c139a10f5c@github.com>

On Wed, 27 Aug 2025 07:29:11 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Fixes `NetworkInterface.c::addif` memory leak on early returns. Issue reproduction is difficult ? didn't add a test.

`tier1,2` passes on all supported platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/26952#issuecomment-3235849804

From vyazici at openjdk.org  Fri Aug 29 08:50:52 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 29 Aug 2025 08:50:52 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v11]
In-Reply-To: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
Message-ID: <9EcZbWUzflSBQOXmJPxjCfg0lw5R-77Y37aUIpzJKNU=.812a6e53-f3a1-4eab-81ad-7967c1141c15@github.com>

> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
> 
>> The file channel will not be closed upon completion. The caller is
>> expected to manage the life cycle of the channel, and close it
>> appropriately when not needed anymore.
> 
> ### Implementation notes
> 
> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.

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

  Improve Javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26155/files
  - new: https://git.openjdk.org/jdk/pull/26155/files/e4d9c55c..53b22972

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

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

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

From jpai at openjdk.org  Fri Aug 29 08:59:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 29 Aug 2025 08:59:56 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v11]
In-Reply-To: <9EcZbWUzflSBQOXmJPxjCfg0lw5R-77Y37aUIpzJKNU=.812a6e53-f3a1-4eab-81ad-7967c1141c15@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <9EcZbWUzflSBQOXmJPxjCfg0lw5R-77Y37aUIpzJKNU=.812a6e53-f3a1-4eab-81ad-7967c1141c15@github.com>
Message-ID: <_VHUj8gqLMmboAEBOGBR0KSBcsEvPg8Gimgd5B3CFHc=.ce6ce9c6-409a-4a8a-aabb-02482a7f8437@github.com>

On Fri, 29 Aug 2025 08:50:52 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve Javadoc

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26155#pullrequestreview-3167945067

From dfuchs at openjdk.org  Fri Aug 29 10:07:46 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 29 Aug 2025 10:07:46 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v11]
In-Reply-To: <9EcZbWUzflSBQOXmJPxjCfg0lw5R-77Y37aUIpzJKNU=.812a6e53-f3a1-4eab-81ad-7967c1141c15@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <9EcZbWUzflSBQOXmJPxjCfg0lw5R-77Y37aUIpzJKNU=.812a6e53-f3a1-4eab-81ad-7967c1141c15@github.com>
Message-ID: <55j1M4AEBYKMBeOHlo1IVHlYS5RcDThGouEzVH7ECT4=.d6bef4ca-e772-4ed1-b7dc-77d8ac4562ff@github.com>

On Fri, 29 Aug 2025 08:50:52 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve Javadoc

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26155#pullrequestreview-3168159498

From vyazici at openjdk.org  Fri Aug 29 12:07:38 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 29 Aug 2025 12:07:38 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v12]
In-Reply-To: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
Message-ID: <YdS-wWLsKvFadMvkK2nX1XtXADbcX4E15Lk-cN0zWCw=.979ed60a-1730-41dc-a82e-c87347449557@github.com>

> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
> 
>> The file channel will not be closed upon completion. The caller is
>> expected to manage the life cycle of the channel, and close it
>> appropriately when not needed anymore.
> 
> ### Implementation notes
> 
> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.

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

 - Merge remote-tracking branch 'upstream/master' into ofFileChannel
 - Improve Javadoc
 - Improve `@apiNote`
 - Improve the `ofFileChannel` Javadoc
 - Improve style for declaring multiple consecutive fields of the same type
 - Revert the last commit: faa5d24d831
   
   The `send()`-vs-`sendAsync()` discrepancy will be addressed separately.
 - Verify exceptions using both `send()` and `sendAsync()`
 - Replace usage of `CompletableFuture` with `Future`
 - Apply review feedback for `FileChannelPublisherTest`
 - Fix typo in `Utils::getBufferWithAtMost` Javadoc
 - ... and 8 more: https://git.openjdk.org/jdk/compare/31c7b765...838b8ca7

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26155/files
  - new: https://git.openjdk.org/jdk/pull/26155/files/53b22972..838b8ca7

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

  Stats: 101758 lines in 2448 files changed: 61263 ins; 27410 del; 13085 mod
  Patch: https://git.openjdk.org/jdk/pull/26155.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26155/head:pull/26155

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

From vyazici at openjdk.org  Fri Aug 29 12:09:46 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 29 Aug 2025 12:09:46 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v11]
In-Reply-To: <9EcZbWUzflSBQOXmJPxjCfg0lw5R-77Y37aUIpzJKNU=.812a6e53-f3a1-4eab-81ad-7967c1141c15@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <9EcZbWUzflSBQOXmJPxjCfg0lw5R-77Y37aUIpzJKNU=.812a6e53-f3a1-4eab-81ad-7967c1141c15@github.com>
Message-ID: <0-xnUMKrq3GKXOcl05DEa_kdvUKX7mbNH2XAwK0XMo8=.b3e1607a-3b2f-4223-8402-3cdc78f8ef31@github.com>

On Fri, 29 Aug 2025 08:50:52 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve Javadoc

Verified that `tier1,2` against 838b8ca7102 succeeds on several platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/26155#issuecomment-3236814231

From lkorinth at openjdk.org  Fri Aug 29 14:41:48 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 29 Aug 2025 14:41:48 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v6]
In-Reply-To: <QGduFIVDL1GhGaPhP8KkFjowyEYbUP8FALCUil62La4=.a0da78f8-d9c5-48b9-a054-6649997d3f71@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <QGduFIVDL1GhGaPhP8KkFjowyEYbUP8FALCUil62La4=.a0da78f8-d9c5-48b9-a054-6649997d3f71@github.com>
Message-ID: <U44eId1pfiGjDkIlPM5vo-4Y_Oq-QdjIdCTFbD5O94E=.0f31a90c-9106-4cf5-a50f-4e7551eb14ff@github.com>

On Tue, 26 Aug 2025 17:06:08 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - revert added timeout, it is not needed
>>  - feedback from Mark Sheppard
>
> test/jdk/sun/security/krb5/name/Constructors.java line 28:
> 
>> 26:  * @summary Make PrincipalName and Realm immutable
>> 27:  * @modules java.security.jgss/sun.security.krb5
>> 28:  * @run main/othervm Constructors
> 
> Do you know why this test needs the change? It's not doing much (no blocking calls) and on my system runs in about a tenth of a second.

I have not analysed why. I can see 1013 occurrences in our test history where the test takes 2 minutes or more. On different CPU platforms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2310355659

From mdonovan at openjdk.org  Fri Aug 29 15:19:32 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 29 Aug 2025 15:19:32 GMT
Subject: RFR: 8325766: Extend CertificateBuilder to create trust and end
 entity certificates programmatically [v7]
In-Reply-To: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
Message-ID: <4mXuyLW05EUyeCGs3LmryWoHl1IRrNe4t4LinJVIv7k=.88a4f46a-9e46-4fec-8429-24bae001b1bd@github.com>

> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates.
> 
> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1)
> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa)
> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0)

Matthew Donovan 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 certbuilder
 - changed keystore to PKCS12 and remove key initialization
 - added new method, setOneHourValidity(), and removed it from the static method.
 - Merge branch 'master' into certbuilder
 - fixed redundant setNotAfter() calls. One of them should have been setNotBefore
 - Merge branch 'master' into certbuilder
 - expanded wildcard imports
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - reversed order of DN strings when making certificates.
 - ... and 6 more: https://git.openjdk.org/jdk/compare/452b052f...98ae3e4b

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

Changes: https://git.openjdk.org/jdk/pull/23700/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23700&range=06
  Stats: 771 lines in 3 files changed: 163 ins; 565 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/23700.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23700/head:pull/23700

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

From mullan at openjdk.org  Fri Aug 29 15:19:32 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 29 Aug 2025 15:19:32 GMT
Subject: RFR: 8325766: Extend CertificateBuilder to create trust and end
 entity certificates programmatically [v7]
In-Reply-To: <4mXuyLW05EUyeCGs3LmryWoHl1IRrNe4t4LinJVIv7k=.88a4f46a-9e46-4fec-8429-24bae001b1bd@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <4mXuyLW05EUyeCGs3LmryWoHl1IRrNe4t4LinJVIv7k=.88a4f46a-9e46-4fec-8429-24bae001b1bd@github.com>
Message-ID: <ucaArH2cQSfLVWu9ATmo6xTB4O0VAKzo5pvKbzrvW5A=.9220dbb7-9df0-435d-bddb-d7adc4b53b59@github.com>

On Fri, 29 Aug 2025 15:16:04 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates.
>> 
>> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1)
>> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa)
>> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0)
>
> Matthew Donovan 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 certbuilder
>  - changed keystore to PKCS12 and remove key initialization
>  - added new method, setOneHourValidity(), and removed it from the static method.
>  - Merge branch 'master' into certbuilder
>  - fixed redundant setNotAfter() calls. One of them should have been setNotBefore
>  - Merge branch 'master' into certbuilder
>  - expanded wildcard imports
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - reversed order of DN strings when making certificates.
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/452b052f...98ae3e4b

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23700#pullrequestreview-3169128309

From lkorinth at openjdk.org  Fri Aug 29 18:45:45 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 29 Aug 2025 18:45:45 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v7]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <2IfOGWu0Kfw8qdRmYLkMEdF5kvlC5lcuc-USAovOTFM=.f6d2a6c9-160d-478e-aa5c-1086b40e52bd@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

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

  update copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/365454d2..4b33904a

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

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

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

From duke at openjdk.org  Fri Aug 29 20:17:54 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 29 Aug 2025 20:17:54 GMT
Subject: RFR: 8361593: Commented dead code in JDK-8342868 can be removed
Message-ID: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>

[JDK-8342868](https://bugs.openjdk.org/browse/JDK-8342868) commented out code rather than removing it. The code can be removed safely, as pointed out in the PR review: #21654.

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

Commit messages:
 - remove commented code

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

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

From jlu at openjdk.org  Fri Aug 29 23:04:42 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 29 Aug 2025 23:04:42 GMT
Subject: RFR: 8361593: Commented dead code in JDK-8342868 can be removed
In-Reply-To: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
References: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
Message-ID: <jvI1IldKMvGXzyCUyvDDynclH_fIqHbvYkqzLMqTtEY=.5697eb3f-c5c5-4bb7-b205-e61e93b61cd5@github.com>

On Fri, 29 Aug 2025 20:12:42 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> [JDK-8342868](https://bugs.openjdk.org/browse/JDK-8342868) commented out code rather than removing it. The code can be removed safely, as pointed out in the PR review: #21654.

Removals are consistent with the ones commented out in https://github.com/openjdk/jdk/pull/21654.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27012#pullrequestreview-3170642702

From naoto at openjdk.org  Fri Aug 29 23:27:41 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 29 Aug 2025 23:27:41 GMT
Subject: RFR: 8361593: Commented dead code in JDK-8342868 can be removed
In-Reply-To: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
References: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
Message-ID: <005TU_LUKpe4hFdKdMHebTg1Tn8GfWbngdLpg8tKvUE=.d068c2e4-4462-4ed5-834b-4285dd4bb910@github.com>

On Fri, 29 Aug 2025 20:12:42 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> [JDK-8342868](https://bugs.openjdk.org/browse/JDK-8342868) commented out code rather than removing it. The code can be removed safely, as pointed out in the PR review: #21654.

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27012#pullrequestreview-3170703060

From duke at openjdk.org  Fri Aug 29 23:27:41 2025
From: duke at openjdk.org (duke)
Date: Fri, 29 Aug 2025 23:27:41 GMT
Subject: RFR: 8361593: Commented dead code in JDK-8342868 can be removed
In-Reply-To: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
References: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
Message-ID: <59nQMxcp2BQVztc0_1WAn9_IlMUN5a01p4Efr90kz3E=.7909e05c-a7cc-4b24-ba4f-7b25a475654c@github.com>

On Fri, 29 Aug 2025 20:12:42 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> [JDK-8342868](https://bugs.openjdk.org/browse/JDK-8342868) commented out code rather than removing it. The code can be removed safely, as pointed out in the PR review: #21654.

@fandreuz 
Your change (at version 09067914f31bdabe29d2c9d4187eec6246a3cae4) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27012#issuecomment-3238691498

From jwaters at openjdk.org  Sat Aug 30 06:53:41 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 30 Aug 2025 06:53:41 GMT
Subject: RFR: 8361593: Commented dead code in JDK-8342868 can be removed
In-Reply-To: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
References: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
Message-ID: <Hf0bUlANe4m4vwq1TaQKBUk3pHysIHbkpb67Xpr6-Es=.e1af0982-049b-4f96-b217-8e2c900feae7@github.com>

On Fri, 29 Aug 2025 20:12:42 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> [JDK-8342868](https://bugs.openjdk.org/browse/JDK-8342868) commented out code rather than removing it. The code can be removed safely, as pointed out in the PR review: #21654.

Test failure is because JDK source failed to check out rather than anything related to this change

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27012#pullrequestreview-3170915193

From jpai at openjdk.org  Sat Aug 30 09:57:45 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 30 Aug 2025 09:57:45 GMT
Subject: RFR: 8361593: Commented dead code in JDK-8342868 can be removed
In-Reply-To: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
References: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
Message-ID: <g8cKUd20NXdcGW5oisM55cxZswHpWAOrPnAvzyS2f2w=.15457053-c4a8-42bb-933c-6c238bcf508f@github.com>

On Fri, 29 Aug 2025 20:12:42 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> [JDK-8342868](https://bugs.openjdk.org/browse/JDK-8342868) commented out code rather than removing it. The code can be removed safely, as pointed out in the PR review: #21654.

Looks OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27012#pullrequestreview-3170992535

From duke at openjdk.org  Sun Aug 31 00:37:49 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Sun, 31 Aug 2025 00:37:49 GMT
Subject: Integrated: 8361593: Commented dead code in JDK-8342868 can be removed
In-Reply-To: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
References: <QGMtxec3fJ0oi-P5ncNcwOr94RjPaVnckSr0AGe6Cjk=.2c28e944-e77c-4439-a1d0-49566731c599@github.com>
Message-ID: <hitHEJaihgTNtVVo8bs47iMtcQriMZmd-ODRi5D6E-w=.381b4606-0b50-4dd7-9c1f-277e313a689b@github.com>

On Fri, 29 Aug 2025 20:12:42 GMT, Francesco Andreuzzi <duke at openjdk.org> wrote:

> [JDK-8342868](https://bugs.openjdk.org/browse/JDK-8342868) commented out code rather than removing it. The code can be removed safely, as pointed out in the PR review: #21654.

This pull request has now been integrated.

Changeset: 9339a6a2
Author:    Francesco Andreuzzi <andreuzzi.francesco at gmail.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9339a6a23236e783e93f967cf6aba16c2f749fdd
Stats:     16 lines in 3 files changed: 0 ins; 11 del; 5 mod

8361593: Commented dead code in JDK-8342868 can be removed

Reviewed-by: jlu, naoto, jwaters, jpai

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

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