From smonteith at openjdk.org Mon Dec 1 12:07:02 2025 From: smonteith at openjdk.org (Stuart Monteith) Date: Mon, 1 Dec 2025 12:07:02 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. Message-ID: MemorySegments allocated from shared Arena from java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | |---------|-------|-------|-------|-------|-------|-------| | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | After: | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | |---------|-------|-------|-------|-------|-------|-------| | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | | 8 | 58.22 | 31.60 | 36.87 | 31.72 | 47.09 | 16.52 | | 16 | 70.15 | 47.76 | 52.37 | 47.26 | 70.91 | 14.53 | | 24 | 77.38 | 78.14 | 81.67 | 71.98 | 87.20 | 21.70 | | 32 | 87.54 | 98.01 | 84.73 | 86.79 | 109.25 | 22.65 | | 48 | 121.54| 128.14 | 120.51 | 104.35 | 175.08 | 26.85 | ------------- Commit messages: - 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas Changes: https://git.openjdk.org/jdk/pull/28575/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28575&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371260 Stats: 628 lines in 33 files changed: 402 ins; 38 del; 188 mod Patch: https://git.openjdk.org/jdk/pull/28575.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28575/head:pull/28575 PR: https://git.openjdk.org/jdk/pull/28575 From alanb at openjdk.org Mon Dec 1 13:15:49 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Dec 2025 13:15:49 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith wrote: > MemorySegments allocated from shared Arena from > java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. > > The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . > > The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | > | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | > | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | > | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | > | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | > | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | > | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | > | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | > > After: > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | > | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | > | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | > | 8 | 58.22 | 31.60 | 36.87 | 31.72 | 47.09 |... Can you confirm that you aren't planning to try to try to integrate this before the fork for JDK 26 this week? There are several discussion points, and some of the changes are in risky areas, will likely need back time in main line. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3596489652 From alanb at openjdk.org Mon Dec 1 13:20:49 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Dec 2025 13:20:49 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith wrote: > MemorySegments allocated from shared Arena from > java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. > > The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . > > The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | > | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | > | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | > | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | > | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | > | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | > | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | > | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | > > After: > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | > | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | > | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | > | 8 | 58.22 | 31.60 | 36.87 | 31.72 | 47.09 |... src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 396: > 394: private final PendingFuture result; > 395: private volatile boolean released; > 396: private int ticket; // to release buffer scope This is for substitution, so needs to be declared with buf (further down), and needs to be volatile (can't use plain access as it may be released on different thread). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2577021290 From smonteith at openjdk.org Mon Dec 1 13:48:47 2025 From: smonteith at openjdk.org (Stuart Monteith) Date: Mon, 1 Dec 2025 13:48:47 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: <49FGQkAhjaiL3NugHvEzFGQhwTOf1oOKIPAUihJDgF0=.f19c5f9b-fa41-4fbe-9223-cba043dfa1d0@github.com> On Mon, 1 Dec 2025 13:13:13 GMT, Alan Bateman wrote: > Can you confirm that you aren't planning to try to try to integrate this before the fork for JDK 26 this week? There are several discussion points, and some of the changes are in risky areas, will likely need back time in main line. I am not planning, and wouldn't want to integrate this just before a fork. While I've checked it the best I can, I'd appreciate some scrutiny. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3596636408 From bpb at openjdk.org Mon Dec 1 17:01:28 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 1 Dec 2025 17:01:28 GMT Subject: Integrated: 8220816: (fs) Files.createDirectory should make it more obvious that it fails when the directory already exists In-Reply-To: References: Message-ID: <1QoIgHomITt7k-nINIxbSwpi8Wzu3R_NRIGHunlMPQ4=.9582c65d-7103-48d2-8da3-0283e2ad8d43@github.com> On Tue, 18 Nov 2025 17:41:24 GMT, Brian Burkhalter wrote: > Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location. This pull request has now been integrated. Changeset: 002fff39 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/002fff39aace870b27a9068de1662fcb0b3033a6 Stats: 27 lines in 1 file changed: 4 ins; 0 del; 23 mod 8220816: (fs) Files.createDirectory should make it more obvious that it fails when the directory already exists Reviewed-by: alanb, jpai ------------- PR: https://git.openjdk.org/jdk/pull/28378 From bpb at openjdk.org Mon Dec 1 17:01:27 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 1 Dec 2025 17:01:27 GMT Subject: RFR: 8220816: (fs) Files.createDirectory should make it more obvious that it fails when the directory already exists [v6] In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 20:13:42 GMT, Brian Burkhalter wrote: >> Slightly changes the specification of `Files.createDirectory` to highlight that it fails if a filesystem entity already exists at the given location. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8220816: Change FAEE for CREATE_NEW cases No new testable assertions were added or removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28378#issuecomment-3597732140 From mcimadamore at openjdk.org Mon Dec 1 18:26:47 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 1 Dec 2025 18:26:47 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith wrote: > MemorySegments allocated from shared Arena from > java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. > > The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . > > The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | > | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | > | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | > | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | > | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | > | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | > | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | > | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | > > After: > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | > | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | > | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | > | 8 | 58.22 | 31.60 | 36.87 | 31.72 | 47.09 |... Thanks for working on this problem. At the high level I understand your goal here. It is a bit unfortunate that we have to change the API for acquire/release which cascades in many smaller (but simple) changes throughout the JDK. But let's set that aside. The main (and more serious) issue with this PR is the decoupling of the liveness bit from the ref counting part. This is something that will require some time to work through to ensure correctness is preserved in all cases. More generally, it is generally advisable for such deep changes to perhaps reach out to panama-dev mailing list first, and maybe have a discussion/reach some consensus there, before moving ahead with a PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3598181959 From smonteith at openjdk.org Mon Dec 1 19:06:46 2025 From: smonteith at openjdk.org (Stuart Monteith) Date: Mon, 1 Dec 2025 19:06:46 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 18:24:07 GMT, Maurizio Cimadamore wrote: > Thanks for working on this problem. > > At the high level I understand your goal here. It is a bit unfortunate that we have to change the API for acquire/release which cascades in many smaller (but simple) changes throughout the JDK. But let's set that aside. Yes, that was regrettable. Originally I retained the "void release0()" that recalculated the "ticket", which resulted in fewer changes. However, it was felt the explicit ticket passing was less likely to introduce errors. > > The main (and more serious) issue with this PR is the decoupling of the liveness bit from the ref counting part. This is something that will require some time to work through to ensure correctness is preserved in all cases. > Yes, I had been grappling with the atomicity. The "acquireCount" and "state" are decoupled in the most recent revision of the, so this closing should either fail and not update state, or pass and complete the shutdown. However, the "state" and ScopedAccesses are complex, so I appreciate the scrutiny in that area. > More generally, it is generally advisable for such deep changes to perhaps reach out to panama-dev mailing list first, and maybe have a discussion/reach some consensus there, before moving ahead with a PR. That was my mistake - I expected that with the foreign ABI being merged, discussions on internals would have reverted to here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3598403208 From mcimadamore at openjdk.org Tue Dec 2 17:54:15 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 2 Dec 2025 17:54:15 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: <5CMXCgWmWnuATMxROM1zVobe9dv-6FrwCN7hJHfC8dc=.e153adc5-f91f-4fba-9ffe-eced1ab9cac6@github.com> On Mon, 1 Dec 2025 19:03:50 GMT, Stuart Monteith wrote: > That was my mistake - I expected that with the foreign ABI being merged, discussions on internals would have reverted to here. In general they are -- but I find that one issue with PRs is that they tend to be very code-centric, whereas in some cases it might be useful to discuss design options more abstractly and _then_ converge towards an implementation. And doing design discussions via PR is suboptimal. But, you did right in bringing this up! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3603277207 From bpb at openjdk.org Wed Dec 3 00:01:25 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 3 Dec 2025 00:01:25 GMT Subject: RFR: 8171432: (fs) WindowsWatchService.Poller::run does not call ReadDirectoryChangesW after a ERROR_NOTIFY_ENUM_DIR Message-ID: Call `ReadDirectoryChangesW` in `WindowsWatchService::Poller.run` if the `ERROR_NOTIFY_ENUM_DIR` error occurs. ------------- Commit messages: - 8171432: (fs) WindowsWatchService.Poller::run does not call ReadDirectoryChangesW after a ERROR_NOTIFY_ENUM_DIR Changes: https://git.openjdk.org/jdk/pull/28620/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28620&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8171432 Stats: 11 lines in 1 file changed: 2 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/28620.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28620/head:pull/28620 PR: https://git.openjdk.org/jdk/pull/28620 From bpb at openjdk.org Wed Dec 3 00:01:25 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 3 Dec 2025 00:01:25 GMT Subject: RFR: 8171432: (fs) WindowsWatchService.Poller::run does not call ReadDirectoryChangesW after a ERROR_NOTIFY_ENUM_DIR In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 23:53:14 GMT, Brian Burkhalter wrote: > Call `ReadDirectoryChangesW` in `WindowsWatchService::Poller.run` if the `ERROR_NOTIFY_ENUM_DIR` error occurs. This change was tested by artificially setting the error code to `ERROR_NOTIFY_ENUM_DIR` in `WindowsWatchService.java` after a certain number of iterations in `run()`. Without the proposed code change, the test `LotsOfEvents` failed but passed with the code change in place. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28620#issuecomment-3604435037 From alanb at openjdk.org Wed Dec 3 08:29:31 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Dec 2025 08:29:31 GMT Subject: RFR: 8372958: SocketInputStream.read throws SocketException instead of returning -1 when input shutdown Message-ID: Invoking Socket.shutdownInput at around the same time that another thread is attempts to read or is blocked in read on the same Socket has always been problematic on Windows. For virtual threads, the read may fail with a SocketException exception like "A request to send or receive data was disallowed because the socket had already been shut down in that direction with a previous shutdown call". The change proposed here to change the SocketImpl to handle the async shutdownInput and cause read to return -1. Tests for async shutdownInput and shutdownOutput are added to BlockingSocketsOps. Some minor drive by clean-up to use a value source for the tests that exercise both untimed and timed cases. Similar cleanup in BlockingChannelOps as it tests the socket adapters doing both untimed and timed reads. The existing test for async shutdown with platform threads is migrated to JUnit as part of the change. Testing: tier1 + tier2, test repeat runs of the modified tests to ensure they are stable. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/28626/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28626&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372958 Stats: 328 lines in 4 files changed: 98 ins; 160 del; 70 mod Patch: https://git.openjdk.org/jdk/pull/28626.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28626/head:pull/28626 PR: https://git.openjdk.org/jdk/pull/28626 From alanb at openjdk.org Wed Dec 3 08:52:17 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Dec 2025 08:52:17 GMT Subject: RFR: 8171432: (fs) WindowsWatchService.Poller::run does not call ReadDirectoryChangesW after a ERROR_NOTIFY_ENUM_DIR In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 23:53:14 GMT, Brian Burkhalter wrote: > Call `ReadDirectoryChangesW` in `WindowsWatchService::Poller.run` if the `ERROR_NOTIFY_ENUM_DIR` error occurs. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28620#pullrequestreview-3533854330 From djelinski at openjdk.org Wed Dec 3 10:47:40 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 3 Dec 2025 10:47:40 GMT Subject: RFR: 8372958: SocketInputStream.read throws SocketException instead of returning -1 when input shutdown In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 07:47:40 GMT, Alan Bateman wrote: > Invoking Socket.shutdownInput at around the same time that another thread is attempts to read or is blocked in read on the same Socket has always been problematic on Windows. For virtual threads, the read may fail with a SocketException exception like "A request to send or receive data was disallowed because the socket had already been shut down in that direction with a previous shutdown call". The change proposed here to change the SocketImpl to handle the async shutdownInput and cause read to return -1. > > Tests for async shutdownInput and shutdownOutput are added to BlockingSocketsOps. Some minor drive by clean-up to use a value source for the tests that exercise both untimed and timed cases. Similar cleanup in BlockingChannelOps as it tests the socket adapters doing both untimed and timed reads. The existing test for async shutdown with platform threads is migrated to JUnit as part of the change. > > Testing: tier1 + tier2, test repeat runs of the modified tests to ensure they are stable. Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28626#pullrequestreview-3534415275 From djelinski at openjdk.org Wed Dec 3 10:55:51 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 3 Dec 2025 10:55:51 GMT Subject: RFR: 8171432: (fs) WindowsWatchService.Poller::run does not call ReadDirectoryChangesW after a ERROR_NOTIFY_ENUM_DIR In-Reply-To: References: Message-ID: <5g5vJdiHLKJxFeVhu9k9i03PyfL16hWWwAFlM9DckZI=.91281665-d4bb-41ae-a649-b715c75e54b4@github.com> On Tue, 2 Dec 2025 23:53:14 GMT, Brian Burkhalter wrote: > Call `ReadDirectoryChangesW` in `WindowsWatchService::Poller.run` if the `ERROR_NOTIFY_ENUM_DIR` error occurs. Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28620#pullrequestreview-3534458560 From michaelm at openjdk.org Wed Dec 3 11:17:38 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 3 Dec 2025 11:17:38 GMT Subject: RFR: 8372958: SocketInputStream.read throws SocketException instead of returning -1 when input shutdown In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 07:47:40 GMT, Alan Bateman wrote: > Invoking Socket.shutdownInput at around the same time that another thread is attempts to read or is blocked in read on the same Socket has always been problematic on Windows. For virtual threads, the read may fail with a SocketException exception like "A request to send or receive data was disallowed because the socket had already been shut down in that direction with a previous shutdown call". The change proposed here to change the SocketImpl to handle the async shutdownInput and cause read to return -1. > > Tests for async shutdownInput and shutdownOutput are added to BlockingSocketsOps. Some minor drive by clean-up to use a value source for the tests that exercise both untimed and timed cases. Similar cleanup in BlockingChannelOps as it tests the socket adapters doing both untimed and timed reads. The existing test for async shutdown with platform threads is migrated to JUnit as part of the change. > > Testing: tier1 + tier2, test repeat runs of the modified tests to ensure they are stable. Looks fine ------------- Marked as reviewed by michaelm (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28626#pullrequestreview-3534557280 From alanb at openjdk.org Wed Dec 3 13:07:13 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Dec 2025 13:07:13 GMT Subject: RFR: 8372958: SocketInputStream.read throws SocketException instead of returning -1 when input shutdown In-Reply-To: References: Message-ID: <4u1usvCrVhEfW4p182tW_JOvUixWgdgn2ydN4AMbdt0=.22bbf4d8-74ca-41fd-ae47-ff3781bbad3d@github.com> On Wed, 3 Dec 2025 07:47:40 GMT, Alan Bateman wrote: > Invoking Socket.shutdownInput at around the same time that another thread attempts to read or is blocked in read on the same Socket has always been problematic on Windows. For virtual threads, the read may fail with a SocketException exception like "A request to send or receive data was disallowed because the socket had already been shut down in that direction with a previous shutdown call". The change proposed here to change the SocketImpl to handle the async shutdownInput and cause read to return -1. > > Tests for async shutdownInput and shutdownOutput are added to BlockingSocketsOps. Some minor drive by clean-up to use a value source for the tests that exercise both untimed and timed cases. Similar cleanup in BlockingChannelOps as it tests the socket adapters doing both untimed and timed reads. The existing test for async shutdown with platform threads is migrated to JUnit as part of the change. > > Testing: tier1 + tier2, test repeat runs of the modified tests to ensure they are stable. Thanks for quick review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28626#issuecomment-3606752964 From alanb at openjdk.org Wed Dec 3 13:07:14 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Dec 2025 13:07:14 GMT Subject: Integrated: 8372958: SocketInputStream.read throws SocketException instead of returning -1 when input shutdown In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 07:47:40 GMT, Alan Bateman wrote: > Invoking Socket.shutdownInput at around the same time that another thread attempts to read or is blocked in read on the same Socket has always been problematic on Windows. For virtual threads, the read may fail with a SocketException exception like "A request to send or receive data was disallowed because the socket had already been shut down in that direction with a previous shutdown call". The change proposed here to change the SocketImpl to handle the async shutdownInput and cause read to return -1. > > Tests for async shutdownInput and shutdownOutput are added to BlockingSocketsOps. Some minor drive by clean-up to use a value source for the tests that exercise both untimed and timed cases. Similar cleanup in BlockingChannelOps as it tests the socket adapters doing both untimed and timed reads. The existing test for async shutdown with platform threads is migrated to JUnit as part of the change. > > Testing: tier1 + tier2, test repeat runs of the modified tests to ensure they are stable. This pull request has now been integrated. Changeset: afb6a0c2 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/afb6a0c2fecdb2114715290d5d463c9dccf93c28 Stats: 328 lines in 4 files changed: 98 ins; 160 del; 70 mod 8372958: SocketInputStream.read throws SocketException instead of returning -1 when input shutdown Reviewed-by: djelinski, michaelm ------------- PR: https://git.openjdk.org/jdk/pull/28626 From bpb at openjdk.org Wed Dec 3 20:03:21 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 3 Dec 2025 20:03:21 GMT Subject: Integrated: 8171432: (fs) WindowsWatchService.Poller::run does not call ReadDirectoryChangesW after a ERROR_NOTIFY_ENUM_DIR In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 23:53:14 GMT, Brian Burkhalter wrote: > Call `ReadDirectoryChangesW` in `WindowsWatchService::Poller.run` if the `ERROR_NOTIFY_ENUM_DIR` error occurs. This pull request has now been integrated. Changeset: 8a5db916 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/8a5db916aff1dc3eb37f25afbf0a633aa77baa20 Stats: 11 lines in 1 file changed: 2 ins; 1 del; 8 mod 8171432: (fs) WindowsWatchService.Poller::run does not call ReadDirectoryChangesW after a ERROR_NOTIFY_ENUM_DIR Reviewed-by: alanb, djelinski ------------- PR: https://git.openjdk.org/jdk/pull/28620 From smonteith at openjdk.org Thu Dec 4 16:24:25 2025 From: smonteith at openjdk.org (Stuart Monteith) Date: Thu, 4 Dec 2025 16:24:25 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith wrote: > MemorySegments allocated from shared Arena from > java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. > > The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . > > The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | > | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | > | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | > | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | > | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | > | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | > | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | > | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | > > After: > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | > | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | > | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | > | 8 | 58.22 | 31.60 | 36.87 | 31.72 | 47.09 |... I'll start a discussion soon on panama-dev. At the very least, this PR provides a point of discussion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3613061007 From mcimadamore at openjdk.org Fri Dec 5 22:25:56 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 5 Dec 2025 22:25:56 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 16:22:08 GMT, Stuart Monteith wrote: > I'll start a discussion soon on panama-dev. At the very least, this PR provides a point of discussion. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3618818702 From duke at openjdk.org Sat Dec 6 13:02:56 2025 From: duke at openjdk.org (ExE Boss) Date: Sat, 6 Dec 2025 13:02:56 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith wrote: > MemorySegments allocated from shared Arena from > java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. > > The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . > > The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | > | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | > | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | > | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | > | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | > | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | > | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | > | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | > > After: > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | > | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | > | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | > | 8 | 58.22 | 31.60 | 36.87 | 31.72 | 47.09 |... src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 89: > 87: @ForceInline > 88: private int getCounter() { > 89: return Thread.currentThread().hashCode() & mask; Maybe use?[`System?::identityHashCode`] here?instead, as?the?`hashCode()`?method of?a?`Thread` can?be?overridden by?subclasses. Suggestion: return System.identityHashCode(Thread.currentThread()) & mask; [`System?::identityHashCode`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/System.html#identityHashCode%28java.lang.Object%29 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2594828923 From bpb at openjdk.org Mon Dec 8 19:21:18 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 8 Dec 2025 19:21:18 GMT Subject: RFR: 8371718: (sc) Channels.new{Input,Output}Stream can allocate unbounded memory for a socket channel Message-ID: Clamp read and write to 128k bytes. ------------- Commit messages: - 8371718: (sc) Channels.new{Input,Output}Stream can allocate unbounded memory for a socket channel Changes: https://git.openjdk.org/jdk/pull/28705/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28705&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371718 Stats: 44 lines in 5 files changed: 34 ins; 1 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28705/head:pull/28705 PR: https://git.openjdk.org/jdk/pull/28705 From alanb at openjdk.org Mon Dec 8 19:21:19 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 8 Dec 2025 19:21:19 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 19:10:42 GMT, Brian Burkhalter wrote: > Clamp read and write to 128k bytes. src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 83: > 81: // The maximum number of bytes to read/write per syscall to avoid needing > 82: // a huge buffer from the temporary buffer cache > 83: static final int MAX_ADAPTOR_BUFFER_SIZE = 128 * 1024; The channel adaptors shouldn't be used the SocketImpl implementation. I think we add a MAX_BUFFER_SIZE constants to Streams. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2599830711 From alanb at openjdk.org Mon Dec 8 19:24:07 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 8 Dec 2025 19:24:07 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 19:10:42 GMT, Brian Burkhalter wrote: > Clamp read and write to 128k bytes. src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 86: > 84: if (bb.remaining() > MAX_ADAPTOR_BUFFER_SIZE) { > 85: bb = bb.slice(bb.position(), MAX_ADAPTOR_BUFFER_SIZE); > 86: } I think we should limit the length in `read(byte[] bs, int off, int len)`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2599838951 From alanb at openjdk.org Mon Dec 8 19:30:57 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 8 Dec 2025 19:30:57 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel In-Reply-To: References: Message-ID: <1tYZdsH_-UVsUkLzQlgDTl591uyY5P05YlQPtsK0oDI=.9cc1eaaf-9218-4e3c-94b2-f8a68d238212@github.com> On Mon, 8 Dec 2025 19:10:42 GMT, Brian Burkhalter wrote: > Clamp read and write to 128k bytes. src/java.base/share/classes/sun/nio/ch/ChannelOutputStream.java line 71: > 69: ByteBuffer writeBuf = bb.remaining() <= MAX_ADAPTOR_BUFFER_SIZE > 70: ? bb : bb.slice(bb.position(), MAX_ADAPTOR_BUFFER_SIZE); > 71: int n = ch.write(writeBuf); This just need to adjust the limit, no need for slice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2599857802 From bpb at openjdk.org Mon Dec 8 21:24:37 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 8 Dec 2025 21:24:37 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel [v2] In-Reply-To: References: Message-ID: > Clamp read and write to 128k bytes. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8371718: Address reviewer comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28705/files - new: https://git.openjdk.org/jdk/pull/28705/files/113a430d..3aa2f796 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28705&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28705&range=00-01 Stats: 25 lines in 5 files changed: 8 ins; 3 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/28705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28705/head:pull/28705 PR: https://git.openjdk.org/jdk/pull/28705 From bpb at openjdk.org Mon Dec 8 21:41:38 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 8 Dec 2025 21:41:38 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel [v3] In-Reply-To: References: Message-ID: > Clamp read and write to 128k bytes. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8371718: Move limit retrieval outside loop ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28705/files - new: https://git.openjdk.org/jdk/pull/28705/files/3aa2f796..1e7aefd9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28705&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28705&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28705/head:pull/28705 PR: https://git.openjdk.org/jdk/pull/28705 From alanb at openjdk.org Tue Dec 9 08:08:05 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 9 Dec 2025 08:08:05 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel [v3] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 21:41:38 GMT, Brian Burkhalter wrote: >> Clamp read and write to 128k bytes. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8371718: Move limit retrieval outside loop src/java.base/share/classes/sun/nio/ch/ChannelOutputStream.java line 76: > 74: if (n <= 0) > 75: throw new RuntimeException("no bytes written"); > 76: bb.limit(limit); Setting the limit twice per iteration is a bit confusing, maybe simplify this loop to: int pos = bb.position(); int rem = bb.limit() - pos; while (rem > 0) { bb.limit(pos + Math.min(MAX_BUFFER_SIZE, rem)); int n = channelWrite(bb); if (n <= 0) throw new RuntimeException("no bytes written"); pos += n; rem -= n; } In passing, the pre-existing throwing of RuntimeException should be re-examined at some point. src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 61: > 59: import static java.net.StandardProtocolFamily.INET6; > 60: import static java.net.StandardProtocolFamily.UNIX; > 61: import static sun.nio.ch.Streams.MAX_BUFFER_SIZE; This is not generally useful for the SocketChannel implementation, it is instead for the sole use of the methods that take an input/output stream. So I think better to use Streams.MAX_BUFFER_SIZE in the two methods rather than static import. test/jdk/java/nio/channels/Channels/SocketChannelStreams.java line 76: > 74: * Test writing and reading an array of bytes. > 75: */ > 76: public void testWriteRead() throws Exception { I don't think this test is useful as there are a lot of tests here that do this. I think the test for this change will use a custom ByteChannel implementation that fails if called with a buffer that are >128k remaining. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2601514295 PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2601462657 PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2601522666 From alanb at openjdk.org Tue Dec 9 08:22:01 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 9 Dec 2025 08:22:01 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel [v3] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 21:41:38 GMT, Brian Burkhalter wrote: >> Clamp read and write to 128k bytes. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8371718: Move limit retrieval outside loop src/java.base/share/classes/sun/nio/ch/Streams.java line 38: > 36: // The maximum number of bytes to read/write per syscall to avoid needing > 37: // a huge buffer from the temporary buffer cache > 38: static final int MAX_BUFFER_SIZE = 128 * 1024; It would be okay for NioSocketImpl to use this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2601561998 From jpai at openjdk.org Tue Dec 9 14:44:31 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 9 Dec 2025 14:44:31 GMT Subject: RFR: 8255463: java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java failed with ThreadTimeoutException Message-ID: Can I please get a review of this test-only change which removes the testng specific timeout from a test method? As noted in https://bugs.openjdk.org/browse/JDK-8255463, the `test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java` fails intermittently with: test InheritedChannelTest.test("StateTest", java.util.ImmutableCollections$List12 at d28f210): failure [30001ms] org.testng.internal.thread.ThreadTimeoutException: Method InheritedChannelTest.test() didn't finish within the time-out 30000 With the proposed change in this PR, it now relies on jtreg test timeout (default of 120 seconds). If the test continues to timeout for whatever reason, then jtreg will be able to capture the relevant thread dumps of the incomplete process (launched in this test method) to help debug the issue. The existing 30 second timeout on the test method doesn't play any role in what the test verifies, so removing it doesn't change that verification. ------------- Commit messages: - 8255463: java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java failed with ThreadTimeoutException Changes: https://git.openjdk.org/jdk/pull/28721/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28721&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8255463 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28721.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28721/head:pull/28721 PR: https://git.openjdk.org/jdk/pull/28721 From dfuchs at openjdk.org Tue Dec 9 15:18:07 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 9 Dec 2025 15:18:07 GMT Subject: RFR: 8255463: java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java failed with ThreadTimeoutException In-Reply-To: References: Message-ID: <2DpfNZGrioOo_qZYv_GIqoCCxJyX7L3TcLM_69yVWJ4=.1a0107b1-40c6-4c7e-83ec-3dbce68f6c48@github.com> On Tue, 9 Dec 2025 14:36:11 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which removes the testng specific timeout from a test method? > > As noted in https://bugs.openjdk.org/browse/JDK-8255463, the `test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java` fails intermittently with: > > > test InheritedChannelTest.test("StateTest", java.util.ImmutableCollections$List12 at d28f210): failure [30001ms] > org.testng.internal.thread.ThreadTimeoutException: Method InheritedChannelTest.test() didn't finish within the time-out 30000 > > With the proposed change in this PR, it now relies on jtreg test timeout (default of 120 seconds). If the test continues to timeout for whatever reason, then jtreg will be able to capture the relevant thread dumps of the incomplete process (launched in this test method) to help debug the issue. > > The existing 30 second timeout on the test method doesn't play any role in what the test verifies, so removing it doesn't change that verification. Looks trivial to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28721#pullrequestreview-3557997566 From djelinski at openjdk.org Tue Dec 9 15:23:36 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 9 Dec 2025 15:23:36 GMT Subject: RFR: 8255463: java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java failed with ThreadTimeoutException In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 14:36:11 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which removes the testng specific timeout from a test method? > > As noted in https://bugs.openjdk.org/browse/JDK-8255463, the `test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java` fails intermittently with: > > > test InheritedChannelTest.test("StateTest", java.util.ImmutableCollections$List12 at d28f210): failure [30001ms] > org.testng.internal.thread.ThreadTimeoutException: Method InheritedChannelTest.test() didn't finish within the time-out 30000 > > With the proposed change in this PR, it now relies on jtreg test timeout (default of 120 seconds). If the test continues to timeout for whatever reason, then jtreg will be able to capture the relevant thread dumps of the incomplete process (launched in this test method) to help debug the issue. > > The existing 30 second timeout on the test method doesn't play any role in what the test verifies, so removing it doesn't change that verification. Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28721#pullrequestreview-3558033106 From bpb at openjdk.org Tue Dec 9 16:33:34 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 9 Dec 2025 16:33:34 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel [v3] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 08:01:47 GMT, Alan Bateman wrote: > Setting the limit twice per iteration is a bit confusing I actually made this change locally but decided against it. I'll take a second look. > I think better to use Streams.MAX_BUFFER_SIZE in the two methods rather than static import. I agree and had also thought to make this change. > It would be okay for NioSocketImpl to use this. Will change. > I don't think this test is useful as there are a lot of tests here that do this. It was intended to verify loops in an alternative implementation I wrote last week so can be reverted I think. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2603411172 PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2603408573 PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2603416204 PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2603414659 From bpb at openjdk.org Tue Dec 9 16:57:12 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 9 Dec 2025 16:57:12 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel [v3] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 16:29:06 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/sun/nio/ch/ChannelOutputStream.java line 76: >> >>> 74: if (n <= 0) >>> 75: throw new RuntimeException("no bytes written"); >>> 76: bb.limit(limit); >> >> Setting the limit twice per iteration is a bit confusing, maybe simplify this loop to: >> >> int pos = bb.position(); >> int rem = bb.limit() - pos; >> while (rem > 0) { >> bb.limit(pos + Math.min(MAX_BUFFER_SIZE, rem)); >> int n = channelWrite(bb); >> if (n <= 0) >> throw new RuntimeException("no bytes written"); >> pos += n; >> rem -= n; >> } >> >> In passing, the pre-existing throwing of RuntimeException should be re-examined at some point. > >> Setting the limit twice per iteration is a bit confusing > > I actually made this change locally but decided against it. I'll take a second look. > In passing, the pre-existing throwing of RuntimeException should be re-examined at some point. For this case, FileOutputStream throws an IOException with message "Write error" and IOUtil.convertReturnVal throws an IOException with message "Read/write failed". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2603499279 From bpb at openjdk.org Tue Dec 9 17:09:36 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 9 Dec 2025 17:09:36 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel [v4] In-Reply-To: References: Message-ID: > Clamp read and write to 128k bytes. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8371718: Address reviewer comments v2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28705/files - new: https://git.openjdk.org/jdk/pull/28705/files/1e7aefd9..3f2983ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28705&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28705&range=02-03 Stats: 46 lines in 5 files changed: 1 ins; 32 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/28705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28705/head:pull/28705 PR: https://git.openjdk.org/jdk/pull/28705 From bpb at openjdk.org Tue Dec 9 17:17:36 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 9 Dec 2025 17:17:36 GMT Subject: RFR: 8255463: java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java failed with ThreadTimeoutException In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 14:36:11 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which removes the testng specific timeout from a test method? > > As noted in https://bugs.openjdk.org/browse/JDK-8255463, the `test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java` fails intermittently with: > > > test InheritedChannelTest.test("StateTest", java.util.ImmutableCollections$List12 at d28f210): failure [30001ms] > org.testng.internal.thread.ThreadTimeoutException: Method InheritedChannelTest.test() didn't finish within the time-out 30000 > > With the proposed change in this PR, it now relies on jtreg test timeout (default of 120 seconds). If the test continues to timeout for whatever reason, then jtreg will be able to capture the relevant thread dumps of the incomplete process (launched in this test method) to help debug the issue. > > The existing 30 second timeout on the test method doesn't play any role in what the test verifies, so removing it doesn't change that verification. Looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28721#pullrequestreview-3558619757 From alanb at openjdk.org Tue Dec 9 17:49:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 9 Dec 2025 17:49:54 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel [v4] In-Reply-To: References: Message-ID: <06hneJuAepBceiN2jQ89V4F3bjKnyUiR2xil5h8ctcM=.4bb742d7-c635-4ff9-8a12-421c2c494b9c@github.com> On Tue, 9 Dec 2025 17:09:36 GMT, Brian Burkhalter wrote: >> Clamp read and write to 128k bytes. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8371718: Address reviewer comments v2 src/java.base/share/classes/sun/nio/ch/ChannelOutputStream.java line 73: > 71: int n = ch.write(bb); > 72: if (n <= 0) > 73: throw new IOException("Write failed"); It would be a broken WritableByteChannel implementation to return < 0. If it were a non-blocking then IllegalBlockingModeException would be thrown already. So I think this throw IOException is okay here but it is a sign of a broken channel implementation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2603667396 From alanb at openjdk.org Tue Dec 9 17:50:05 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 9 Dec 2025 17:50:05 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel [v3] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 16:30:08 GMT, Brian Burkhalter wrote: >> test/jdk/java/nio/channels/Channels/SocketChannelStreams.java line 76: >> >>> 74: * Test writing and reading an array of bytes. >>> 75: */ >>> 76: public void testWriteRead() throws Exception { >> >> I don't think this test is useful as there are a lot of tests here that do this. I think the test for this change will use a custom ByteChannel implementation that fails if called with a buffer that are >128k remaining. > >> I don't think this test is useful as there are a lot of tests here that do this. > > It was intended to verify loops in an alternative implementation I wrote last week so can be reverted I think. I think we can add a new test with test channel implementations that throw if invoked with remaining > 128k. That would at least test the changes to ChannelInputStream and ChannelOutputStream. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2603676782 From bpb at openjdk.org Tue Dec 9 18:38:19 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 9 Dec 2025 18:38:19 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel [v3] In-Reply-To: References: Message-ID: <9DSEGdrCibZB3y1HETPi3cXWshDmFALgt3Mc2Yyr5qw=.26a3a8d7-d965-4f77-b13c-9aef5a209269@github.com> On Tue, 9 Dec 2025 17:42:46 GMT, Alan Bateman wrote: > I think we can add a new test with test channel implementations that throw if invoked with remaining > 128k. That would at least test the changes to ChannelInputStream and ChannelOutputStream. I am not sure this is feasible for ChannelOutputStream as it uses writeFully which loops until all bytes are written. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2603855242 From bpb at openjdk.org Tue Dec 9 18:43:30 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 9 Dec 2025 18:43:30 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel [v3] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 16:54:17 GMT, Brian Burkhalter wrote: >>> Setting the limit twice per iteration is a bit confusing >> >> I actually made this change locally but decided against it. I'll take a second look. > >> In passing, the pre-existing throwing of RuntimeException should be re-examined at some point. > > For this case, FileOutputStream throws an IOException with message "Write error" and IOUtil.convertReturnVal throws an IOException with message "Read/write failed". > if (n <= 0) > throw new RuntimeException("no bytes written"); > pos += n; > rem -= n; This failed to update the buffer position in the loop. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2603886913 From bpb at openjdk.org Tue Dec 9 18:43:31 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 9 Dec 2025 18:43:31 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel [v3] In-Reply-To: <9DSEGdrCibZB3y1HETPi3cXWshDmFALgt3Mc2Yyr5qw=.26a3a8d7-d965-4f77-b13c-9aef5a209269@github.com> References: <9DSEGdrCibZB3y1HETPi3cXWshDmFALgt3Mc2Yyr5qw=.26a3a8d7-d965-4f77-b13c-9aef5a209269@github.com> Message-ID: <3faxQosYLg1PYg5J6-4sxzfrtJ_kc74pmgo7RcUaCc0=.684f8ba7-c0a9-4f8c-a11d-da579b791537@github.com> On Tue, 9 Dec 2025 18:34:19 GMT, Brian Burkhalter wrote: > I am not sure this is feasible for ChannelOutputStream as it uses writeFully which loops until all bytes are written. Never mind. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2603876043 From bpb at openjdk.org Tue Dec 9 18:51:55 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 9 Dec 2025 18:51:55 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel [v5] In-Reply-To: References: Message-ID: > Clamp read and write to 128k bytes. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8371718: Add tests; fix ChannelOutputStream.write ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28705/files - new: https://git.openjdk.org/jdk/pull/28705/files/3f2983ad..956d64b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28705&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28705&range=03-04 Stats: 76 lines in 2 files changed: 75 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28705/head:pull/28705 PR: https://git.openjdk.org/jdk/pull/28705 From bpb at openjdk.org Tue Dec 9 19:11:31 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 9 Dec 2025 19:11:31 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel [v6] In-Reply-To: References: Message-ID: > Clamp read and write to 128k bytes. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8371718: Make test cleaner ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28705/files - new: https://git.openjdk.org/jdk/pull/28705/files/956d64b2..6f2e8568 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28705&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28705&range=04-05 Stats: 46 lines in 1 file changed: 4 ins; 18 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/28705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28705/head:pull/28705 PR: https://git.openjdk.org/jdk/pull/28705 From alanb at openjdk.org Tue Dec 9 21:15:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 9 Dec 2025 21:15:51 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel [v6] In-Reply-To: References: Message-ID: <60CEf13jA2oWWX2y77OiAI-gvtAoNU08BwEVcX5X6XE=.5346cdf4-7828-4814-9fac-a5c35e9a7725@github.com> On Tue, 9 Dec 2025 19:11:31 GMT, Brian Burkhalter wrote: >> Clamp read and write to 128k bytes. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8371718: Make test cleaner src/java.base/share/classes/sun/nio/ch/ChannelOutputStream.java line 76: > 74: pos += n; > 75: rem -= n; > 76: bb.position(pos); I assume this line is not needed as ch.write(bb) will advance the position by n. test/jdk/java/nio/channels/Channels/SocketChannelStreams.java line 25: > 23: > 24: /* @test > 25: * @bug 8279339 I suppose we add to the `@bug` line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2604280051 PR Review Comment: https://git.openjdk.org/jdk/pull/28705#discussion_r2604286770 From bpb at openjdk.org Wed Dec 10 00:31:25 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 10 Dec 2025 00:31:25 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel [v7] In-Reply-To: References: Message-ID: <3kL5iQmF993WTGfYj6mwGVhaylCBMH3xprraCaMN7Ok=.b1ad81c6-dc0c-4ca9-a6ba-fe6ddba07909@github.com> > Clamp read and write to 128k bytes. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8371718: Remove duplicative position update; add bug ID to test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28705/files - new: https://git.openjdk.org/jdk/pull/28705/files/6f2e8568..e8036cf8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28705&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28705&range=05-06 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28705/head:pull/28705 PR: https://git.openjdk.org/jdk/pull/28705 From jpai at openjdk.org Wed Dec 10 02:07:15 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 10 Dec 2025 02:07:15 GMT Subject: RFR: 8255463: java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java failed with ThreadTimeoutException In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 14:36:11 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which removes the testng specific timeout from a test method? > > As noted in https://bugs.openjdk.org/browse/JDK-8255463, the `test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java` fails intermittently with: > > > test InheritedChannelTest.test("StateTest", java.util.ImmutableCollections$List12 at d28f210): failure [30001ms] > org.testng.internal.thread.ThreadTimeoutException: Method InheritedChannelTest.test() didn't finish within the time-out 30000 > > With the proposed change in this PR, it now relies on jtreg test timeout (default of 120 seconds). If the test continues to timeout for whatever reason, then jtreg will be able to capture the relevant thread dumps of the incomplete process (launched in this test method) to help debug the issue. > > The existing 30 second timeout on the test method doesn't play any role in what the test verifies, so removing it doesn't change that verification. Thank you all for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28721#issuecomment-3635035133 From jpai at openjdk.org Wed Dec 10 02:07:16 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 10 Dec 2025 02:07:16 GMT Subject: Integrated: 8255463: java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java failed with ThreadTimeoutException In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 14:36:11 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which removes the testng specific timeout from a test method? > > As noted in https://bugs.openjdk.org/browse/JDK-8255463, the `test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java` fails intermittently with: > > > test InheritedChannelTest.test("StateTest", java.util.ImmutableCollections$List12 at d28f210): failure [30001ms] > org.testng.internal.thread.ThreadTimeoutException: Method InheritedChannelTest.test() didn't finish within the time-out 30000 > > With the proposed change in this PR, it now relies on jtreg test timeout (default of 120 seconds). If the test continues to timeout for whatever reason, then jtreg will be able to capture the relevant thread dumps of the incomplete process (launched in this test method) to help debug the issue. > > The existing 30 second timeout on the test method doesn't play any role in what the test verifies, so removing it doesn't change that verification. This pull request has now been integrated. Changeset: a2622129 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/a26221299e657b64379d2d56ed3b073f12b227d1 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8255463: java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java failed with ThreadTimeoutException Reviewed-by: dfuchs, djelinski, bpb ------------- PR: https://git.openjdk.org/jdk/pull/28721 From alanb at openjdk.org Wed Dec 10 06:46:24 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 10 Dec 2025 06:46:24 GMT Subject: RFR: 8371718: (sc) Channels.new{Input, Output}Stream can allocate unbounded memory for a socket channel [v7] In-Reply-To: <3kL5iQmF993WTGfYj6mwGVhaylCBMH3xprraCaMN7Ok=.b1ad81c6-dc0c-4ca9-a6ba-fe6ddba07909@github.com> References: <3kL5iQmF993WTGfYj6mwGVhaylCBMH3xprraCaMN7Ok=.b1ad81c6-dc0c-4ca9-a6ba-fe6ddba07909@github.com> Message-ID: On Wed, 10 Dec 2025 00:31:25 GMT, Brian Burkhalter wrote: >> Clamp read and write to 128k bytes. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8371718: Remove duplicative position update; add bug ID to test Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28705#pullrequestreview-3560994872 From smonteith at openjdk.org Wed Dec 10 09:06:32 2025 From: smonteith at openjdk.org (Stuart Monteith) Date: Wed, 10 Dec 2025 09:06:32 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Sat, 6 Dec 2025 12:55:37 GMT, ExE Boss wrote: >> MemorySegments allocated from shared Arena from >> java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. >> >> The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . >> >> The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. >> >> | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | >> |---------|-------|-------|-------|-------|-------|-------| >> | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | >> | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | >> | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | >> | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | >> | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | >> | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | >> | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | >> | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | >> >> After: >> >> | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | >> |---------|-------|-------|-------|-------|-------|-------| >> | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | >> | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | >> | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | >> | 8 | 58... > > src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 89: > >> 87: @ForceInline >> 88: private int getCounter() { >> 89: return Thread.currentThread().hashCode() & mask; > > Maybe use?[`System?::identityHashCode`] here?instead, as?the?`hashCode()`?method of?a?`Thread` can?be?overridden by?subclasses. > Suggestion: > > return System.identityHashCode(Thread.currentThread()) & mask; > > > [`System?::identityHashCode`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/System.html#identityHashCode%28java.lang.Object%29 Thanks - that's a good suggestion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2605783455 From duke at openjdk.org Wed Dec 10 22:25:36 2025 From: duke at openjdk.org (duke) Date: Wed, 10 Dec 2025 22:25:36 GMT Subject: Withdrawn: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 10:38:01 GMT, Darragh Clarke wrote: > This PR was originally part of #25546, though that PR has been split in 2, the first chunk was https://github.com/openjdk/jdk/pull/27590. > > This PR aims to convert KQueue to use FFM apis, the first PR in this area added all the jextract generated code needed, while this PR modifies some of the jextract code and then uses it with Kqueue. > > A brief rundown of the changes: > - The files `errno_h$shared.java` , `kqueue_h$shared.java`, `timespec_h$shared.java` and `timespec_h.java` have all been deleted. This is because they all contained shared elements that could be moved into the Utility file `FFMUtils.java` > - `Kqueue.c` has been deleted, and all native methods in the other `KQueue` files have been replaced with references to the generated files kevent and kqueue. This is the bulk of the changes > - Both the `Kqueue()` and `Kevent()` methods in `kqueue_h.java` were modified to use adapted method handles that will return the errno value This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27796 From bpb at openjdk.org Wed Dec 10 22:49:12 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 10 Dec 2025 22:49:12 GMT Subject: Integrated: 8371718: (sc) Channels.new{Input,Output}Stream can allocate unbounded memory for a socket channel In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 19:10:42 GMT, Brian Burkhalter wrote: > Clamp read and write to 128k bytes. This pull request has now been integrated. Changeset: 74dca863 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/74dca863c2e61c13884c3454b8da7be125235970 Stats: 88 lines in 6 files changed: 72 ins; 5 del; 11 mod 8371718: (sc) Channels.new{Input,Output}Stream can allocate unbounded memory for a socket channel Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/28705 From sshivang at openjdk.org Thu Dec 18 04:38:27 2025 From: sshivang at openjdk.org (Shivangi Gupta) Date: Thu, 18 Dec 2025 04:38:27 GMT Subject: [jdk26] RFR: 8255463: java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java failed with ThreadTimeoutException Message-ID: <88pRDuSP8VE2oFp8IUjH0Ozip-wKz7Ez8TBBhDLPEMk=.784dc6f3-4390-45df-9da4-cfc7ef9548da@github.com> Ran the test 50 times and it passed . Straight Backport. ------------- Commit messages: - Backport a26221299e657b64379d2d56ed3b073f12b227d1 Changes: https://git.openjdk.org/jdk/pull/28888/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28888&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8255463 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28888.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28888/head:pull/28888 PR: https://git.openjdk.org/jdk/pull/28888 From jpai at openjdk.org Thu Dec 18 04:57:51 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 18 Dec 2025 04:57:51 GMT Subject: [jdk26] RFR: 8255463: java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java failed with ThreadTimeoutException In-Reply-To: <88pRDuSP8VE2oFp8IUjH0Ozip-wKz7Ez8TBBhDLPEMk=.784dc6f3-4390-45df-9da4-cfc7ef9548da@github.com> References: <88pRDuSP8VE2oFp8IUjH0Ozip-wKz7Ez8TBBhDLPEMk=.784dc6f3-4390-45df-9da4-cfc7ef9548da@github.com> Message-ID: On Thu, 18 Dec 2025 04:22:46 GMT, Shivangi Gupta wrote: > Ran the test 50 times and it passed . Straight Backport. Looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28888#pullrequestreview-3590772307 From duke at openjdk.org Thu Dec 18 04:57:52 2025 From: duke at openjdk.org (duke) Date: Thu, 18 Dec 2025 04:57:52 GMT Subject: [jdk26] RFR: 8255463: java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java failed with ThreadTimeoutException In-Reply-To: <88pRDuSP8VE2oFp8IUjH0Ozip-wKz7Ez8TBBhDLPEMk=.784dc6f3-4390-45df-9da4-cfc7ef9548da@github.com> References: <88pRDuSP8VE2oFp8IUjH0Ozip-wKz7Ez8TBBhDLPEMk=.784dc6f3-4390-45df-9da4-cfc7ef9548da@github.com> Message-ID: On Thu, 18 Dec 2025 04:22:46 GMT, Shivangi Gupta wrote: > Ran the test 50 times and it passed . Straight Backport. @Shivangi-aa Your change (at version b1e8b0bd19ab8b7b972d77665cd0d5efa7367e0e) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28888#issuecomment-3668373381 From sshivang at openjdk.org Thu Dec 18 05:07:02 2025 From: sshivang at openjdk.org (Shivangi Gupta) Date: Thu, 18 Dec 2025 05:07:02 GMT Subject: [jdk26] Integrated: 8255463: java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java failed with ThreadTimeoutException In-Reply-To: <88pRDuSP8VE2oFp8IUjH0Ozip-wKz7Ez8TBBhDLPEMk=.784dc6f3-4390-45df-9da4-cfc7ef9548da@github.com> References: <88pRDuSP8VE2oFp8IUjH0Ozip-wKz7Ez8TBBhDLPEMk=.784dc6f3-4390-45df-9da4-cfc7ef9548da@github.com> Message-ID: On Thu, 18 Dec 2025 04:22:46 GMT, Shivangi Gupta wrote: > Ran the test 50 times and it passed . Straight Backport. This pull request has now been integrated. Changeset: 509ca633 Author: Shivangi Gupta Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/509ca63371bcf770f9258d457f080991f2f4c82e Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8255463: java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java failed with ThreadTimeoutException Reviewed-by: jpai Backport-of: a26221299e657b64379d2d56ed3b073f12b227d1 ------------- PR: https://git.openjdk.org/jdk/pull/28888 From jvernee at openjdk.org Fri Dec 19 17:40:15 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 19 Dec 2025 17:40:15 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith wrote: > MemorySegments allocated from shared Arena from > java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. > > The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . > > The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | > | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | > | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | > | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | > | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | > | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | > | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | > | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | > > After: > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | > | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | > | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | > | 8 | 58.22 | 31.60 | 36.87 | 31.72 | 47.09 |... I have started looking at this patch, but it's taking a while, and I've run out of time before the holidays. I will pick this back up next year. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3675949673 From serb at openjdk.org Wed Dec 24 02:57:38 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 24 Dec 2025 02:57:38 GMT Subject: RFR: 8374320: Update copyright year to 2025 for java.net.http in files where it was missed Message-ID: The copyright year in "java.net.http" files updated in 2025 has been bumped to 2025. All files are updated which touched the src/java.net.http and related files. The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: ` git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` ------------- Commit messages: - 8374320: Update copyright year to 2025 for java.net.http in files where it was missed Changes: https://git.openjdk.org/jdk/pull/28973/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28973&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374320 Stats: 191 lines in 191 files changed: 0 ins; 0 del; 191 mod Patch: https://git.openjdk.org/jdk/pull/28973.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28973/head:pull/28973 PR: https://git.openjdk.org/jdk/pull/28973 From alanb at openjdk.org Wed Dec 24 06:58:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 24 Dec 2025 06:58:51 GMT Subject: RFR: 8374320: Update copyright year to 2025 for java.net.http in files where it was missed In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 02:05:28 GMT, Sergey Bylokhov wrote: > The copyright year in "java.net.http" files updated in 2025 has been bumped to 2025. All files are updated which touched the src/java.net.http and related files. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > ` > git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` I checked the http3 branch in the sandbox and several of these files had their last change in 2024, not 2025. When JEP 517 integrated then it might appear that they were created in 2025 even though they have exited in the http3 branch for longer than that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28973#issuecomment-3688873806 From serb at openjdk.org Wed Dec 24 07:03:31 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 24 Dec 2025 07:03:31 GMT Subject: RFR: 8374320: Update copyright year to 2025 for java.net.http in files where it was missed In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 06:55:36 GMT, Alan Bateman wrote: >I checked the http3 branch in the sandbox and several of these files had their last change in 2024, not 2025. When JEP 517 integrated then it might appear that they were created in 2025 even though they have exited in the http3 branch for longer than that. correct, they appeared in jdk/master in 2025 as new files as part of the JEP integration. Not sure whether they should be excluded or not, since they were touched this year in some way. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28973#issuecomment-3688881325 From serb at openjdk.org Wed Dec 24 07:51:02 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 24 Dec 2025 07:51:02 GMT Subject: RFR: 8374327: Update copyright year to 2025 for java.base in files where it was missed Message-ID: This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates. The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` ------------- Commit messages: - 8374327: Update copyright year to 2025 for java.base in files where it was missed Changes: https://git.openjdk.org/jdk/pull/28980/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28980&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374327 Stats: 80 lines in 80 files changed: 0 ins; 0 del; 80 mod Patch: https://git.openjdk.org/jdk/pull/28980.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28980/head:pull/28980 PR: https://git.openjdk.org/jdk/pull/28980 From maxim.kartashev at jetbrains.com Thu Dec 25 07:04:31 2025 From: maxim.kartashev at jetbrains.com (Maxim Kartashev) Date: Thu, 25 Dec 2025 11:04:31 +0400 Subject: RFO: open RandomAccessFile with FILE_SHARE_DELETE on Windows Message-ID: Hi All, Currently, the following snippet will not succeed on Windows try (RandomAccessFile ignored = new RandomAccessFile(f, "r")) { f.delete(); } because RandomAccessFile is opened without the FILE_SHARE_DELETE option for the CreateFileW() call. I wonder if this is intentional and what, if anything, would break if this decision is reversed and FILE_SHARE_DELETE is supplied? I suspect applications rely on the existing semantics but can't give concrete examples myself. Appreciate your input. Maxim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaikiran.pai at oracle.com Thu Dec 25 07:17:46 2025 From: jaikiran.pai at oracle.com (Jaikiran Pai) Date: Thu, 25 Dec 2025 12:47:46 +0530 Subject: RFO: open RandomAccessFile with FILE_SHARE_DELETE on Windows In-Reply-To: References: Message-ID: <8a91728d-1c0e-48b3-a7d0-71f8e3de7f6f@oracle.com> Hello Maxim, Some years back, there were some experiments that were done for the usage of FILE_SHARE_DELETE on Windows, for https://bugs.openjdk.org/browse/JDK-8224794. The related mailing list thread here https://mail.openjdk.org/pipermail/core-libs-dev/2021-November/083809.html has additional details why it was decided not to use that option (even though that mail talks about ZipFile/JarFile, the underlying code uses RandomAccessFile). -Jaikiran On 25/12/25 12:34 pm, Maxim Kartashev wrote: > Hi All, > > Currently, the following snippet will not succeed on Windows > try (RandomAccessFile ignored = new RandomAccessFile(f, "r")) { > ? ? f.delete(); > } > because RandomAccessFile is opened without the?FILE_SHARE_DELETE > option for the?CreateFileW() call. > I wonder if this is intentional and what, if anything, would break if > this decision is reversed and?FILE_SHARE_DELETE is supplied? I suspect > applications rely on the existing semantics but can't give concrete > examples myself. > > Appreciate your input. > > Maxim. From alan.bateman at oracle.com Thu Dec 25 07:22:08 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Thu, 25 Dec 2025 07:22:08 +0000 Subject: RFO: open RandomAccessFile with FILE_SHARE_DELETE on Windows In-Reply-To: References: Message-ID: <648cf0a5-f269-4fab-a923-07aaf8642712@oracle.com> On 25/12/2025 07:04, Maxim Kartashev wrote: > Hi All, > > Currently, the following snippet will not succeed on Windows > try (RandomAccessFile ignored = new RandomAccessFile(f, "r")) { > ? ? f.delete(); > } > because RandomAccessFile is opened without the?FILE_SHARE_DELETE > option for the?CreateFileW() call. > I wonder if this is intentional and what, if anything, would break if > this decision is reversed and?FILE_SHARE_DELETE is supplied? I suspect > applications rely on the existing semantics but can't give concrete > examples myself. > Files opened with APIs introduced since JDK 7 use FILE_SHARE_DELETE by default. The issue with the legacy APIs dates from early JDK releases and has been looked at many times over the years. Many of these cases where it comes up involved JarFile where tools are deleting JAR files that are in use. Some time ago we had a prototype re-write of java.io on top of java.nio.file and has to specifically deal with the issue. So yes, long standing issues that dates from early JDK releases. Changing the behavior would be a significant change and we have never been brave enough to do it. Also FILE_SHARE_DELETE is not the full story, there are a bunch of scenarios where Windows doesn't provide the same semantics as Unix, e.g. re-creating files, deleting files that have file mappings, sub-processes, ... -Alan From serb at openjdk.org Fri Dec 26 03:18:25 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 26 Dec 2025 03:18:25 GMT Subject: RFR: 8374365: Update copyright year to 2025 for test/jdk in files where it was missed Message-ID: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs. **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed. The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` ------------- Commit messages: - 8374365: Update copyright year to 2025 for test/jdk in files where it was missed Changes: https://git.openjdk.org/jdk/pull/28997/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28997&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374365 Stats: 76 lines in 76 files changed: 0 ins; 0 del; 76 mod Patch: https://git.openjdk.org/jdk/pull/28997.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28997/head:pull/28997 PR: https://git.openjdk.org/jdk/pull/28997 From sacharya at openjdk.org Fri Dec 26 05:34:21 2025 From: sacharya at openjdk.org (Shruthi Acharya) Date: Fri, 26 Dec 2025 05:34:21 GMT Subject: RFR: 8374368: Invalid java.nio.channels.spi.SelectorProvider value results in ClassNotFoundException instead of falling back to default provider Message-ID: Fall back to the default SelectorProvider by logging an error when an invalid provider is specified via the java.nio.channels.spi.SelectorProvider system property. The bug report for the same: https://bugs.openjdk.org/browse/JDK-8374368 ------------- Commit messages: - 8374368: Invalid java.nio.channels.spi.SelectorProvider value results in ClassNotFoundException instead of falling back to default provider Changes: https://git.openjdk.org/jdk/pull/28998/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28998&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374368 Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/28998.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28998/head:pull/28998 PR: https://git.openjdk.org/jdk/pull/28998 From sacharya at openjdk.org Fri Dec 26 05:46:57 2025 From: sacharya at openjdk.org (Shruthi Acharya) Date: Fri, 26 Dec 2025 05:46:57 GMT Subject: RFR: 8374368: Invalid java.nio.channels.spi.SelectorProvider value results in ClassNotFoundException instead of falling back to default provider In-Reply-To: References: Message-ID: On Fri, 26 Dec 2025 05:27:53 GMT, Shruthi Acharya wrote: > Fall back to the default SelectorProvider by logging an error when an invalid provider is specified via the java.nio.channels.spi.SelectorProvider system property. > The bug report for the same: https://bugs.openjdk.org/browse/JDK-8374368 Validated the fix with the personal build SelectorTypeCheck.java import java.nio.channels.Selector; public class SelectorTypeCheck { public static void main(String[] args) throws Exception { try (Selector selector = Selector.open()) { System.out.println("Selector provider: " + selector.provider()); System.out.println("Selector implementation class: " + selector.getClass().getName()); } } } jdk/bin/java SelectorTypeCheck Selector provider: sun.nio.ch.EPollSelectorProvider at 68968cd4 Selector implementation class: sun.nio.ch.EPollSelectorImpl jdk/bin/java -Djava.nio.channels.spi.SelectorProvider=abc SelectorTypeCheck Invalid SelectorProvider specified: abc. Falling back to default provider. Selector provider: sun.nio.ch.EPollSelectorProvider at 7f1338e3 Selector implementation class: sun.nio.ch.EPollSelectorImpl jdk/bin/java -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider SelectorTypeCheck Selector provider: sun.nio.ch.PollSelectorProvider at b3462c23 Selector implementation class: sun.nio.ch.PollSelectorImpl Also I have triggred java_nio, java_io and jdk_net tests. All of them are passing 20:55:05 TEST TARGETS SUMMARY 20:55:05 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 20:55:05 PASSED test targets: 20:55:05 jdk_io_0 - Test results: passed: 395 20:55:05 jdk_io_1 - Test results: passed: 395 20:55:05 jdk_nio_0 - Test results: passed: 445 20:55:05 jdk_nio_1 - Test results: passed: 445 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28998#issuecomment-3692179969 From alanb at openjdk.org Fri Dec 26 06:32:00 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 26 Dec 2025 06:32:00 GMT Subject: RFR: 8374368: Invalid java.nio.channels.spi.SelectorProvider value results in ClassNotFoundException instead of falling back to default provider In-Reply-To: References: Message-ID: On Fri, 26 Dec 2025 05:27:53 GMT, Shruthi Acharya wrote: > Fall back to the default SelectorProvider by logging an error when an invalid provider is specified via the java.nio.channels.spi.SelectorProvider system property. > The bug report for the same: https://bugs.openjdk.org/browse/JDK-8374368 This is not a bug, the lookup is specified to fall if there is a configuration error. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28998#issuecomment-3692247386 From phh at openjdk.org Fri Dec 26 22:58:54 2025 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 26 Dec 2025 22:58:54 GMT Subject: RFR: 8374365: Update copyright year to 2025 for test/jdk in files where it was missed In-Reply-To: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> References: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> Message-ID: On Fri, 26 Dec 2025 02:35:31 GMT, Sergey Bylokhov wrote: > The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs. > > **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28997#pullrequestreview-3613936569 From serb at openjdk.org Sat Dec 27 07:07:04 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 27 Dec 2025 07:07:04 GMT Subject: Integrated: 8374365: Update copyright year to 2025 for test/jdk in files where it was missed In-Reply-To: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> References: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> Message-ID: On Fri, 26 Dec 2025 02:35:31 GMT, Sergey Bylokhov wrote: > The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs. > > **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` This pull request has now been integrated. Changeset: 9512a43e Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/9512a43e82652be7294338c11cc9ffb0f0324b92 Stats: 76 lines in 76 files changed: 0 ins; 0 del; 76 mod 8374365: Update copyright year to 2025 for test/jdk in files where it was missed Reviewed-by: phh ------------- PR: https://git.openjdk.org/jdk/pull/28997 From serb at openjdk.org Sat Dec 27 07:30:59 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 27 Dec 2025 07:30:59 GMT Subject: RFR: 8374365: Update copyright year to 2025 for test/jdk in files where it was missed In-Reply-To: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> References: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> Message-ID: On Fri, 26 Dec 2025 02:35:31 GMT, Sergey Bylokhov wrote: > The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs. > > **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` I will update this PR to include all changes in src/hotspot and test/hotspot only. The rest will be done separately. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28997#issuecomment-3693789137 From lmesnik at openjdk.org Sun Dec 28 03:01:01 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sun, 28 Dec 2025 03:01:01 GMT Subject: RFR: 8374368: Invalid java.nio.channels.spi.SelectorProvider value results in ClassNotFoundException instead of falling back to default provider In-Reply-To: References: Message-ID: On Fri, 26 Dec 2025 05:27:53 GMT, Shruthi Acharya wrote: > Fall back to the default SelectorProvider by logging an error when an invalid provider is specified via the java.nio.channels.spi.SelectorProvider system property. > The bug report for the same: https://bugs.openjdk.org/browse/JDK-8374368 Changes requested by lmesnik (Reviewer). src/java.base/share/classes/java/nio/channels/spi/SelectorProvider.java line 98: > 96: Class clazz = Class.forName(cn, true, ClassLoader.getSystemClassLoader()); > 97: return (SelectorProvider) clazz.getConstructor().newInstance(); > 98: } catch (Throwable t) { This fix should have a regression test, based on the provided reproducer. If it can't be implemented, then bug should have 'noreg-' label. ------------- PR Review: https://git.openjdk.org/jdk/pull/28998#pullrequestreview-3614498838 PR Review Comment: https://git.openjdk.org/jdk/pull/28998#discussion_r2649442749 From serb at openjdk.org Tue Dec 30 23:09:05 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 30 Dec 2025 23:09:05 GMT Subject: RFR: 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov wrote: > This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` Looking for volunteers to review this patch. It cannot be integrated in 2026. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3700774950 From liach at openjdk.org Wed Dec 31 00:20:54 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 31 Dec 2025 00:20:54 GMT Subject: RFR: 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov wrote: > This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` Unfortunately many of our reviewers are on their winter break. You might consider proposing such prs in early December in the future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3700907244 From serb at openjdk.org Wed Dec 31 00:52:02 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 31 Dec 2025 00:52:02 GMT Subject: RFR: 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 In-Reply-To: References: Message-ID: On Wed, 31 Dec 2025 00:18:14 GMT, Chen Liang wrote: > Unfortunately many of our reviewers are on their winter break. You might consider proposing such prs in early December in the future. Yeah, usually [magicus](https://github.com/openjdk/jdk/pull/22642) updates those files, but for some reason this year updates were missing, so I decided to pick them up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3700942964 From jpai at openjdk.org Wed Dec 31 01:32:52 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 31 Dec 2025 01:32:52 GMT Subject: RFR: 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov wrote: > This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` Hello Sergey, > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done What is that command expected to return as output? I ran that on top of this PR and I don't see any output. It completes normally without any error. I'm on macos. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3701057533 From jpai at openjdk.org Wed Dec 31 01:49:51 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 31 Dec 2025 01:49:51 GMT Subject: RFR: 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 In-Reply-To: References: Message-ID: <1W3A16ibXOMrTbXRCkTywPfLx2l0Lm9Pxe2_aJft9Zc=.95756c42-e9a3-498e-b99c-7111af17b18b@github.com> On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov wrote: > This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` Looking at some other similar PRs that were open, I even tried the following command that was noted in one of them: git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done Even this one doesn't generate any output for me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3701127162 From serb at openjdk.org Wed Dec 31 02:16:01 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 31 Dec 2025 02:16:01 GMT Subject: RFR: 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov wrote: > This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` The first command checks the files changed in the last commit of the PR and verifies whether each file has any commit history since January 1, 2025. If not, it prints "NOT IN 2025". `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` The disadvantage of the first command is that it depends on a specific commit. The second command avoids this by comparing the current PR against master and using that diff as the list of changed files. To test the second command, modify and commit a file in the PR branch that has not been modified in 2025. The script will flag it as "NOT IN 2025", because this PR is expected to change only files that already have commits on master in 2025. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3701263133 From jpai at openjdk.org Wed Dec 31 04:41:57 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 31 Dec 2025 04:41:57 GMT Subject: RFR: 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov wrote: > This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` Marked as reviewed by jpai (Reviewer). Thank you for that detail, I used a slightly different way to verify that the files changed in this PR were indeed updated in 2025. The changes look good to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/28980#pullrequestreview-3620237303 PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3701430051 From alanb at openjdk.org Wed Dec 31 07:48:33 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 31 Dec 2025 07:48:33 GMT Subject: RFR: 8374382: (aio) AsynchronousFileChannel writes wrong content using heap ByteBuffer when position != 0 Message-ID: On Windows only, if AsynchronousFileChannel is used with a heap ByteBuffer with a non-0 buffer position then the AsynchronousFileChannel read/write methods don't work correctly when the buffer is "substituted" for the underlying I/O operation. This is a regression in JDK 26 after JDK-8357847, missed as we didn't have tests that exercise this scenario. ------------- Commit messages: - Remove unused import - Fix test summary - Initial commit Changes: https://git.openjdk.org/jdk/pull/29010/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29010&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374382 Stats: 191 lines in 2 files changed: 189 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29010.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29010/head:pull/29010 PR: https://git.openjdk.org/jdk/pull/29010 From serb at openjdk.org Wed Dec 31 09:17:07 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 31 Dec 2025 09:17:07 GMT Subject: Integrated: 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov wrote: > This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` This pull request has now been integrated. Changeset: 36d2c277 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/36d2c277c47767ba22208e2e49c46001642bd4f5 Stats: 80 lines in 80 files changed: 0 ins; 0 del; 80 mod 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/28980 From alanb at openjdk.org Wed Dec 31 09:25:13 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 31 Dec 2025 09:25:13 GMT Subject: RFR: 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 In-Reply-To: References: Message-ID: <_66pqVpeNUXYUPpnX4X56yihxoBpaIll4RdsJAUCSGo=.6b4217ed-c69a-4738-a719-3860c0ec212e@github.com> On Wed, 31 Dec 2025 04:38:43 GMT, Jaikiran Pai wrote: > I used a slightly different way to verify that the files changed in this PR were indeed updated in 2025. There's a handful of files that were last updated in Dec 2024 via PRs that were in progress at the time. The "/integrate" happened in early Jan 2025 so it looks like the files were updated in 2025. Probably happens every year. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3701814018 From jpai at openjdk.org Wed Dec 31 15:34:00 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 31 Dec 2025 15:34:00 GMT Subject: RFR: 8374382: (aio) AsynchronousFileChannel writes wrong content using heap ByteBuffer when position != 0 In-Reply-To: References: Message-ID: On Wed, 31 Dec 2025 07:08:40 GMT, Alan Bateman wrote: > On Windows only, if AsynchronousFileChannel is used with a heap ByteBuffer with a non-0 buffer position then the AsynchronousFileChannel read/write methods don't work correctly when the buffer is "substituted" for the underlying I/O operation. > > This is a regression in JDK 26 after JDK-8357847, missed as we didn't have tests that exercise this scenario. This looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29010#pullrequestreview-3621058146 From aivanov at openjdk.org Wed Dec 31 15:49:00 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 31 Dec 2025 15:49:00 GMT Subject: RFR: 8374320: Update copyright year to 2025 for java.net.http in files where it was missed In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 07:00:11 GMT, Sergey Bylokhov wrote: > > I checked the http3 branch in the sandbox and several of these files had their last change in 2024, not 2025. When JEP 517 integrated then it might appear that they were created in 2025 even though they have exited in the http3 branch for longer than that. > > correct, they appeared in jdk/master in 2025 as new files as part of the JEP integration. Not sure whether they should be excluded or not, since they were touched this year in some way. Since the development branch is gone and the commits are squashed, these are the new files from the `master` branch perspective. I think the copyright year can still be bumped up in them, preserving the original year. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28973#issuecomment-3702417860