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