From lancea at openjdk.java.net Sun Jan 2 22:00:11 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Sun, 2 Jan 2022 22:00:11 GMT Subject: RFR: 8278268 - (ch) InputStream returned by Channels.newInputStream should have fast path for FileChannel targets [v8] In-Reply-To: References: Message-ID: On Wed, 22 Dec 2021 18:34:09 GMT, Lance Andersen wrote: >>> @LanceAndersen Are you sure that the sporadic timeout comes from the changes made by _this_ PR? IIUC then the sporadic timeouts are found _in the master branch_, so reverting the changes from _this_ PR do not bring a benefit. It would be better to separate out _all_ (_even existing_) 2GB tests instead. >> >> As I mentioned in my earlier comment, we need to make the changes as outlined. We do have some Windows boxes which are older but we cannot afford to have sporadic test failures due to the disruption it causes. And yes, these failures are occurring with the changes made and do not occur if I back them out. >> >> So please follow the recommendations, I can then re-test the PR to validate we are clean (or as clean as we ca)n for sporadic failures. > >> @LanceAndersen I assumed the second test will exist only for the time until we fixed the Windows problems, so I did not invest time to reduce duplication so far. So you really want to keep the separated tests forever and want me to reduce duplication? > > I would not make any such assumptions especially for tests that create large files. So yes please address the duplication. It is not a huge amount of work to create a base class that the tests extend (you will see examples elsewhere within the various test directories). > @LanceAndersen I'm done with the requested changes. For "the remaining tests" I kept the separation into TransferTo (existing tests) and TransferTo2 (new tests of this PR) -- or do you want me to consolidate TransferTo2 into TransferTo now that Alan identified the source of trouble being the Unix Domain Sockets? I haven't gone through this in detail, but we want to merge The remaining TransferTo2 tests into TransferTo. For the large File tests, any duplicate code can also be included in the base class. I will look at this more when I am back from the holiday break ------------- PR: https://git.openjdk.java.net/jdk/pull/6711 From bpb at openjdk.java.net Mon Jan 3 19:42:37 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 3 Jan 2022 19:42:37 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v9] In-Reply-To: <8vwe-oQ5ilpMKuep4zSHycQisXMIFImfyE4hRVFvCS8=.c0fbf5b2-ccf3-46f4-bce1-6bb5fb3403e3@github.com> References: <8vwe-oQ5ilpMKuep4zSHycQisXMIFImfyE4hRVFvCS8=.c0fbf5b2-ccf3-46f4-bce1-6bb5fb3403e3@github.com> Message-ID: On Sat, 31 Jul 2021 00:59:19 GMT, Brian Burkhalter wrote: >> Please review this proposed change to add a method `java.nio.file.Path.getExtension()`. This was initially discussed in the thread http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004716.html. This method would return the filename extension of the file name of the `Path`. The extension is defined to be the portion of the file name after the last dot `(?.?)`. >> >> The definitions of file extension for about fifteen platforms and languages were surveyed to try to find a reasonable compromise for the definition of extension. The most common definition was the last segment of the name including and after the last dot. The second definition omitted the last dot from the extension. Java-related platforms all exclude the last dot. (One divergent definition in the internal Java NIO method `AbstractFileTypeDetector.getExtension(String)` defines the extension as the part after the *first* dot.) >> >> All examined cases define the extension to be an empty string if it cannot be determined. None of these cases used `null` to represent an indeterminate extension. >> >> Little in the way of specifying behavior for special cases (consisting mainly of file names with one or more leading dots) was found. Most definitions concern themselves only with the last dot and what comes after it and ignore leading dots altogether. A few definitions ignore a leading dot at the zeroth character. The current proposal ignores a dot at character zero. >> >> The behavior of the proposed method for some example cases is as: >> >> >> . -> >> .. -> >> .a.b -> b >> ...... -> >> .....a -> a >> ....a.b -> b >> ..foo -> foo >> test.rb -> rb >> a/b/d/test.rb -> rb >> .a/b/d/test.rb -> rb >> foo. -> >> test -> >> .profile -> >> .profile.sh -> sh >> ..foo -> foo >> .....foo -> foo >> .vimrc -> >> test. -> >> test.. -> >> test... -> >> foo.tar.gz -> gz >> foo.bar. -> >> image.jpg -> jpg >> music.mp3 -> mp3 >> video.mp4 -> mp4 >> document.txt -> txt >> foo.tar.gz -> gz >> foo.bar. -> > > Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - 8057113: Optimistically update @since tag to 18 > - Merge > - 8057113: Change first sentence; change param name > - 8057113: Change Path.getExtension() to accept a default return value in case the extension is indeterminate > - 8057113: Tweak spec again, and @implSpec code > - 8057113: Add @since tag > - 8057113: Tweak first sentence of spec > - 8057113: Handle getFileName() == null; revise spec > - 8057113: Changes pursuant to PR conversation > - 8057113: (fs) Path should have a method to obtain the filename extension continue ------------- PR: https://git.openjdk.java.net/jdk/pull/2319 From bpb at openjdk.java.net Mon Jan 3 19:43:12 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 3 Jan 2022 19:43:12 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() [v4] In-Reply-To: <1AR4tgaz1JdXutbQMh7FNoG0SHk1nHznl5H9n2Jzk3U=.545d612d-8eee-4290-8571-e5a9e18fe680@github.com> References: <1AR4tgaz1JdXutbQMh7FNoG0SHk1nHznl5H9n2Jzk3U=.545d612d-8eee-4290-8571-e5a9e18fe680@github.com> Message-ID: On Mon, 25 Oct 2021 16:57:41 GMT, Brian Burkhalter wrote: >> Please consider this patch which would improve the performance of >> `FileChannel.transferTo()` on macOS and Windows. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8274112: Make transferTo0() static; remove check for null FileDescriptor continue ------------- PR: https://git.openjdk.java.net/jdk/pull/5623 From alanb at openjdk.java.net Tue Jan 4 09:56:26 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 4 Jan 2022 09:56:26 GMT Subject: RFR: 8279339: (ch) Input/Output streams returned by Channels factory methods don't support concurrent read/write ops Message-ID: If someone has a SocketChannel sc then one way to obtain input/output streams is via the Socket adaptor, i.e. sc.socket().getXXXStream. Another way is with Channels.newXXXStream(sc) factory methods. A long standing limitation is that the input/output streams returned by the Channels.newXXXStream methods must synchronize on the channel's blockingLock() to prevent the channel from being configured non-blocking. There is one "blocking lock" per SelectableChannel so problematic when the SelectableChannel is also a ByteChannel as it prevents a thread from writing while another is blocked in read (and vice versa). The change proposed here is to have Channels.newXXXStream special case the SocketChannel implementation so that it returns the same input/output stream as the socket adaptors. These socket streams make use of non-exposed blocking read/write methods that coordinate with configureBlocking so don't need to synchronize on the blockingLock. The core part of the change is that the inner classes that were in SocketAdaptor are moved to be top-level SocketInputStream and SocketOutputStream classes. There is some minor cleanup to ChannelInputStream and ChannelOutputStream in this patch. Once pattern matching for switch is permanent, and Markus Karg is done with transferTo, then we can see if we want to refactor that method and/or introduce a sub-class for FileChannel. I've added a new test to exercise the the read/write methods, with focus on async close and interrupt. It includes tests that do concurrent read + write operations. ------------- Commit messages: - Cleanup - Merge - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/6953/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6953&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279339 Stats: 911 lines in 8 files changed: 755 ins; 116 del; 40 mod Patch: https://git.openjdk.java.net/jdk/pull/6953.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6953/head:pull/6953 PR: https://git.openjdk.java.net/jdk/pull/6953 From mcimadamore at openjdk.java.net Wed Jan 5 17:07:34 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 5 Jan 2022 17:07:34 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution Message-ID: This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: Benchmark Mode Cnt Score Error Units LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: Benchmark Mode Cnt Score Error Units LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. ------------- Commit messages: - Initial push Changes: https://git.openjdk.java.net/jdk18/pull/82/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=82&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279527 Stats: 108 lines in 8 files changed: 41 ins; 49 del; 18 mod Patch: https://git.openjdk.java.net/jdk18/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/82/head:pull/82 PR: https://git.openjdk.java.net/jdk18/pull/82 From mcimadamore at openjdk.java.net Wed Jan 5 17:07:34 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 5 Jan 2022 17:07:34 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 16:59:30 GMT, Maurizio Cimadamore wrote: > This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op > > > That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). > > In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op > > > Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 367: > 365: > 366: void checkValidState() { > 367: scope.checkValidStateSlow(); Not to be confused with `ResourceScope::checkValidState` - this method is only really used by other non-performance critical code around `AbstractMemorySegmentImpl`. ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From lancea at openjdk.java.net Wed Jan 5 17:12:13 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 5 Jan 2022 17:12:13 GMT Subject: RFR: 8279339: (ch) Input/Output streams returned by Channels factory methods don't support concurrent read/write ops In-Reply-To: References: Message-ID: On Tue, 4 Jan 2022 09:13:34 GMT, Alan Bateman wrote: > If someone has a SocketChannel sc then one way to obtain input/output streams is via the Socket adaptor, i.e. sc.socket().getXXXStream. Another way is with Channels.newXXXStream(sc) factory methods. A long standing limitation is that the input/output streams returned by the Channels.newXXXStream methods must synchronize on the channel's blockingLock() to prevent the channel from being configured non-blocking. There is one "blocking lock" per SelectableChannel so problematic when the SelectableChannel is also a ByteChannel as it prevents a thread from writing while another is blocked in read (and vice versa). > > The change proposed here is to have Channels.newXXXStream special case the SocketChannel implementation so that it returns the same input/output stream as the socket adaptors. These socket streams make use of non-exposed blocking read/write methods that coordinate with configureBlocking so don't need to synchronize on the blockingLock. The core part of the change is that the inner classes that were in SocketAdaptor are moved to be top-level SocketInputStream and SocketOutputStream classes. > > There is some minor cleanup to ChannelInputStream and ChannelOutputStream in this patch. Once pattern matching for switch is permanent, and Markus Karg is done with transferTo, then we can see if we want to refactor that method and/or introduce a sub-class for FileChannel. > > I've added a new test to exercise the the read/write methods, with focus on async close and interrupt. It includes tests that do concurrent read + write operations. This looks good. Thank you for addressing. I typically use assertThrows vs expectThrows for consistency with the other assertXXX ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6953 From psandoz at openjdk.java.net Wed Jan 5 17:27:11 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 5 Jan 2022 17:27:11 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 16:59:30 GMT, Maurizio Cimadamore wrote: > This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op > > > That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). > > In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op > > > Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ResourceScopeImpl.java line 190: > 188: @ForceInline > 189: public final void checkValidState() { > 190: if (owner != null && owner != Thread.currentThread()) { For consistency we could change code `checkValidStateSlow` to refer directly to `owner`. It would be satisfying, but I don't know if it's possible, to compose `checkValidStateSlow` from `checkValidState` e.g. public final checkValidStateSlow() { checkValidState(); if (!isAlive() { ... } } ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From mcimadamore at openjdk.java.net Wed Jan 5 18:01:10 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 5 Jan 2022 18:01:10 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 17:23:40 GMT, Paul Sandoz wrote: >> This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: >> >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op >> LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op >> LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op >> LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op >> >> >> That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). >> >> In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: >> >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op >> LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op >> >> >> Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. > > src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ResourceScopeImpl.java line 190: > >> 188: @ForceInline >> 189: public final void checkValidState() { >> 190: if (owner != null && owner != Thread.currentThread()) { > > For consistency we could change code `checkValidStateSlow` to refer directly to `owner`. > > It would be satisfying, but I don't know if it's possible, to compose `checkValidStateSlow` from `checkValidState` e.g. > > public final checkValidStateSlow() { > checkValidState(); > if (!isAlive() { ... } > } I'll change use of `owner`. It's not really possible to write checkValidStateSlow in terms of checkValidState, because the latter does a plain read of the state, whereas the former does a volatile read. Reusing one from the other would result in two reads (a plain and a volatile). ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From mcimadamore at openjdk.java.net Wed Jan 5 18:08:01 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 5 Jan 2022 18:08:01 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution [v2] In-Reply-To: References: Message-ID: <7ouKP99gKljCPTw091C9WUnwXiENN9nJCvIF09fPU9w=.1277b87b-242a-46c1-8f30-1c18671171d1@github.com> > This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op > > > That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). > > In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op > > > Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Use owner field instead of accessor in checkValidStateSlow ------------- Changes: - all: https://git.openjdk.java.net/jdk18/pull/82/files - new: https://git.openjdk.java.net/jdk18/pull/82/files/c6082953..04a1e9f2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=82&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=82&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk18/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/82/head:pull/82 PR: https://git.openjdk.java.net/jdk18/pull/82 From alanb at openjdk.java.net Wed Jan 5 18:13:25 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 5 Jan 2022 18:13:25 GMT Subject: [jdk18] RFR: 8279529: ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 17:22:54 GMT, Daniel D. Daugherty wrote: > A couple of trivial ProblemListings: > > JDK-8279529 ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64 > JDK-8279532 ProblemList sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java This looks okay although I think we're working around a macOS or configuration issue rather than a JDK or test issue. ------------- PR: https://git.openjdk.java.net/jdk18/pull/83 From bpb at openjdk.java.net Wed Jan 5 18:15:15 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 5 Jan 2022 18:15:15 GMT Subject: RFR: 8279339: (ch) Input/Output streams returned by Channels factory methods don't support concurrent read/write ops In-Reply-To: References: Message-ID: On Tue, 4 Jan 2022 09:13:34 GMT, Alan Bateman wrote: > If someone has a SocketChannel sc then one way to obtain input/output streams is via the Socket adaptor, i.e. sc.socket().getXXXStream. Another way is with Channels.newXXXStream(sc) factory methods. A long standing limitation is that the input/output streams returned by the Channels.newXXXStream methods must synchronize on the channel's blockingLock() to prevent the channel from being configured non-blocking. There is one "blocking lock" per SelectableChannel so problematic when the SelectableChannel is also a ByteChannel as it prevents a thread from writing while another is blocked in read (and vice versa). > > The change proposed here is to have Channels.newXXXStream special case the SocketChannel implementation so that it returns the same input/output stream as the socket adaptors. These socket streams make use of non-exposed blocking read/write methods that coordinate with configureBlocking so don't need to synchronize on the blockingLock. The core part of the change is that the inner classes that were in SocketAdaptor are moved to be top-level SocketInputStream and SocketOutputStream classes. > > There is some minor cleanup to ChannelInputStream and ChannelOutputStream in this patch. Once pattern matching for switch is permanent, and Markus Karg is done with transferTo, then we can see if we want to refactor that method and/or introduce a sub-class for FileChannel. > > I've added a new test to exercise the the read/write methods, with focus on async close and interrupt. It includes tests that do concurrent read + write operations. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6953 From alanb at openjdk.java.net Wed Jan 5 18:21:11 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 5 Jan 2022 18:21:11 GMT Subject: RFR: 8279339: (ch) Input/Output streams returned by Channels factory methods don't support concurrent read/write ops In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 17:09:09 GMT, Lance Andersen wrote: > I typically use assertThrows vs expectThrows for consistency with the other assertXXX I've got into the habit of using expectThrows because tests will often need to check the exception cause (assertThrows is void). I don't mind changing it as either will work for this test. ------------- PR: https://git.openjdk.java.net/jdk/pull/6953 From psandoz at openjdk.java.net Wed Jan 5 18:28:22 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 5 Jan 2022 18:28:22 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution [v2] In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 17:57:44 GMT, Maurizio Cimadamore wrote: >> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ResourceScopeImpl.java line 190: >> >>> 188: @ForceInline >>> 189: public final void checkValidState() { >>> 190: if (owner != null && owner != Thread.currentThread()) { >> >> For consistency we could change code `checkValidStateSlow` to refer directly to `owner`. >> >> It would be satisfying, but I don't know if it's possible, to compose `checkValidStateSlow` from `checkValidState` e.g. >> >> public final checkValidStateSlow() { >> checkValidState(); >> if (!isAlive() { ... } >> } > > I'll change use of `owner`. It's not really possible to write checkValidStateSlow in terms of checkValidState, because the latter does a plain read of the state, whereas the former does a volatile read. Reusing one from the other would result in two reads (a plain and a volatile). Ok. My thought was that since this is slow two reads do not matter, but i did not reason fully about the concurrent implications (if the fast alive check returns false, the slow alive check can still return true so that seems good, if the fast check returns true i was presume the slow alive check would also be true, given the way state changes monotonically?) ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From dcubed at openjdk.java.net Wed Jan 5 18:37:18 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 5 Jan 2022 18:37:18 GMT Subject: [jdk18] RFR: 8279529: ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 17:39:16 GMT, Jamil Nimeh wrote: >> A couple of trivial ProblemListings: >> >> JDK-8279529 ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64 >> JDK-8279532 ProblemList sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java > > Looks good to me. @jnimeh - Thanks for the review. @AlanBateman - I presume you are talking about java/nio/channels/DatagramChannel/ManySourcesAndTargets.java. It could be a macosx-aarch64 config issue and if we can get to the bottom of that issue, then we can re-enable the test. For now, with the JDK18 clock ticking down, I'd like to reduce the noise in the CI. Did you plan on adding your reviewer approval here? ------------- PR: https://git.openjdk.java.net/jdk18/pull/83 From psandoz at openjdk.java.net Wed Jan 5 18:49:11 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 5 Jan 2022 18:49:11 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution [v2] In-Reply-To: <7ouKP99gKljCPTw091C9WUnwXiENN9nJCvIF09fPU9w=.1277b87b-242a-46c1-8f30-1c18671171d1@github.com> References: <7ouKP99gKljCPTw091C9WUnwXiENN9nJCvIF09fPU9w=.1277b87b-242a-46c1-8f30-1c18671171d1@github.com> Message-ID: On Wed, 5 Jan 2022 18:08:01 GMT, Maurizio Cimadamore wrote: >> This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: >> >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op >> LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op >> LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op >> LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op >> >> >> That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). >> >> In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: >> >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op >> LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op >> >> >> Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Use owner field instead of accessor in checkValidStateSlow Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From mcimadamore at openjdk.java.net Wed Jan 5 18:54:13 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 5 Jan 2022 18:54:13 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution [v2] In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 18:24:39 GMT, Paul Sandoz wrote: >> I'll change use of `owner`. It's not really possible to write checkValidStateSlow in terms of checkValidState, because the latter does a plain read of the state, whereas the former does a volatile read. Reusing one from the other would result in two reads (a plain and a volatile). > > Ok. My thought was that since this is slow two reads do not matter, but i did not reason fully about the concurrent implications (if the fast alive check returns false, the slow alive check can still return true so that seems good, if the fast check returns true i was presume the slow alive check would also be true, given the way state changes monotonically?) If we're ok with a redundant plain read, then I don't think there are issues. You just do two reads, and the latter (the volatile one) is the one that counts. I don't think we can rely much on dependencies between what the plain read and what the volatile read will see. The state is updated in both direction (for shared segments) e.g. we can go from ALIVE to CLOSING then back to ALIVE. Or we could go from ALIVE to CLOSING to CLOSE. That said, I guess my main reservation for writing one routine on top of the other is that we really want checkValidState to be only used in critical hot paths. It has a non-volatile semantics and an exception handling which only really makes sense when combined with ScopedMemoryAccess - for this reason, using it as an internal building primitive didn't seem to me as a great idea. ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From lancea at openjdk.java.net Wed Jan 5 18:58:10 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 5 Jan 2022 18:58:10 GMT Subject: RFR: 8279339: (ch) Input/Output streams returned by Channels factory methods don't support concurrent read/write ops In-Reply-To: References: Message-ID: <5c9eNA3LqKosj-QeVbZlYaD8DIaBfkimWtEQLVmtYUY=.41abc551-16dc-4068-822e-9f70b0714452@github.com> On Wed, 5 Jan 2022 18:18:24 GMT, Alan Bateman wrote: > > I typically use assertThrows vs expectThrows for consistency with the other assertXXX > > I've got into the habit of using expectThrows because tests will often need to check the exception cause (assertThrows is void). I don't mind changing it as either will work for this test. No need to change. All good by me either way! ------------- PR: https://git.openjdk.java.net/jdk/pull/6953 From dcubed at openjdk.java.net Wed Jan 5 19:04:18 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 5 Jan 2022 19:04:18 GMT Subject: [jdk18] Integrated: 8279529: ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64 In-Reply-To: References: Message-ID: <2BPWevmssx0ch_cnM_yKhgVKfrxzdyM7qGggLBquG4A=.a56aedf9-c272-4cee-9e45-f53c51de6288@github.com> On Wed, 5 Jan 2022 17:22:54 GMT, Daniel D. Daugherty wrote: > A couple of trivial ProblemListings: > > JDK-8279529 ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64 > JDK-8279532 ProblemList sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java This pull request has now been integrated. Changeset: 564c8c63 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk18/commit/564c8c6390ee380ab2e2eb73ef22c3184c369f9f Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8279529: ProblemList java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64 8279532: ProblemList sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java Reviewed-by: jnimeh ------------- PR: https://git.openjdk.java.net/jdk18/pull/83 From alanb at openjdk.java.net Wed Jan 5 20:05:53 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 5 Jan 2022 20:05:53 GMT Subject: RFR: 8279339: (ch) Input/Output streams returned by Channels factory methods don't support concurrent read/write ops [v2] In-Reply-To: References: Message-ID: > If someone has a SocketChannel sc then one way to obtain input/output streams is via the Socket adaptor, i.e. sc.socket().getXXXStream. Another way is with Channels.newXXXStream(sc) factory methods. A long standing limitation is that the input/output streams returned by the Channels.newXXXStream methods must synchronize on the channel's blockingLock() to prevent the channel from being configured non-blocking. There is one "blocking lock" per SelectableChannel so problematic when the SelectableChannel is also a ByteChannel as it prevents a thread from writing while another is blocked in read (and vice versa). > > The change proposed here is to have Channels.newXXXStream special case the SocketChannel implementation so that it returns the same input/output stream as the socket adaptors. These socket streams make use of non-exposed blocking read/write methods that coordinate with configureBlocking so don't need to synchronize on the blockingLock. The core part of the change is that the inner classes that were in SocketAdaptor are moved to be top-level SocketInputStream and SocketOutputStream classes. > > There is some minor cleanup to ChannelInputStream and ChannelOutputStream in this patch. Once pattern matching for switch is permanent, and Markus Karg is done with transferTo, then we can see if we want to refactor that method and/or introduce a sub-class for FileChannel. > > I've added a new test to exercise the the read/write methods, with focus on async close and interrupt. It includes tests that do concurrent read + write operations. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Fix typo in comment - Remove redundant case - Merge - Cleanup - Merge - Initial commit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6953/files - new: https://git.openjdk.java.net/jdk/pull/6953/files/36d8adb3..5448afd9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6953&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6953&range=00-01 Stats: 578 lines in 33 files changed: 444 ins; 80 del; 54 mod Patch: https://git.openjdk.java.net/jdk/pull/6953.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6953/head:pull/6953 PR: https://git.openjdk.java.net/jdk/pull/6953 From bpb at openjdk.java.net Wed Jan 5 20:10:11 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 5 Jan 2022 20:10:11 GMT Subject: RFR: 8279339: (ch) Input/Output streams returned by Channels factory methods don't support concurrent read/write ops [v2] In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 20:05:53 GMT, Alan Bateman wrote: >> If someone has a SocketChannel sc then one way to obtain input/output streams is via the Socket adaptor, i.e. sc.socket().getXXXStream. Another way is with Channels.newXXXStream(sc) factory methods. A long standing limitation is that the input/output streams returned by the Channels.newXXXStream methods must synchronize on the channel's blockingLock() to prevent the channel from being configured non-blocking. There is one "blocking lock" per SelectableChannel so problematic when the SelectableChannel is also a ByteChannel as it prevents a thread from writing while another is blocked in read (and vice versa). >> >> The change proposed here is to have Channels.newXXXStream special case the SocketChannel implementation so that it returns the same input/output stream as the socket adaptors. These socket streams make use of non-exposed blocking read/write methods that coordinate with configureBlocking so don't need to synchronize on the blockingLock. The core part of the change is that the inner classes that were in SocketAdaptor are moved to be top-level SocketInputStream and SocketOutputStream classes. >> >> There is some minor cleanup to ChannelInputStream and ChannelOutputStream in this patch. Once pattern matching for switch is permanent, and Markus Karg is done with transferTo, then we can see if we want to refactor that method and/or introduce a sub-class for FileChannel. >> >> I've added a new test to exercise the the read/write methods, with focus on async close and interrupt. It includes tests that do concurrent read + write operations. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Fix typo in comment > - Remove redundant case > - Merge > - Cleanup > - Merge > - Initial commit Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6953 From lancea at openjdk.java.net Wed Jan 5 20:23:20 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 5 Jan 2022 20:23:20 GMT Subject: RFR: 8279339: (ch) Input/Output streams returned by Channels factory methods don't support concurrent read/write ops [v2] In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 20:05:53 GMT, Alan Bateman wrote: >> If someone has a SocketChannel sc then one way to obtain input/output streams is via the Socket adaptor, i.e. sc.socket().getXXXStream. Another way is with Channels.newXXXStream(sc) factory methods. A long standing limitation is that the input/output streams returned by the Channels.newXXXStream methods must synchronize on the channel's blockingLock() to prevent the channel from being configured non-blocking. There is one "blocking lock" per SelectableChannel so problematic when the SelectableChannel is also a ByteChannel as it prevents a thread from writing while another is blocked in read (and vice versa). >> >> The change proposed here is to have Channels.newXXXStream special case the SocketChannel implementation so that it returns the same input/output stream as the socket adaptors. These socket streams make use of non-exposed blocking read/write methods that coordinate with configureBlocking so don't need to synchronize on the blockingLock. The core part of the change is that the inner classes that were in SocketAdaptor are moved to be top-level SocketInputStream and SocketOutputStream classes. >> >> There is some minor cleanup to ChannelInputStream and ChannelOutputStream in this patch. Once pattern matching for switch is permanent, and Markus Karg is done with transferTo, then we can see if we want to refactor that method and/or introduce a sub-class for FileChannel. >> >> I've added a new test to exercise the the read/write methods, with focus on async close and interrupt. It includes tests that do concurrent read + write operations. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Fix typo in comment > - Remove redundant case > - Merge > - Cleanup > - Merge > - Initial commit Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6953 From alanb at openjdk.java.net Thu Jan 6 08:16:19 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 6 Jan 2022 08:16:19 GMT Subject: Integrated: 8279339: (ch) Input/Output streams returned by Channels factory methods don't support concurrent read/write ops In-Reply-To: References: Message-ID: On Tue, 4 Jan 2022 09:13:34 GMT, Alan Bateman wrote: > If someone has a SocketChannel sc then one way to obtain input/output streams is via the Socket adaptor, i.e. sc.socket().getXXXStream. Another way is with Channels.newXXXStream(sc) factory methods. A long standing limitation is that the input/output streams returned by the Channels.newXXXStream methods must synchronize on the channel's blockingLock() to prevent the channel from being configured non-blocking. There is one "blocking lock" per SelectableChannel so problematic when the SelectableChannel is also a ByteChannel as it prevents a thread from writing while another is blocked in read (and vice versa). > > The change proposed here is to have Channels.newXXXStream special case the SocketChannel implementation so that it returns the same input/output stream as the socket adaptors. These socket streams make use of non-exposed blocking read/write methods that coordinate with configureBlocking so don't need to synchronize on the blockingLock. The core part of the change is that the inner classes that were in SocketAdaptor are moved to be top-level SocketInputStream and SocketOutputStream classes. > > There is some minor cleanup to ChannelInputStream and ChannelOutputStream in this patch. Once pattern matching for switch is permanent, and Markus Karg is done with transferTo, then we can see if we want to refactor that method and/or introduce a sub-class for FileChannel. > > I've added a new test to exercise the the read/write methods, with focus on async close and interrupt. It includes tests that do concurrent read + write operations. This pull request has now been integrated. Changeset: 2dbb936d Author: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/2dbb936da91a875a5a88da5d4c0b4956b9c6368f Stats: 907 lines in 8 files changed: 751 ins; 116 del; 40 mod 8279339: (ch) Input/Output streams returned by Channels factory methods don't support concurrent read/write ops Reviewed-by: lancea, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/6953 From jvernee at openjdk.java.net Thu Jan 6 12:19:32 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 6 Jan 2022 12:19:32 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution [v2] In-Reply-To: <7ouKP99gKljCPTw091C9WUnwXiENN9nJCvIF09fPU9w=.1277b87b-242a-46c1-8f30-1c18671171d1@github.com> References: <7ouKP99gKljCPTw091C9WUnwXiENN9nJCvIF09fPU9w=.1277b87b-242a-46c1-8f30-1c18671171d1@github.com> Message-ID: On Wed, 5 Jan 2022 18:08:01 GMT, Maurizio Cimadamore wrote: >> This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: >> >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op >> LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op >> LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op >> LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op >> >> >> That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). >> >> In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: >> >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op >> LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op >> >> >> Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Use owner field instead of accessor in checkValidStateSlow Marked as reviewed by jvernee (Reviewer). src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ConfinedScope.java line 45: > 43: private int lockCount = 0; > 44: private int asyncReleaseCount = 0; > 45: private final Thread owner; Is this `owner` field still needed now that the super class also has it? ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From mcimadamore at openjdk.java.net Thu Jan 6 12:19:33 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 6 Jan 2022 12:19:33 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution [v2] In-Reply-To: References: <7ouKP99gKljCPTw091C9WUnwXiENN9nJCvIF09fPU9w=.1277b87b-242a-46c1-8f30-1c18671171d1@github.com> Message-ID: On Thu, 6 Jan 2022 12:11:29 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Use owner field instead of accessor in checkValidStateSlow > > src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ConfinedScope.java line 45: > >> 43: private int lockCount = 0; >> 44: private int asyncReleaseCount = 0; >> 45: private final Thread owner; > > Is this `owner` field still needed now that the super class also has it? Forgot to remove - well spotted ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From mcimadamore at openjdk.java.net Thu Jan 6 12:36:52 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 6 Jan 2022 12:36:52 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution [v3] In-Reply-To: References: Message-ID: > This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op > > > That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). > > In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op > > > Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: * Drop redundant owner field * Reuse `state` variable for confined lock count ------------- Changes: - all: https://git.openjdk.java.net/jdk18/pull/82/files - new: https://git.openjdk.java.net/jdk18/pull/82/files/04a1e9f2..e0bbc8f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=82&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=82&range=01-02 Stats: 9 lines in 1 file changed: 0 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk18/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/82/head:pull/82 PR: https://git.openjdk.java.net/jdk18/pull/82 From jvernee at openjdk.java.net Fri Jan 7 13:11:17 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 7 Jan 2022 13:11:17 GMT Subject: [jdk18] RFR: 8279527: Dereferencing segments backed by different scopes leads to pollution [v3] In-Reply-To: References: Message-ID: On Thu, 6 Jan 2022 12:36:52 GMT, Maurizio Cimadamore wrote: >> This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: >> >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op >> LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op >> LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op >> LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op >> >> >> That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). >> >> In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: >> >> >> Benchmark Mode Cnt Score Error Units >> LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op >> LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op >> LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op >> LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op >> LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op >> LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op >> >> >> Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > * Drop redundant owner field > * Reuse `state` variable for confined lock count Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From mcimadamore at openjdk.java.net Fri Jan 7 13:45:19 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 7 Jan 2022 13:45:19 GMT Subject: [jdk18] Integrated: 8279527: Dereferencing segments backed by different scopes leads to pollution In-Reply-To: References: Message-ID: On Wed, 5 Jan 2022 16:59:30 GMT, Maurizio Cimadamore wrote: > This patch fixes a performance issue when dereferencing memory segments backed by different kinds of scopes. When looking at inline traces, I found that one of our benchmark, namely `LoopOverPollutedSegment` was already hitting the ceiling of the bimorphic inline cache, specifically when checking liveness of the segment scope in the memory access hotpath (`ResourceScopeImpl::checkValidState`). The benchmark only used segments backed by confined and global scope. I then added (in the initialization "polluting" loop) segments backed by a shared scope, and then the benchmark numbers started to look as follows: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 7.004 ? 0.089 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 7.159 ? 0.016 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 7.017 ? 0.110 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 7.175 ? 0.048 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.243 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 7.366 ? 0.036 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 7.305 ? 0.098 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.238 ? 0.002 ms/op > > > That is, since now we have *three* different kinds of scopes (confined, shared and global), the call to the liveness check can no longer be inlined. One solution could be, as we do for the *base* accessor, to add a scope accessor to all memory segment implementation classes. But doing so only works ok for heap segments (for which the scope accessor just returns the global scope constants). For native segments, we're still megamorphic (as a native segment can be backed by all kinds of scopes). > > In the end, it turned out to be much simpler to just make the liveness check monomorphic, since there's so much sharing between the code paths already. With that change, numbers of the tweaked benchmark go back to normal: > > > Benchmark Mode Cnt Score Error Units > LoopOverPollutedSegments.heap_segment_floats_VH avgt 30 0.241 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_floats_instance avgt 30 0.244 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_VH avgt 30 0.242 ? 0.003 ms/op > LoopOverPollutedSegments.heap_segment_ints_instance avgt 30 0.248 ? 0.001 ms/op > LoopOverPollutedSegments.heap_unsafe avgt 30 0.247 ? 0.013 ms/op > LoopOverPollutedSegments.native_segment_VH avgt 30 0.245 ? 0.004 ms/op > LoopOverPollutedSegments.native_segment_instance avgt 30 0.245 ? 0.001 ms/op > LoopOverPollutedSegments.native_unsafe avgt 30 0.247 ? 0.005 ms/op > > > Note that this patch tidies up a bit the usage of `checkValidState` vs. `checkValidStateSlow`. The former should only really be used in the hot path, while the latter is a more general routine which should be used in non-performance critical code. Making `checkValidState` monomorphic caused the `ScopeAccessError` to be generated in more places, so I needed to either update the usage to use the safer `checkValidStateSlow` (where possible) or, (in `Buffer` and `ConfinedScope`) just add extra wrapping. This pull request has now been integrated. Changeset: d65c6658 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk18/commit/d65c665839c0a564c422ef685f2673fac37315d7 Stats: 116 lines in 8 files changed: 40 ins; 52 del; 24 mod 8279527: Dereferencing segments backed by different scopes leads to pollution Reviewed-by: psandoz, jvernee ------------- PR: https://git.openjdk.java.net/jdk18/pull/82 From alanb at openjdk.java.net Mon Jan 10 09:01:29 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 10 Jan 2022 09:01:29 GMT Subject: RFR: 8278268 - (ch) InputStream returned by Channels.newInputStream should have fast path for FileChannel targets [v15] In-Reply-To: <3y4DdQ1hOUjOKWxuZ4JCwl9abqXbjqXpf-Awx9qLoek=.7d21aa99-9527-4c0f-b4a8-148073f98e71@github.com> References: <4RcpFZMVKNqYuiowJOFwZuM_RDwKHAt8KyOPHz3S5c4=.23940329-cbf6-4f13-b044-eb91e4193f36@github.com> <3y4DdQ1hOUjOKWxuZ4JCwl9abqXbjqXpf-Awx9qLoek=.7d21aa99-9527-4c0f-b4a8-148073f98e71@github.com> Message-ID: On Thu, 30 Dec 2021 10:12:20 GMT, Markus KARG wrote: >>> @AlanBateman I found [the cause of the problem](https://github.com/trishagee/socket-locking/pull/1#issuecomment-1002187644). The problem is that ChannelInputStream and ChannelOutputStream share the same blocking lock when created for the same IP connection, which is pretty straightforward, as a SocketChannel is bidirectional by nature, but has only one blocking setting for both directions. This shared lock is not documented anywhere, so how should an application programmer know about this? This should _either_ be documented in the Channels JavaDocs, or (even better) there should be separate blocking modes per direction. FYI, the channel reader does not produce the deadlock as it does not care about the blocking mode at all but simply expects non-blocking mode so it runs in an active loop (squandering power). Maybe we should align both implementations, reader and stream? WDYT? >> >> Good sleuthing! This is a design bug that goes back to JSR-51/Java 1.4 (https://bugs.openjdk.java.net/browse/JDK-4509080). SelectableChannel specifies blockingLock, which is okay for adaptors and the like when they are readable or writable, but not both. The socket adaptors have been re-implemented so as not to require the blockingLock during read/write operations so this limits the issue to the interop support that Channels provides. It's fixable with a bit of surgery. A first attempt would be for Channels.newInputStream to return sc.socket().getInputStream() when the channel is a SocketChannel. This requires dealing with cases where someone attempts to get an input stream from an unconnected or closed channel. A second attempt would be to add sun.nio.ch.SocketInputStream >> >> package sun.nio.ch; >> >> import java.io.IOException; >> import java.io.InputStream; >> >> public class SocketInputStream extends InputStream { >> private final SocketChannelImpl sc; >> public SocketInputStream(SocketChannelImpl sc) { >> this.sc = sc; >> } >> @Override >> public int read() throws IOException { >> byte[] a = new byte[1]; >> int n = read(a, 0, 1); >> return (n > 0) ? (a[0] & 0xff) : -1; >> } >> @Override >> public int read(byte[] b, int off, int len) throws IOException { >> return sc.blockingRead(b, off, len, 0); >> } >> @Override >> public int available() throws IOException { >> return sc.available(); >> } >> @Override >> public void close() throws IOException { >> sc.close(); >> } >> } >> >> The main question is whether it's worth doing. > > @AlanBateman @LanceAndersen Back to the original thread of this PR, are there more change requests or is it fine for merging? @mkarg Do you have any benchmarks/results for the change? I'm asking because FileChannel transferTo is implemented (where possible) on sendfile/equivalent so fast for the file -> socket and file -> file cases. The changes in this PR make use of FileChannel transferFrom so may not be significantly better than the default implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/6711 From jpai at openjdk.java.net Mon Jan 10 15:13:52 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 10 Jan 2022 15:13:52 GMT Subject: RFR: 8279536: jdk/nio/zipfs/ZipFSOutputStreamTest.java timed out Message-ID: Can I please get a review for this test only change which helps drastically improve the time taken by the `jdk/nio/zipfs/ZipFSOutputStreamTest.java` testcase? This `jdk/nio/zipfs/ZipFSOutputStreamTest.java` testcase was initially introduced in https://github.com/openjdk/jdk/pull/4607 to reproduce and verify the bug fix for https://bugs.openjdk.java.net/browse/JDK-8190753. The test does the following: - Using ZipFS creates a zip file with entries of varying size. Each of these entries use random byte content. - One of the entry size is `Integer.MAX_SIZE + 1` byte to trigger/verify the issue noted in JDK-8190753. - Finally the test verifies the contents of the generated entries in the zip file by matching it against the previously generated random content. The slowness resides in the way this testing/verification is done in this test case. Currently there's a loop which compares one byte at a time for each of these entries. This is unncessary and this adds up especially for the `Integer.MAX_SIZE + 1` sized entry. The change in this PR, improves this verification logic by using a fixed data to write out the entries and then read/verify that (fixed) content. This allows for better/quicker comparison of the entries. Without this change, the testcase used to consistently take around 3 minutes 30 seconds to 3 minutes 50 seconds on my local setup. With this change the test now consistently completes (successfully) in just around 40 to 42 seconds (i.e. within a minute). The original configuration of this test case uses a timeout of 300 seconds (5 minutes). That timeout was used based on the numbers I was seeing for this test completion. With this change, I don't expect it to require that much amount of time to complete (even on slow setups). However, I decided not to change that value just yet in this PR (since it anyway is a "maximum" time). Additionally this PR adds some diagnostic logs for any future use if/when this test times out. ------------- Commit messages: - 8279536: jdk/nio/zipfs/ZipFSOutputStreamTest.java timed out Changes: https://git.openjdk.java.net/jdk/pull/7010/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7010&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279536 Stats: 18 lines in 1 file changed: 9 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7010.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7010/head:pull/7010 PR: https://git.openjdk.java.net/jdk/pull/7010 From jwilhelm at openjdk.java.net Mon Jan 10 17:10:41 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 10 Jan 2022 17:10:41 GMT Subject: Integrated: Merge jdk18 In-Reply-To: <5hMMnbP2laUfEjb0svduDuzGgdUJckDDcCxaj-7QZg0=.1fd54c99-b81e-41e1-b3d7-bbdbedf161c9@github.com> References: <5hMMnbP2laUfEjb0svduDuzGgdUJckDDcCxaj-7QZg0=.1fd54c99-b81e-41e1-b3d7-bbdbedf161c9@github.com> Message-ID: On Mon, 10 Jan 2022 17:00:05 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: d9b1bb58 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/d9b1bb58600c03cee43387864d1530d4dd5f1422 Stats: 615 lines in 24 files changed: 478 ins; 77 del; 60 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/7017 From jwilhelm at openjdk.java.net Mon Jan 10 17:10:40 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 10 Jan 2022 17:10:40 GMT Subject: Integrated: Merge jdk18 Message-ID: <5hMMnbP2laUfEjb0svduDuzGgdUJckDDcCxaj-7QZg0=.1fd54c99-b81e-41e1-b3d7-bbdbedf161c9@github.com> Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge - 8274679: Remove unnecessary conversion to String in security code in java.base - 8142362: Lots of code duplication in Copy class - 8218857: Confusing overloads for os::open - 8183227: read/write APIs in class os shall return ssize_t - 8279300: [arm32] SIGILL when running GetObjectSizeIntrinsicsTest - 8278329: some TraceDeoptimization code not included in PRODUCT build - 8279523: Parallel: Remove unnecessary PSScavenge::_to_space_top_before_gc - 8279522: Serial: Remove unused Generation::clear_remembered_set - 8279528: Unused TypeEnter.diag after JDK-8205187 - ... and 163 more: https://git.openjdk.java.net/jdk/compare/40df5df9...6ff1c607 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jdk/pull/7017/files Stats: 27994 lines in 750 files changed: 20678 ins; 5315 del; 2001 mod Patch: https://git.openjdk.java.net/jdk/pull/7017.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7017/head:pull/7017 PR: https://git.openjdk.java.net/jdk/pull/7017 From lancea at openjdk.java.net Mon Jan 10 18:58:28 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 10 Jan 2022 18:58:28 GMT Subject: RFR: 8279536: jdk/nio/zipfs/ZipFSOutputStreamTest.java timed out In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 15:06:11 GMT, Jaikiran Pai wrote: > Can I please get a review for this test only change which helps drastically improve the time taken by the `jdk/nio/zipfs/ZipFSOutputStreamTest.java` testcase? > > This `jdk/nio/zipfs/ZipFSOutputStreamTest.java` testcase was initially introduced in https://github.com/openjdk/jdk/pull/4607 to reproduce and verify the bug fix for https://bugs.openjdk.java.net/browse/JDK-8190753. The test does the following: > - Using ZipFS creates a zip file with entries of varying size. Each of these entries use random byte content. > - One of the entry size is `Integer.MAX_SIZE + 1` byte to trigger/verify the issue noted in JDK-8190753. > - Finally the test verifies the contents of the generated entries in the zip file by matching it against the previously generated random content. The slowness resides in the way this testing/verification is done in this test case. Currently there's a loop which compares one byte at a time for each of these entries. This is unncessary and this adds up especially for the `Integer.MAX_SIZE + 1` sized entry. > > The change in this PR, improves this verification logic by using a fixed data to write out the entries and then read/verify that (fixed) content. This allows for better/quicker comparison of the entries. > > Without this change, the testcase used to consistently take around 3 minutes 30 seconds to 3 minutes 50 seconds on my local setup. With this change the test now consistently completes (successfully) in just around 40 to 42 seconds (i.e. within a minute). > > The original configuration of this test case uses a timeout of 300 seconds (5 minutes). That timeout was used based on the numbers I was seeing for this test completion. With this change, I don't expect it to require that much amount of time to complete (even on slow setups). However, I decided not to change that value just yet in this PR (since it anyway is a "maximum" time). > > Additionally this PR adds some diagnostic logs for any future use if/when this test times out. The changes look reasonable. I am going to run this a several hundred times to see where we get. ------------- PR: https://git.openjdk.java.net/jdk/pull/7010 From lancea at openjdk.java.net Wed Jan 12 11:48:21 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 12 Jan 2022 11:48:21 GMT Subject: RFR: 8279536: jdk/nio/zipfs/ZipFSOutputStreamTest.java timed out In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 15:06:11 GMT, Jaikiran Pai wrote: > Can I please get a review for this test only change which helps drastically improve the time taken by the `jdk/nio/zipfs/ZipFSOutputStreamTest.java` testcase? > > This `jdk/nio/zipfs/ZipFSOutputStreamTest.java` testcase was initially introduced in https://github.com/openjdk/jdk/pull/4607 to reproduce and verify the bug fix for https://bugs.openjdk.java.net/browse/JDK-8190753. The test does the following: > - Using ZipFS creates a zip file with entries of varying size. Each of these entries use random byte content. > - One of the entry size is `Integer.MAX_SIZE + 1` byte to trigger/verify the issue noted in JDK-8190753. > - Finally the test verifies the contents of the generated entries in the zip file by matching it against the previously generated random content. The slowness resides in the way this testing/verification is done in this test case. Currently there's a loop which compares one byte at a time for each of these entries. This is unncessary and this adds up especially for the `Integer.MAX_SIZE + 1` sized entry. > > The change in this PR, improves this verification logic by using a fixed data to write out the entries and then read/verify that (fixed) content. This allows for better/quicker comparison of the entries. > > Without this change, the testcase used to consistently take around 3 minutes 30 seconds to 3 minutes 50 seconds on my local setup. With this change the test now consistently completes (successfully) in just around 40 to 42 seconds (i.e. within a minute). > > The original configuration of this test case uses a timeout of 300 seconds (5 minutes). That timeout was used based on the numbers I was seeing for this test completion. With this change, I don't expect it to require that much amount of time to complete (even on slow setups). However, I decided not to change that value just yet in this PR (since it anyway is a "maximum" time). > > Additionally this PR adds some diagnostic logs for any future use if/when this test times out. I think you are good to go. I ran your change 1800 times across the various Mach5 platforms that we have without failure. 37 of the runs were over a minute, with the max run of 3 minutes, 27 seconds. Only 2 of the runs were over 3 minutes. In case you are interested, here is the output from the slowest run: Wrote entry f1 of bytes 2147483648 in 30330 milli seconds Wrote entry f2 of bytes 26214400 in 889 milli seconds Wrote entry d1/d2/f4 of bytes 0 in 0 milli seconds Wrote entry d1/f3 of bytes 1234 in 0 milli seconds Read entry f1 of bytes 2147483648 in 28988 milli seconds Read entry f2 of bytes 26214400 in 62 milli seconds Read entry d1/d2/f4 of bytes 0 in 0 milli seconds Read entry d1/f3 of bytes 1234 in 0 milli seconds test ZipFSOutputStreamTest.testOutputStream(java.util.ImmutableCollections$MapN at 15951e35): success config ZipFSOutputStreamTest.tearDown(): success config ZipFSOutputStreamTest.setUp(): success Wrote entry f1 of bytes 2147483648 in 11572 milli seconds Wrote entry f2 of bytes 26214400 in 145 milli seconds Wrote entry d1/d2/f4 of bytes 0 in 1 milli seconds Wrote entry d1/f3 of bytes 1234 in 0 milli seconds Read entry f1 of bytes 2147483648 in 4783 milli seconds Read entry f2 of bytes 26214400 in 64 milli seconds Read entry d1/d2/f4 of bytes 0 in 0 milli seconds Read entry d1/f3 of bytes 1234 in 0 milli seconds test ZipFSOutputStreamTest.testOutputStream(java.util.ImmutableCollections$MapN at 2092a6c3): success ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7010 From jpai at openjdk.java.net Wed Jan 12 13:02:33 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 12 Jan 2022 13:02:33 GMT Subject: Integrated: 8279536: jdk/nio/zipfs/ZipFSOutputStreamTest.java timed out In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 15:06:11 GMT, Jaikiran Pai wrote: > Can I please get a review for this test only change which helps drastically improve the time taken by the `jdk/nio/zipfs/ZipFSOutputStreamTest.java` testcase? > > This `jdk/nio/zipfs/ZipFSOutputStreamTest.java` testcase was initially introduced in https://github.com/openjdk/jdk/pull/4607 to reproduce and verify the bug fix for https://bugs.openjdk.java.net/browse/JDK-8190753. The test does the following: > - Using ZipFS creates a zip file with entries of varying size. Each of these entries use random byte content. > - One of the entry size is `Integer.MAX_SIZE + 1` byte to trigger/verify the issue noted in JDK-8190753. > - Finally the test verifies the contents of the generated entries in the zip file by matching it against the previously generated random content. The slowness resides in the way this testing/verification is done in this test case. Currently there's a loop which compares one byte at a time for each of these entries. This is unncessary and this adds up especially for the `Integer.MAX_SIZE + 1` sized entry. > > The change in this PR, improves this verification logic by using a fixed data to write out the entries and then read/verify that (fixed) content. This allows for better/quicker comparison of the entries. > > Without this change, the testcase used to consistently take around 3 minutes 30 seconds to 3 minutes 50 seconds on my local setup. With this change the test now consistently completes (successfully) in just around 40 to 42 seconds (i.e. within a minute). > > The original configuration of this test case uses a timeout of 300 seconds (5 minutes). That timeout was used based on the numbers I was seeing for this test completion. With this change, I don't expect it to require that much amount of time to complete (even on slow setups). However, I decided not to change that value just yet in this PR (since it anyway is a "maximum" time). > > Additionally this PR adds some diagnostic logs for any future use if/when this test times out. This pull request has now been integrated. Changeset: ff0cb989 Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/ff0cb98965a0b6be2f6c399e4645630c10b3466e Stats: 18 lines in 1 file changed: 9 ins; 4 del; 5 mod 8279536: jdk/nio/zipfs/ZipFSOutputStreamTest.java timed out Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/7010 From jpai at openjdk.java.net Wed Jan 12 13:02:33 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 12 Jan 2022 13:02:33 GMT Subject: RFR: 8279536: jdk/nio/zipfs/ZipFSOutputStreamTest.java timed out In-Reply-To: References: Message-ID: On Mon, 10 Jan 2022 15:06:11 GMT, Jaikiran Pai wrote: > Can I please get a review for this test only change which helps drastically improve the time taken by the `jdk/nio/zipfs/ZipFSOutputStreamTest.java` testcase? > > This `jdk/nio/zipfs/ZipFSOutputStreamTest.java` testcase was initially introduced in https://github.com/openjdk/jdk/pull/4607 to reproduce and verify the bug fix for https://bugs.openjdk.java.net/browse/JDK-8190753. The test does the following: > - Using ZipFS creates a zip file with entries of varying size. Each of these entries use random byte content. > - One of the entry size is `Integer.MAX_SIZE + 1` byte to trigger/verify the issue noted in JDK-8190753. > - Finally the test verifies the contents of the generated entries in the zip file by matching it against the previously generated random content. The slowness resides in the way this testing/verification is done in this test case. Currently there's a loop which compares one byte at a time for each of these entries. This is unncessary and this adds up especially for the `Integer.MAX_SIZE + 1` sized entry. > > The change in this PR, improves this verification logic by using a fixed data to write out the entries and then read/verify that (fixed) content. This allows for better/quicker comparison of the entries. > > Without this change, the testcase used to consistently take around 3 minutes 30 seconds to 3 minutes 50 seconds on my local setup. With this change the test now consistently completes (successfully) in just around 40 to 42 seconds (i.e. within a minute). > > The original configuration of this test case uses a timeout of 300 seconds (5 minutes). That timeout was used based on the numbers I was seeing for this test completion. With this change, I don't expect it to require that much amount of time to complete (even on slow setups). However, I decided not to change that value just yet in this PR (since it anyway is a "maximum" time). > > Additionally this PR adds some diagnostic logs for any future use if/when this test times out. Thank you Lance for the review and running extensive tests. The numbers look reasonable to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/7010 From bpb at openjdk.java.net Thu Jan 13 02:49:43 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 13 Jan 2022 02:49:43 GMT Subject: RFR: 8279946: (ch) java.nio.channels.FileChannel tryLock and write methods are missing @throws NonWritableChannelException Message-ID: <-CHg8AcTLeC1xUiizSzokn8WFyugxADHbcZVjwRLlWo=.e46c108e-d3c9-4bcc-b694-02e45230d027@github.com> Please consider this change which would add `@throws` clauses for `NonWritableChannelException` to the various `tryLock()` and `write()` methods in `java.nio.channels.FileChannel`. ------------- Commit messages: - 8279946: (ch) java.nio.channels.FileChannel tryLock and write methods are missing @throws NonWritableChannelException Changes: https://git.openjdk.java.net/jdk/pull/7058/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7058&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279946 Stats: 23 lines in 1 file changed: 19 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7058.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7058/head:pull/7058 PR: https://git.openjdk.java.net/jdk/pull/7058 From bpb at openjdk.java.net Thu Jan 13 22:01:50 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 13 Jan 2022 22:01:50 GMT Subject: RFR: 8279990: (fs) Ankward verbiage in description of Files.createTempFile(Path,String,String,FileAttribute) Message-ID: This change would improve the description of `java.nio.file.Files.createTempFile(Path,String,String,FileAttribute)`. ------------- Commit messages: - 8279990: (fs) Ankward verbiage in description of Files.createTempFile(Path,String,String,FileAttribute) Changes: https://git.openjdk.java.net/jdk/pull/7071/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7071&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279990 Stats: 7 lines in 1 file changed: 1 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7071.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7071/head:pull/7071 PR: https://git.openjdk.java.net/jdk/pull/7071 From brian.burkhalter at oracle.com Thu Jan 13 22:04:21 2022 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 13 Jan 2022 22:04:21 +0000 Subject: RFR: 8279990: (fs) Ankward verbiage in description of Files.createTempFile(Path,String,String,FileAttribute) In-Reply-To: References: Message-ID: "Ankward verbiage? indeed. Corrected. D?oh. On Jan 13, 2022, at 2:01 PM, Brian Burkhalter > wrote: This change would improve the description of `java.nio.file.Files.createTempFile(Path,String,String,FileAttribute)`. ------------- Commit messages: - 8279990: (fs) Ankward verbiage in description of Files.createTempFile(Path,String,String,FileAttribute) Changes: https://git.openjdk.java.net/jdk/pull/7071/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7071&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279990 Stats: 7 lines in 1 file changed: 1 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7071.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7071/head:pull/7071 PR: https://git.openjdk.java.net/jdk/pull/7071 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.java.net Thu Jan 13 22:07:01 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 13 Jan 2022 22:07:01 GMT Subject: RFR: 8279990: (fs) Awkward verbiage in description of Files.createTempFile(Path,String,String,FileAttribute) [v2] In-Reply-To: References: Message-ID: > This change would improve the description of `java.nio.file.Files.createTempFile(Path,String,String,FileAttribute)`. Brian Burkhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8279990: (fs) Awkward verbiage in description of Files.createTempFile(Path,String,String,FileAttribute) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7071/files - new: https://git.openjdk.java.net/jdk/pull/7071/files/1f74214d..1cf026b0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7071&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7071&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7071.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7071/head:pull/7071 PR: https://git.openjdk.java.net/jdk/pull/7071 From lancea at openjdk.java.net Thu Jan 13 22:18:31 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 13 Jan 2022 22:18:31 GMT Subject: RFR: 8279990: (fs) Awkward verbiage in description of Files.createTempFile(Path,String,String,FileAttribute) [v2] In-Reply-To: References: Message-ID: <1a-BxdspDc6xHNCanWV02CbO4Gh8FVKDa0nKmA6aa_Q=.d7c202e4-ca9c-497a-af9d-6f0e4090a143@github.com> On Thu, 13 Jan 2022 22:07:01 GMT, Brian Burkhalter wrote: >> This change would improve the description of `java.nio.file.Files.createTempFile(Path,String,String,FileAttribute)`. > > Brian Burkhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8279990: (fs) Awkward verbiage in description of Files.createTempFile(Path,String,String,FileAttribute) src/java.base/share/classes/java/nio/file/Files.java line 826: > 824: * java.io.File#createTempFile(String,String,File)} method. > 825: * > 826: *

The resulting file should be deleted once it is no longer needed. I think this sentence can be omitted as the sentence which follow the above I believe can stand on its own ------------- PR: https://git.openjdk.java.net/jdk/pull/7071 From bpb at openjdk.java.net Thu Jan 13 22:25:06 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 13 Jan 2022 22:25:06 GMT Subject: RFR: 8279990: (fs) Awkward verbiage in description of Files.createTempFile(Path,String,String,FileAttribute) [v3] In-Reply-To: References: Message-ID: <3AXniMrEIdGra-GweU96mFHn2aNrDoWARlQZQMQgqkE=.498547f5-8ef9-4cbe-bdb8-c3ec7722ba70@github.com> > This change would improve the description of `java.nio.file.Files.createTempFile(Path,String,String,FileAttribute)`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8279990: Delete redundant sentence ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7071/files - new: https://git.openjdk.java.net/jdk/pull/7071/files/1cf026b0..c9581607 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7071&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7071&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7071.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7071/head:pull/7071 PR: https://git.openjdk.java.net/jdk/pull/7071 From bpb at openjdk.java.net Thu Jan 13 22:25:09 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 13 Jan 2022 22:25:09 GMT Subject: RFR: 8279990: (fs) Awkward verbiage in description of Files.createTempFile(Path,String,String,FileAttribute) [v2] In-Reply-To: <1a-BxdspDc6xHNCanWV02CbO4Gh8FVKDa0nKmA6aa_Q=.d7c202e4-ca9c-497a-af9d-6f0e4090a143@github.com> References: <1a-BxdspDc6xHNCanWV02CbO4Gh8FVKDa0nKmA6aa_Q=.d7c202e4-ca9c-497a-af9d-6f0e4090a143@github.com> Message-ID: <6ZHGWH5GOaffsxxCg-Ca4J1XZabJWL_wNmCeiB-zI1c=.325a67b2-2996-4b82-a500-59bb29562e62@github.com> On Thu, 13 Jan 2022 22:15:09 GMT, Lance Andersen wrote: >> Brian Burkhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8279990: (fs) Awkward verbiage in description of Files.createTempFile(Path,String,String,FileAttribute) > > src/java.base/share/classes/java/nio/file/Files.java line 826: > >> 824: * java.io.File#createTempFile(String,String,File)} method. >> 825: * >> 826: *

The resulting file should be deleted once it is no longer needed. > > I think this sentence can be omitted as the sentence which follow the above I believe can stand on its own I concur. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7071 From lancea at openjdk.java.net Thu Jan 13 22:31:24 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 13 Jan 2022 22:31:24 GMT Subject: RFR: 8279990: (fs) Awkward verbiage in description of Files.createTempFile(Path,String,String,FileAttribute) [v3] In-Reply-To: <3AXniMrEIdGra-GweU96mFHn2aNrDoWARlQZQMQgqkE=.498547f5-8ef9-4cbe-bdb8-c3ec7722ba70@github.com> References: <3AXniMrEIdGra-GweU96mFHn2aNrDoWARlQZQMQgqkE=.498547f5-8ef9-4cbe-bdb8-c3ec7722ba70@github.com> Message-ID: On Thu, 13 Jan 2022 22:25:06 GMT, Brian Burkhalter wrote: >> This change would improve the description of `java.nio.file.Files.createTempFile(Path,String,String,FileAttribute)`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8279990: Delete redundant sentence Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7071 From bpb at openjdk.java.net Fri Jan 14 17:51:30 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 14 Jan 2022 17:51:30 GMT Subject: Integrated: 8279990: (fs) Awkward verbiage in description of Files.createTempFile(Path,String,String,FileAttribute) In-Reply-To: References: Message-ID: <90xm8CzeQ4UoDYIQl4lAaoQ3BnbI3TNfoRz7EC_Hym0=.c71f5e2e-336c-4cf3-aaa1-b4645b3b3545@github.com> On Thu, 13 Jan 2022 21:55:43 GMT, Brian Burkhalter wrote: > This change would improve the description of `java.nio.file.Files.createTempFile(Path,String,String,FileAttribute)`. This pull request has now been integrated. Changeset: fb8fdc0f Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/fb8fdc0fbf17dd7e900cb688df4917b97b26b9ab Stats: 7 lines in 1 file changed: 1 ins; 2 del; 4 mod 8279990: (fs) Awkward verbiage in description of Files.createTempFile(Path,String,String,FileAttribute) Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/7071 From duke at openjdk.java.net Sat Jan 15 09:33:25 2022 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 15 Jan 2022 09:33:25 GMT Subject: RFR: 8278268 - (ch) InputStream returned by Channels.newInputStream should have fast path for FileChannel targets [v16] In-Reply-To: References: Message-ID: On Sat, 25 Dec 2021 16:10:37 GMT, Markus KARG wrote: >> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel. > > Markus KARG has updated the pull request incrementally with three additional commits since the last revision: > > - separate test class for each large file test > - Base class only contains utilities and helpers > - Renamed AbstractTransferTo to TransferToBase as it is not abstract I will set up an explicit benchmark for this case. ------------- PR: https://git.openjdk.java.net/jdk/pull/6711 From duke at openjdk.java.net Sat Jan 15 09:36:27 2022 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 15 Jan 2022 09:36:27 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: Message-ID: On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG wrote: >> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review. >> >> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are: >> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. >> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides. >> >> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. >> >> I encourage everybody to discuss this draft: >> * Are there valid arguments for *not* doing this change? >> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`? >> * How to go on from here: What is missing to get this ready for an actual review? > > Markus KARG has updated the pull request incrementally with two additional commits since the last revision: > > - Draft: Eliminated duplicate code using lambda expressions > - Draft: Use blocking mode also for target channel Please keep this PR open as I am working on several sub-issues currently. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From alanb at openjdk.java.net Sat Jan 15 16:25:25 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 15 Jan 2022 16:25:25 GMT Subject: RFR: 8279990: (fs) Awkward verbiage in description of Files.createTempFile(Path,String,String,FileAttribute) [v3] In-Reply-To: <3AXniMrEIdGra-GweU96mFHn2aNrDoWARlQZQMQgqkE=.498547f5-8ef9-4cbe-bdb8-c3ec7722ba70@github.com> References: <3AXniMrEIdGra-GweU96mFHn2aNrDoWARlQZQMQgqkE=.498547f5-8ef9-4cbe-bdb8-c3ec7722ba70@github.com> Message-ID: <3Yg9kEvXh2TQda5_vpRSP66IsVmIp1m0vL_tJLkPANE=.96409ce6-d4bb-4158-bff4-9afa14a67812@github.com> On Thu, 13 Jan 2022 22:25:06 GMT, Brian Burkhalter wrote: >> This change would improve the description of `java.nio.file.Files.createTempFile(Path,String,String,FileAttribute)`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8279990: Delete redundant sentence The original text was correct to say that the method is only part of a temporary-file facility. It was also correct to say that DELETE_ON_CLOSE is appropriate for working files that should be deleted when close. So I think we may need to create a new issue to restore the text, maybe in re-phased form, that was removed by this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7071 From aturbanov at openjdk.java.net Wed Jan 19 11:03:34 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 19 Jan 2022 11:03:34 GMT Subject: Integrated: 8274811: Remove superfluous use of boxing in java.base In-Reply-To: References: Message-ID: On Sat, 11 Sep 2021 12:11:50 GMT, Andrey Turbanov wrote: > Usages of primitive types should be preferred and makes code easier to read. > Similar cleanups: > 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168) java.desktop > 2. [JDK-8274234](https://bugs.openjdk.java.net/browse/JDK-8274234) java.sql.rowset This pull request has now been integrated. Changeset: 5af7f258 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/5af7f258144d9f753ebe6ebfada42f33aaed108b Stats: 11 lines in 4 files changed: 0 ins; 0 del; 11 mod 8274811: Remove superfluous use of boxing in java.base Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/5481 From michaelm at openjdk.java.net Wed Jan 19 13:17:45 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 19 Jan 2022 13:17:45 GMT Subject: [jdk18] RFR: 8280233: disable Unix domain sockets in PipeImpl Message-ID: Hi, Could I get the following change reviewed please? Pending full investigation of the cause of (JDK-8278369) we want to disable the use of Unix domain sockets in the Windows Pipe implementation, reverting to the previous (pre JDK 16) TCP socket impl. The TCP impl was always used in versions of windows other than 10, 2019 server+ that didn't support Unix domain sockets. There isn't a regression test as existing Pipe tests should be sufficient. It's not clear at this point if the issue is a JDK or Windows bug but it's expected the Unix domain impl will be restored later. UNIX protocol family SocketChannel/ServerSocketChannels still work after this change. Thanks, Michael. ------------- Commit messages: - update PipeImpl implNote - disable Unix domain sockets in PipeImpl Changes: https://git.openjdk.java.net/jdk18/pull/109/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=109&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280233 Stats: 18 lines in 1 file changed: 0 ins; 16 del; 2 mod Patch: https://git.openjdk.java.net/jdk18/pull/109.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/109/head:pull/109 PR: https://git.openjdk.java.net/jdk18/pull/109 From michaelm at openjdk.java.net Wed Jan 19 13:25:03 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 19 Jan 2022 13:25:03 GMT Subject: [jdk18] RFR: 8280233: disable Unix domain sockets in PipeImpl [v2] In-Reply-To: References: Message-ID: > Hi, > > Could I get the following change reviewed please? Pending full investigation of the cause of (JDK-8278369) we want to disable the use of Unix domain sockets in the Windows Pipe implementation, reverting to the previous (pre JDK 16) TCP socket impl. The TCP impl was always used in versions of windows other than 10, 2019 server+ that didn't support Unix domain sockets. There isn't a regression test as existing Pipe tests should be sufficient. > > It's not clear at this point if the issue is a JDK or Windows bug but it's expected the Unix domain impl will be restored later. UNIX protocol family SocketChannel/ServerSocketChannels still work after this change. > > Thanks, > > Michael. Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: removed dead code that handles UnixDomainSocketAddress ------------- Changes: - all: https://git.openjdk.java.net/jdk18/pull/109/files - new: https://git.openjdk.java.net/jdk18/pull/109/files/5079d373..19f3a5c4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=109&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=109&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk18/pull/109.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/109/head:pull/109 PR: https://git.openjdk.java.net/jdk18/pull/109 From alanb at openjdk.java.net Wed Jan 19 13:45:29 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 19 Jan 2022 13:45:29 GMT Subject: [jdk18] RFR: 8280233: Temporarily disable Unix domain sockets in Windows PipeImpl [v2] In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 13:25:03 GMT, Michael McMahon wrote: >> Hi, >> >> Could I get the following change reviewed please? Pending full investigation of the cause of (JDK-8278369) we want to disable the use of Unix domain sockets in the Windows Pipe implementation, reverting to the previous (pre JDK 16) TCP socket impl. The TCP impl was always used in versions of windows other than 10, 2019 server+ that didn't support Unix domain sockets. There isn't a regression test as existing Pipe tests should be sufficient. >> >> It's not clear at this point if the issue is a JDK or Windows bug but it's expected the Unix domain impl will be restored later. UNIX protocol family SocketChannel/ServerSocketChannels still work after this change. >> >> Thanks, >> >> Michael. > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > removed dead code that handles UnixDomainSocketAddress This looks okay. I assume you'll remove the import of java.net.StandardProtocolFamily and update the date in the copyright header too. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk18/pull/109 From michaelm at openjdk.java.net Wed Jan 19 14:01:15 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 19 Jan 2022 14:01:15 GMT Subject: [jdk18] RFR: 8280233: Temporarily disable Unix domain sockets in Windows PipeImpl [v3] In-Reply-To: References: Message-ID: > Hi, > > Could I get the following change reviewed please? Pending full investigation of the cause of (JDK-8278369) we want to disable the use of Unix domain sockets in the Windows Pipe implementation, reverting to the previous (pre JDK 16) TCP socket impl. The TCP impl was always used in versions of windows other than 10, 2019 server+ that didn't support Unix domain sockets. There isn't a regression test as existing Pipe tests should be sufficient. > > It's not clear at this point if the issue is a JDK or Windows bug but it's expected the Unix domain impl will be restored later. UNIX protocol family SocketChannel/ServerSocketChannels still work after this change. > > Thanks, > > Michael. Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: copyright update and remove unused import ------------- Changes: - all: https://git.openjdk.java.net/jdk18/pull/109/files - new: https://git.openjdk.java.net/jdk18/pull/109/files/19f3a5c4..2085e82f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk18&pr=109&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk18&pr=109&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk18/pull/109.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/109/head:pull/109 PR: https://git.openjdk.java.net/jdk18/pull/109 From alanb at openjdk.java.net Wed Jan 19 14:11:29 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 19 Jan 2022 14:11:29 GMT Subject: [jdk18] RFR: 8280233: Temporarily disable Unix domain sockets in Windows PipeImpl [v3] In-Reply-To: References: Message-ID: <1wZvL23vnbIOubNBFIRxgQx05BdHTtXezYwzMdrmBNA=.de898ccd-4c02-4829-8758-04b6bb6856c2@github.com> On Wed, 19 Jan 2022 14:01:15 GMT, Michael McMahon wrote: >> Hi, >> >> Could I get the following change reviewed please? Pending full investigation of the cause of (JDK-8278369) we want to disable the use of Unix domain sockets in the Windows Pipe implementation, reverting to the previous (pre JDK 16) TCP socket impl. The TCP impl was always used in versions of windows other than 10, 2019 server+ that didn't support Unix domain sockets. There isn't a regression test as existing Pipe tests should be sufficient. >> >> It's not clear at this point if the issue is a JDK or Windows bug but it's expected the Unix domain impl will be restored later. UNIX protocol family SocketChannel/ServerSocketChannels still work after this change. >> >> Thanks, >> >> Michael. > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > copyright update and remove unused import Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/109 From alanb at openjdk.java.net Wed Jan 19 16:52:30 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 19 Jan 2022 16:52:30 GMT Subject: RFR: 8279946: (ch) java.nio.channels.FileChannel tryLock and write methods are missing @throws NonWritableChannelException In-Reply-To: <-CHg8AcTLeC1xUiizSzokn8WFyugxADHbcZVjwRLlWo=.e46c108e-d3c9-4bcc-b694-02e45230d027@github.com> References: <-CHg8AcTLeC1xUiizSzokn8WFyugxADHbcZVjwRLlWo=.e46c108e-d3c9-4bcc-b694-02e45230d027@github.com> Message-ID: On Thu, 13 Jan 2022 02:40:39 GMT, Brian Burkhalter wrote: > Please consider this change which would add `@throws` clauses for `NonWritableChannelException` to the various `tryLock()` and `write()` methods in `java.nio.channels.FileChannel`. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7058 From michaelm at openjdk.java.net Wed Jan 19 19:52:06 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 19 Jan 2022 19:52:06 GMT Subject: [jdk18] Integrated: 8280233: Temporarily disable Unix domain sockets in Windows PipeImpl In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 10:01:38 GMT, Michael McMahon wrote: > Hi, > > Could I get the following change reviewed please? Pending full investigation of the cause of (JDK-8278369) we want to disable the use of Unix domain sockets in the Windows Pipe implementation, reverting to the previous (pre JDK 16) TCP socket impl. The TCP impl was always used in versions of windows other than 10, 2019 server+ that didn't support Unix domain sockets. There isn't a regression test as existing Pipe tests should be sufficient. > > It's not clear at this point if the issue is a JDK or Windows bug but it's expected the Unix domain impl will be restored later. UNIX protocol family SocketChannel/ServerSocketChannels still work after this change. > > Thanks, > > Michael. This pull request has now been integrated. Changeset: 03680bea Author: Michael McMahon URL: https://git.openjdk.java.net/jdk18/commit/03680bea1cca1113ea23a1eb7a413b93dd73c381 Stats: 25 lines in 1 file changed: 0 ins; 22 del; 3 mod 8280233: Temporarily disable Unix domain sockets in Windows PipeImpl Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk18/pull/109 From jwilhelm at openjdk.java.net Thu Jan 20 00:40:42 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 20 Jan 2022 00:40:42 GMT Subject: RFR: Merge jdk18 Message-ID: Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge - 8280233: Temporarily disable Unix domain sockets in Windows PipeImpl - 8278834: Error "Cannot read field "sym" because "this.lvar[od]" is null" when compiling - 8272058: 25 Null pointer dereference defect groups in 4 files - 8280234: AArch64 "core" variant does not build after JDK-8270947 - 8280155: [PPC64, s390] frame size checks are not yet correct - 8273383: vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes verifying length of DCQS - 8279654: jdk/incubator/vector/Vector256ConversionTests.java crashes randomly with SVE - 8278417: Closed test fails after JDK-8276108 on aarch64 - 8274096: Improve decoding of image files - ... and 30 more: https://git.openjdk.java.net/jdk/compare/98d96a77...e0d83a07 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=7151&range=00.0 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=7151&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/7151/files Stats: 1732 lines in 67 files changed: 933 ins; 606 del; 193 mod Patch: https://git.openjdk.java.net/jdk/pull/7151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7151/head:pull/7151 PR: https://git.openjdk.java.net/jdk/pull/7151 From jwilhelm at openjdk.java.net Thu Jan 20 01:21:56 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 20 Jan 2022 01:21:56 GMT Subject: Integrated: Merge jdk18 In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 00:28:55 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: 4616c13c Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/4616c13c2f1ced8a8bdeed81f0469523932e91b5 Stats: 1732 lines in 67 files changed: 933 ins; 606 del; 193 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/7151 From bpb at openjdk.java.net Thu Jan 20 17:59:25 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 20 Jan 2022 17:59:25 GMT Subject: RFR: 8279946: (ch) java.nio.channels.FileChannel tryLock and write methods are missing @throws NonWritableChannelException [v2] In-Reply-To: <-CHg8AcTLeC1xUiizSzokn8WFyugxADHbcZVjwRLlWo=.e46c108e-d3c9-4bcc-b694-02e45230d027@github.com> References: <-CHg8AcTLeC1xUiizSzokn8WFyugxADHbcZVjwRLlWo=.e46c108e-d3c9-4bcc-b694-02e45230d027@github.com> Message-ID: > Please consider this change which would add `@throws` clauses for `NonWritableChannelException` to the various `tryLock()` and `write()` methods in `java.nio.channels.FileChannel`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8279946: Add missing NonReadableChannelException for tryLock(long,long,boolean) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7058/files - new: https://git.openjdk.java.net/jdk/pull/7058/files/fa54174e..e7abdaab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7058&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7058&range=00-01 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7058.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7058/head:pull/7058 PR: https://git.openjdk.java.net/jdk/pull/7058 From lancea at openjdk.java.net Thu Jan 20 18:09:49 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 20 Jan 2022 18:09:49 GMT Subject: RFR: 8279946: (ch) java.nio.channels.FileChannel tryLock and write methods are missing @throws NonWritableChannelException [v2] In-Reply-To: References: <-CHg8AcTLeC1xUiizSzokn8WFyugxADHbcZVjwRLlWo=.e46c108e-d3c9-4bcc-b694-02e45230d027@github.com> Message-ID: On Thu, 20 Jan 2022 17:59:25 GMT, Brian Burkhalter wrote: >> Please consider this change which would add `@throws` clauses for `NonWritableChannelException` to the various `tryLock()` and `write()` methods in `java.nio.channels.FileChannel`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8279946: Add missing NonReadableChannelException for tryLock(long,long,boolean) This looks better Brian. Thank you for the update. Given FileChannel::tryLock() calls the method you updated, shouldn't we also update its javadoc for the relevant exceptions? ------------- PR: https://git.openjdk.java.net/jdk/pull/7058 From bpb at openjdk.java.net Thu Jan 20 18:14:51 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 20 Jan 2022 18:14:51 GMT Subject: RFR: 8279946: (ch) java.nio.channels.FileChannel tryLock and write methods are missing @throws NonWritableChannelException [v2] In-Reply-To: References: <-CHg8AcTLeC1xUiizSzokn8WFyugxADHbcZVjwRLlWo=.e46c108e-d3c9-4bcc-b694-02e45230d027@github.com> Message-ID: <90pa5EfygNJGketTZzliu1u_8QmVRV17BcifKUCtYNs=.4505af92-3a51-4335-b18a-263330362c53@github.com> On Thu, 20 Jan 2022 18:06:59 GMT, Lance Andersen wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8279946: Add missing NonReadableChannelException for tryLock(long,long,boolean) > > This looks better Brian. Thank you for the update. > > Given FileChannel::tryLock() calls the method you updated, shouldn't we also update its javadoc for the relevant exceptions? @LanceAndersen Thanks for the comments. I think that for the no-arg `tryLock()` only the `NonWritableChannelException` is relevant as the lock is exclusive, i.e., `shared` is implicitly `false`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7058 From lancea at openjdk.java.net Thu Jan 20 19:13:46 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 20 Jan 2022 19:13:46 GMT Subject: RFR: 8279946: (ch) java.nio.channels.FileChannel tryLock and write methods are missing @throws NonWritableChannelException [v2] In-Reply-To: References: <-CHg8AcTLeC1xUiizSzokn8WFyugxADHbcZVjwRLlWo=.e46c108e-d3c9-4bcc-b694-02e45230d027@github.com> Message-ID: On Thu, 20 Jan 2022 18:06:59 GMT, Lance Andersen wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8279946: Add missing NonReadableChannelException for tryLock(long,long,boolean) > > This looks better Brian. Thank you for the update. > > Given FileChannel::tryLock() calls the method you updated, shouldn't we also update its javadoc for the relevant exceptions? > @LanceAndersen Thanks for the comments. I think that for the no-arg `tryLock()` only the `NonWritableChannelException` is relevant as the lock is exclusive, i.e., `shared` is implicitly `false`. Yes, that I believe is correct from my read as well ------------- PR: https://git.openjdk.java.net/jdk/pull/7058 From bpb at openjdk.java.net Thu Jan 20 19:28:49 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 20 Jan 2022 19:28:49 GMT Subject: RFR: 8279946: (ch) java.nio.channels.FileChannel tryLock and write methods are missing @throws NonWritableChannelException [v2] In-Reply-To: References: <-CHg8AcTLeC1xUiizSzokn8WFyugxADHbcZVjwRLlWo=.e46c108e-d3c9-4bcc-b694-02e45230d027@github.com> Message-ID: On Thu, 20 Jan 2022 17:59:25 GMT, Brian Burkhalter wrote: >> Please consider this change which would add `@throws` clauses for `NonWritableChannelException` to the various `tryLock()` and `write()` methods in `java.nio.channels.FileChannel`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8279946: Add missing NonReadableChannelException for tryLock(long,long,boolean) For the no-arg `tryLock()` the NWCE throws clause is already there so there is nothing to add. ------------- PR: https://git.openjdk.java.net/jdk/pull/7058 From lancea at openjdk.java.net Thu Jan 20 19:37:50 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 20 Jan 2022 19:37:50 GMT Subject: RFR: 8279946: (ch) java.nio.channels.FileChannel tryLock and write methods are missing @throws NonWritableChannelException [v2] In-Reply-To: References: <-CHg8AcTLeC1xUiizSzokn8WFyugxADHbcZVjwRLlWo=.e46c108e-d3c9-4bcc-b694-02e45230d027@github.com> Message-ID: <0cwhK7Yq-9t6JwoRlWPcWPeh1OKLJqkZHDA1ZqPcyuM=.bfa800fd-0656-4351-8e9b-eec937f136d3@github.com> On Thu, 20 Jan 2022 19:25:56 GMT, Brian Burkhalter wrote: > For the no-arg `tryLock()` the NWCE throws clause is already there so there is nothing to add. See it now. Was comparing the your latest update and forgot you handled this in the 1st commit, my bad ------------- PR: https://git.openjdk.java.net/jdk/pull/7058 From bpb at openjdk.java.net Thu Jan 20 19:41:50 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 20 Jan 2022 19:41:50 GMT Subject: RFR: 8279946: (ch) java.nio.channels.FileChannel tryLock and write methods are missing @throws NonWritableChannelException [v2] In-Reply-To: References: <-CHg8AcTLeC1xUiizSzokn8WFyugxADHbcZVjwRLlWo=.e46c108e-d3c9-4bcc-b694-02e45230d027@github.com> Message-ID: On Thu, 20 Jan 2022 17:59:25 GMT, Brian Burkhalter wrote: >> Please consider this change which would add `@throws` clauses for `NonWritableChannelException` to the various `tryLock()` and `write()` methods in `java.nio.channels.FileChannel`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8279946: Add missing NonReadableChannelException for tryLock(long,long,boolean) No worries. ------------- PR: https://git.openjdk.java.net/jdk/pull/7058 From djelinski at openjdk.java.net Mon Jan 24 14:34:18 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 24 Jan 2022 14:34:18 GMT Subject: RFR: 8280241: (aio) java/foreign/channels/TestAsyncSocketChannels fails in IPv6 only env with ExceptionInInitializerError Message-ID: When IPv4 is disabled on a Windows system, `socket(AF_INET,...)` calls fail with `WSAEAFNOSUPPORT`. The socket is only needed to retrieve the address of ConnectEx method, and an IPv6 socket serves that purpose equally well. The patch was verified on a Windows 10 machine with IPv4 disabled using `netsh interface ipv4 uninstall`. Some tests are still failing, but `TestAsyncSocketChannels` is passing now. ------------- Commit messages: - Fix ConnectEx address retrieval on IPv4-only Windows machines Changes: https://git.openjdk.java.net/jdk/pull/7197/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7197&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280241 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7197.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7197/head:pull/7197 PR: https://git.openjdk.java.net/jdk/pull/7197 From dfuchs at openjdk.java.net Mon Jan 24 14:43:10 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 24 Jan 2022 14:43:10 GMT Subject: RFR: 8280241: (aio) java/foreign/channels/TestAsyncSocketChannels fails in IPv6 only env with ExceptionInInitializerError In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 14:27:51 GMT, Daniel Jeli?ski wrote: > When IPv4 is disabled on a Windows system, `socket(AF_INET,...)` calls fail with `WSAEAFNOSUPPORT`. > The socket is only needed to retrieve the address of ConnectEx method, and an IPv6 socket serves that purpose equally well. > > The patch was verified on a Windows 10 machine with IPv4 disabled using `netsh interface ipv4 uninstall`. Some tests are still failing, but `TestAsyncSocketChannels` is passing now. LGTM. Could you please add `8280241` to the `@bug` list in `java/foreign/channels/TestAsyncSocketChannels.java` - and update the copyright years in the modified files if needed? ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7197 From alanb at openjdk.java.net Mon Jan 24 15:10:10 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 24 Jan 2022 15:10:10 GMT Subject: RFR: 8280241: (aio) java/foreign/channels/TestAsyncSocketChannels fails in IPv6 only env with ExceptionInInitializerError In-Reply-To: References: Message-ID: <-w6AwYaob9h-nEpO6qA3LXC8jy08rzmzrAYCsSc7nSU=.66fb588d-9e3c-4e43-977b-31b9ebe230ad@github.com> On Mon, 24 Jan 2022 14:27:51 GMT, Daniel Jeli?ski wrote: > When IPv4 is disabled on a Windows system, `socket(AF_INET,...)` calls fail with `WSAEAFNOSUPPORT`. > The socket is only needed to retrieve the address of ConnectEx method, and an IPv6 socket serves that purpose equally well. > > The patch was verified on a Windows 10 machine with IPv4 disabled using `netsh interface ipv4 uninstall`. Some tests are still failing, but `TestAsyncSocketChannels` is passing now. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7197 From alanb at openjdk.java.net Mon Jan 24 15:10:10 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 24 Jan 2022 15:10:10 GMT Subject: RFR: 8280241: (aio) java/foreign/channels/TestAsyncSocketChannels fails in IPv6 only env with ExceptionInInitializerError In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 14:39:30 GMT, Daniel Fuchs wrote: > Could you please add `8280241` to the `@bug` list in `java/foreign/channels/TestAsyncSocketChannels.java` - and update the copyright years in the modified files if needed? I would expect all tests that use AsynchronousSocketChannel to fail when IPv4 is disabled, I assume it's not specific to this test. ------------- PR: https://git.openjdk.java.net/jdk/pull/7197 From bpb at openjdk.java.net Mon Jan 24 18:53:18 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 24 Jan 2022 18:53:18 GMT Subject: RFR: 8280366: (fs) Restore Files.createTempFile javadoc Message-ID: This change reverts commit fb8fdc0fbf17dd7e900cb688df4917b97b26b9ab and then makes a smaller change to the verbiage of `Files.createTempFile `. ------------- Commit messages: - 8280366: (fs) Restore Files.createTempFile javadoc Changes: https://git.openjdk.java.net/jdk/pull/7202/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7202&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280366 Stats: 7 lines in 1 file changed: 3 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7202.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7202/head:pull/7202 PR: https://git.openjdk.java.net/jdk/pull/7202 From bpb at openjdk.java.net Tue Jan 25 02:19:06 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 25 Jan 2022 02:19:06 GMT Subject: RFR: 4774868: (fc spec) Unclear spec for FileChannel.force Message-ID: Add verbiage to `FileChannel.force()` indicating that if the FileChannel is derived from a FileOutputStream or a RandomAccessFile using `getChannel()`, then any modifications made to the channel's file by methods invoked on the parent object will also be forced. ------------- Commit messages: - 4774868: (fc spec) Unclear spec for FileChannel.force Changes: https://git.openjdk.java.net/jdk/pull/7207/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7207&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-4774868 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7207.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7207/head:pull/7207 PR: https://git.openjdk.java.net/jdk/pull/7207 From alanb at openjdk.java.net Tue Jan 25 07:55:34 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 25 Jan 2022 07:55:34 GMT Subject: RFR: 8280366: (fs) Restore Files.createTempFile javadoc In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 18:47:45 GMT, Brian Burkhalter wrote: > This change reverts commit fb8fdc0fbf17dd7e900cb688df4917b97b26b9ab and then makes a smaller change to the verbiage of `Files.createTempFile `. src/java.base/share/classes/java/nio/file/Files.java line 828: > 826: *

As with the {@code File.createTempFile} methods, this method is only > 827: * part of a temporary-file facility. Where the resulting file is used > 828: * as a work file solely by a single instance of the Java virtual I think the insertion of "solely by a single instance of the Java virtual machine" will create questions and we'll end up re-writing the paragraph again. I think I'd prefer to just restore the text and then start again with the questions that lead to the change in the first place. ------------- PR: https://git.openjdk.java.net/jdk/pull/7202 From alanb at openjdk.java.net Tue Jan 25 08:00:42 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 25 Jan 2022 08:00:42 GMT Subject: RFR: 4774868: (fc spec) Unclear spec for FileChannel.force In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 02:12:38 GMT, Brian Burkhalter wrote: > Add verbiage to `FileChannel.force()` indicating that if the FileChannel is derived from a FileOutputStream or a RandomAccessFile using `getChannel()`, then any modifications made to the channel's file by methods invoked on the parent object will also be forced. src/java.base/share/classes/java/nio/channels/FileChannel.java line 560: > 558: * channel was derived from a {@link FileOutputStream} or > 559: * {@link RandomAccessFile} using the {@code getChannel} method, > 560: * via the methods defined in those classes. It may or This looks okay, I just note that the existing javadoc uses "obtain" rather than "derive". An alternative to consider is "or the methods defined by FOS or RAF when the channel was obtained with the getChannel method". ------------- PR: https://git.openjdk.java.net/jdk/pull/7207 From djelinski at openjdk.java.net Tue Jan 25 09:55:41 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 25 Jan 2022 09:55:41 GMT Subject: RFR: 8280241: (aio) AsynchronousSocketChannel init fails in IPv6 only Windows env In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 15:06:48 GMT, Alan Bateman wrote: > > Could you please add `8280241` to the `@bug` list in `java/foreign/channels/TestAsyncSocketChannels.java` - and update the copyright years in the modified files if needed? > > I would expect all tests that use AsynchronousSocketChannel to fail when IPv4 is disabled, I assume it's not specific to this test. That's correct. `TestAsyncSocketChannels` is just the only tier1 test that uses `AsynchronousSocketChannel`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7197 From djelinski at openjdk.java.net Tue Jan 25 10:22:12 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 25 Jan 2022 10:22:12 GMT Subject: RFR: 8280241: (aio) AsynchronousSocketChannel init fails in IPv6 only Windows env [v2] In-Reply-To: References: Message-ID: > When IPv4 is disabled on a Windows system, `socket(AF_INET,...)` calls fail with `WSAEAFNOSUPPORT`. > The socket is only needed to retrieve the address of ConnectEx method, and an IPv6 socket serves that purpose equally well. > > The patch was verified on a Windows 10 machine with IPv4 disabled using `netsh interface ipv4 uninstall`. Some tests are still failing, but `TestAsyncSocketChannels` is passing now. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Update copyright dates ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7197/files - new: https://git.openjdk.java.net/jdk/pull/7197/files/2f2207db..111f41bb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7197&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7197&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7197.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7197/head:pull/7197 PR: https://git.openjdk.java.net/jdk/pull/7197 From alanb at openjdk.java.net Tue Jan 25 10:31:32 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 25 Jan 2022 10:31:32 GMT Subject: RFR: 8280241: (aio) AsynchronousSocketChannel init fails in IPv6 only Windows env [v2] In-Reply-To: References: Message-ID: <0VfyAEga22VQ1_oEsR8mSEF7AHIp7TMbF-CCEpzAVPE=.9f81ac0f-57fc-4b00-8dfb-23d0944afd11@github.com> On Tue, 25 Jan 2022 10:22:12 GMT, Daniel Jeli?ski wrote: >> When IPv4 is disabled on a Windows system, `socket(AF_INET,...)` calls fail with `WSAEAFNOSUPPORT`. >> The socket is only needed to retrieve the address of ConnectEx method, and an IPv6 socket serves that purpose equally well. >> >> The patch was verified on a Windows 10 machine with IPv4 disabled using `netsh interface ipv4 uninstall`. Some tests are still failing, but `TestAsyncSocketChannels` is passing now. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright dates Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7197 From djelinski at openjdk.java.net Tue Jan 25 10:31:32 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 25 Jan 2022 10:31:32 GMT Subject: RFR: 8280241: (aio) AsynchronousSocketChannel init fails in IPv6 only Windows env [v2] In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 14:39:30 GMT, Daniel Fuchs wrote: >> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright dates > > LGTM. Could you please add `8280241` to the `@bug` list in `java/foreign/channels/TestAsyncSocketChannels.java` - and update the copyright years in the modified files if needed? Updated the copyright dates. @dfuch please confirm if you still want me to add the bug ID to the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/7197 From dfuchs at openjdk.java.net Tue Jan 25 10:39:37 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 25 Jan 2022 10:39:37 GMT Subject: RFR: 8280241: (aio) AsynchronousSocketChannel init fails in IPv6 only Windows env [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 10:22:12 GMT, Daniel Jeli?ski wrote: >> When IPv4 is disabled on a Windows system, `socket(AF_INET,...)` calls fail with `WSAEAFNOSUPPORT`. >> The socket is only needed to retrieve the address of ConnectEx method, and an IPv6 socket serves that purpose equally well. >> >> The patch was verified on a Windows 10 machine with IPv4 disabled using `netsh interface ipv4 uninstall`. Some tests are still failing, but `TestAsyncSocketChannels` is passing now. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright dates LGTM. The test will only verify your changes if IPv4 is disabled - and I see Alan has marked the issue as noreg-hard so I'm OK with not updating the `@bug` list in the test. I can sponsor the change if you integrate it. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7197 From djelinski at openjdk.java.net Tue Jan 25 11:20:38 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 25 Jan 2022 11:20:38 GMT Subject: Integrated: 8280241: (aio) AsynchronousSocketChannel init fails in IPv6 only Windows env In-Reply-To: References: Message-ID: <_YeRq8tiORfgIq4qV-EZUzAhX_6C1XpPQLFPPS_RbDA=.ec4679ed-718c-4068-8579-d07b089d5882@github.com> On Mon, 24 Jan 2022 14:27:51 GMT, Daniel Jeli?ski wrote: > When IPv4 is disabled on a Windows system, `socket(AF_INET,...)` calls fail with `WSAEAFNOSUPPORT`. > The socket is only needed to retrieve the address of ConnectEx method, and an IPv6 socket serves that purpose equally well. > > The patch was verified on a Windows 10 machine with IPv4 disabled using `netsh interface ipv4 uninstall`. Some tests are still failing, but `TestAsyncSocketChannels` is passing now. This pull request has now been integrated. Changeset: 36fbec78 Author: Daniel Jeli?ski Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/36fbec78be837fe1defb72f39c6e3f2b5135fddf Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod 8280241: (aio) AsynchronousSocketChannel init fails in IPv6 only Windows env Reviewed-by: dfuchs, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7197 From bpb at openjdk.java.net Tue Jan 25 17:25:10 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 25 Jan 2022 17:25:10 GMT Subject: RFR: 4774868: (fc spec) Unclear spec for FileChannel.force [v2] In-Reply-To: References: Message-ID: > Add verbiage to `FileChannel.force()` indicating that if the FileChannel is derived from a FileOutputStream or a RandomAccessFile using `getChannel()`, then any modifications made to the channel's file by methods invoked on the parent object will also be forced. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 4774868: Tweak verbiage ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7207/files - new: https://git.openjdk.java.net/jdk/pull/7207/files/93c2fb31..b5f80d7b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7207&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7207&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7207.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7207/head:pull/7207 PR: https://git.openjdk.java.net/jdk/pull/7207 From alanb at openjdk.java.net Tue Jan 25 17:25:11 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 25 Jan 2022 17:25:11 GMT Subject: RFR: 4774868: (fc spec) Unclear spec for FileChannel.force [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 17:21:52 GMT, Brian Burkhalter wrote: >> Add verbiage to `FileChannel.force()` indicating that if the FileChannel is derived from a FileOutputStream or a RandomAccessFile using `getChannel()`, then any modifications made to the channel's file by methods invoked on the parent object will also be forced. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 4774868: Tweak verbiage Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7207 From bpb at openjdk.java.net Tue Jan 25 17:25:14 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 25 Jan 2022 17:25:14 GMT Subject: RFR: 4774868: (fc spec) Unclear spec for FileChannel.force [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 07:57:29 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 4774868: Tweak verbiage > > src/java.base/share/classes/java/nio/channels/FileChannel.java line 560: > >> 558: * channel was derived from a {@link FileOutputStream} or >> 559: * {@link RandomAccessFile} using the {@code getChannel} method, >> 560: * via the methods defined in those classes. It may or > > This looks okay, I just note that the existing javadoc uses "obtain" rather than "derive". An alternative to consider is "or the methods defined by FOS or RAF when the channel was obtained with the getChannel method". So changed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7207 From bpb at openjdk.java.net Tue Jan 25 17:29:02 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 25 Jan 2022 17:29:02 GMT Subject: RFR: 8280366: (fs) Restore Files.createTempFile javadoc [v2] In-Reply-To: References: Message-ID: > This change reverts commit fb8fdc0fbf17dd7e900cb688df4917b97b26b9ab and then makes a smaller change to the verbiage of `Files.createTempFile `. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8280366: Revert to state prior to JDK-8279990 change modulo fixing a grammatical error ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7202/files - new: https://git.openjdk.java.net/jdk/pull/7202/files/8599059b..27d9bd7d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7202&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7202&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7202.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7202/head:pull/7202 PR: https://git.openjdk.java.net/jdk/pull/7202 From bpb at openjdk.java.net Tue Jan 25 18:05:38 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 25 Jan 2022 18:05:38 GMT Subject: Integrated: 8279946: (ch) java.nio.channels.FileChannel tryLock and write methods are missing @throws NonWritableChannelException In-Reply-To: <-CHg8AcTLeC1xUiizSzokn8WFyugxADHbcZVjwRLlWo=.e46c108e-d3c9-4bcc-b694-02e45230d027@github.com> References: <-CHg8AcTLeC1xUiizSzokn8WFyugxADHbcZVjwRLlWo=.e46c108e-d3c9-4bcc-b694-02e45230d027@github.com> Message-ID: On Thu, 13 Jan 2022 02:40:39 GMT, Brian Burkhalter wrote: > Please consider this change which would add `@throws` clauses for `NonWritableChannelException` to the various `tryLock()` and `write()` methods in `java.nio.channels.FileChannel`. This pull request has now been integrated. Changeset: f4575e40 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/f4575e4052bf66f1259c626e01a74d3ac593e645 Stats: 28 lines in 1 file changed: 23 ins; 0 del; 5 mod 8279946: (ch) java.nio.channels.FileChannel tryLock and write methods are missing @throws NonWritableChannelException Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7058 From bpb at openjdk.java.net Wed Jan 26 00:46:56 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 26 Jan 2022 00:46:56 GMT Subject: RFR: 4750574: (se spec) Selector spec should clarify calculation of select return value Message-ID: Improve the description of the return value of each of the `Selector.select()` methods which do not accept an action parameter. ------------- Commit messages: - 4750574: (se spec) Selector spec should clarify calculation of select return value Changes: https://git.openjdk.java.net/jdk/pull/7220/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7220&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-4750574 Stats: 9 lines in 1 file changed: 3 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7220.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7220/head:pull/7220 PR: https://git.openjdk.java.net/jdk/pull/7220 From alanb at openjdk.java.net Wed Jan 26 08:37:34 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 26 Jan 2022 08:37:34 GMT Subject: RFR: 8280366: (fs) Restore Files.createTempFile javadoc [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 17:29:02 GMT, Brian Burkhalter wrote: >> This change reverts commit fb8fdc0fbf17dd7e900cb688df4917b97b26b9ab and then makes a smaller change to the verbiage of `Files.createTempFile `. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8280366: Revert to state prior to JDK-8279990 change modulo fixing a grammatical error Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7202 From dfuchs at openjdk.java.net Wed Jan 26 10:23:34 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 26 Jan 2022 10:23:34 GMT Subject: RFR: 4750574: (se spec) Selector spec should clarify calculation of select return value In-Reply-To: References: Message-ID: <0Ou95IEz9TAZhnfWJaXw0nrx1ktx7qJMi0SV6rZL84s=.a4a1fcd5-ba41-4e91-8c84-326a433a7b25@github.com> On Wed, 26 Jan 2022 00:19:36 GMT, Brian Burkhalter wrote: > Improve the description of the return value of each of the `Selector.select()` methods which do not accept an action parameter. Ah, yes - I have been bitten by this before. I wonder if it would deserve an `@apiNote` to say that the number returned doesn't always reflect the number of keys present in the selected-key set, and that a caller may consider clearing the selected-key set before calling these methods if they want to ensure that the number returned is equal to the size of the selected-key set. ------------- PR: https://git.openjdk.java.net/jdk/pull/7220 From alanb at openjdk.java.net Wed Jan 26 10:23:34 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 26 Jan 2022 10:23:34 GMT Subject: RFR: 4750574: (se spec) Selector spec should clarify calculation of select return value In-Reply-To: References: Message-ID: On Wed, 26 Jan 2022 00:19:36 GMT, Brian Burkhalter wrote: > Improve the description of the return value of each of the `Selector.select()` methods which do not accept an action parameter. It requires careful reading but is accurate, so I think this is okay (esp. as this is an API for advanced users, not an API that most users would use directly). ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7220 From lancea at openjdk.java.net Wed Jan 26 11:25:33 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 26 Jan 2022 11:25:33 GMT Subject: RFR: 8280366: (fs) Restore Files.createTempFile javadoc [v2] In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 17:29:02 GMT, Brian Burkhalter wrote: >> This change reverts commit fb8fdc0fbf17dd7e900cb688df4917b97b26b9ab and then makes a smaller change to the verbiage of `Files.createTempFile `. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8280366: Revert to state prior to JDK-8279990 change modulo fixing a grammatical error This is Looks fine to get us back to where we started. I do think we need to revisit some of the questions that were asked about the original wording via a new PR ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7202 From bpb at openjdk.java.net Wed Jan 26 16:55:31 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 26 Jan 2022 16:55:31 GMT Subject: RFR: 4750574: (se spec) Selector spec should clarify calculation of select return value In-Reply-To: References: Message-ID: On Wed, 26 Jan 2022 10:20:29 GMT, Alan Bateman wrote: >> Improve the description of the return value of each of the `Selector.select()` methods which do not accept an action parameter. > > It requires careful reading but is accurate, so I think this is okay (esp. as this is an API for advanced users, not an API that most users would use directly). @AlanBateman What do you think of @dfuch's API note suggestion? ------------- PR: https://git.openjdk.java.net/jdk/pull/7220 From bpb at openjdk.java.net Wed Jan 26 19:03:31 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 26 Jan 2022 19:03:31 GMT Subject: RFR: 8280366: (fs) Restore Files.createTempFile javadoc [v2] In-Reply-To: References: Message-ID: <-RUCbbmIKVSiNySme2UoozybaaxnDVY6Di3AjU_sZ5Q=.bf3f4e9f-d3fc-4418-8d03-0fb71cf4c55d@github.com> On Tue, 25 Jan 2022 17:29:02 GMT, Brian Burkhalter wrote: >> This change reverts commit fb8fdc0fbf17dd7e900cb688df4917b97b26b9ab and then makes a smaller change to the verbiage of `Files.createTempFile `. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8280366: Revert to state prior to JDK-8279990 change modulo fixing a grammatical error Specifically, there is no definition of either _temporary-file facility_ or _work file_. ------------- PR: https://git.openjdk.java.net/jdk/pull/7202 From bpb at openjdk.java.net Thu Jan 27 21:05:15 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 27 Jan 2022 21:05:15 GMT Subject: Integrated: 8280366: (fs) Restore Files.createTempFile javadoc In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 18:47:45 GMT, Brian Burkhalter wrote: > This change reverts commit fb8fdc0fbf17dd7e900cb688df4917b97b26b9ab and then makes a smaller change to the verbiage of `Files.createTempFile `. This pull request has now been integrated. Changeset: ece89c6d Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/ece89c6df167e9a7f99b00e3f89c2c41c10ab31b Stats: 6 lines in 1 file changed: 2 ins; 1 del; 3 mod 8280366: (fs) Restore Files.createTempFile javadoc Reviewed-by: alanb, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/7202 From bpb at openjdk.java.net Thu Jan 27 22:19:37 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 27 Jan 2022 22:19:37 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues Message-ID: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Add an implementation note to `java.nio.channels.FileLock.overlaps(long,long)` indicating that the method does not check its parameters. Adding such checks would be an incompatible change. ------------- Commit messages: - 5041655: (ch) FileLock: negative param and overflow issues Changes: https://git.openjdk.java.net/jdk/pull/7254/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-5041655 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7254.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7254/head:pull/7254 PR: https://git.openjdk.java.net/jdk/pull/7254 From alanb at openjdk.java.net Fri Jan 28 05:55:15 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 28 Jan 2022 05:55:15 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues In-Reply-To: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Thu, 27 Jan 2022 22:12:32 GMT, Brian Burkhalter wrote: > Add an implementation note to `java.nio.channels.FileLock.overlaps(long,long)` indicating that the method does not check its parameters. Adding such checks would be an incompatible change. If the javadoc is changed to document long standing behavior then the change would need to be normative, I don't think an impl note works here. I agree that throwing IAE is not an option. However, maybe you could try this: 1. Return false if size is negative, such a region can't overlap with with the region of any file lock. 2. If position is negative then treat it an overlap request on (0, size + position). That would mean an overlap on the positive range. This part may not require any code changes btw, the existing check might over it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Fri Jan 28 17:16:15 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 28 Jan 2022 17:16:15 GMT Subject: Integrated: 4774868: (fc spec) Unclear spec for FileChannel.force In-Reply-To: References: Message-ID: <4WDYTM_hYo9hgKllTpGinYbGMa2OGaKB49sISI4PojY=.b0a12a98-2262-449b-91bc-1866291c940a@github.com> On Tue, 25 Jan 2022 02:12:38 GMT, Brian Burkhalter wrote: > Add verbiage to `FileChannel.force()` indicating that if the FileChannel is derived from a FileOutputStream or a RandomAccessFile using `getChannel()`, then any modifications made to the channel's file by methods invoked on the parent object will also be forced. This pull request has now been integrated. Changeset: 95ee9bf7 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/95ee9bf7be40572e768cf6213c03ca183b8ad886 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 4774868: (fc spec) Unclear spec for FileChannel.force Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7207 From bpb at openjdk.java.net Fri Jan 28 17:24:18 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 28 Jan 2022 17:24:18 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues In-Reply-To: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Thu, 27 Jan 2022 22:12:32 GMT, Brian Burkhalter wrote: > Add an implementation note to `java.nio.channels.FileLock.overlaps(long,long)` indicating that the method does not check its parameters. Adding such checks would be an incompatible change. 1. I thought through several possibilities, including `size < 0` implies `false` and using `Math.addExact()` with `position` and `size`. If `Math.addExact(position, size)` throws then the exception would be ignored. 2. I don't understand what you intend here. Was it instead maybe `overlaps(position, size)` for `position < 0` becomes `overlaps(0, size)`? ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From alanb at openjdk.java.net Fri Jan 28 20:16:09 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 28 Jan 2022 20:16:09 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues In-Reply-To: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Thu, 27 Jan 2022 22:12:32 GMT, Brian Burkhalter wrote: > Add an implementation note to `java.nio.channels.FileLock.overlaps(long,long)` indicating that the method does not check its parameters. Adding such checks would be an incompatible change. > * I thought through several possibilities, including `size < 0` implies `false` and using `Math.addExact()` with `position` and `size`. If `Math.addExact(position, size)` throws then the exception would be ignored. > * I don't understand what you intend here. Was it instead maybe `overlaps(position, size)` for `position < 0` becomes `overlaps(0, size)`? It might be that checking if size <= 0 is enough. Maybe the starting point for this issue is a series of test cases with negative positions and sizes. All tests that uses a negative size should return false. The tests that use a negative position may overlap with the locked region. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Fri Jan 28 20:38:27 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 28 Jan 2022 20:38:27 GMT Subject: RFR: 8280903: javadoc build fails after JDK-4774868 Message-ID: Prefix `java.io` to FOS and RAF links. ------------- Commit messages: - 8280903: javadoc build fails after JDK-4774868 Changes: https://git.openjdk.java.net/jdk/pull/7273/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7273&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280903 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7273.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7273/head:pull/7273 PR: https://git.openjdk.java.net/jdk/pull/7273 From dcubed at openjdk.java.net Fri Jan 28 20:42:10 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 28 Jan 2022 20:42:10 GMT Subject: RFR: 8280903: javadoc build fails after JDK-4774868 In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 20:30:57 GMT, Brian Burkhalter wrote: > Prefix `java.io` to FOS and RAF links. The fix does what is described. Of course, the only way to be sure is to execute the 'javadoc' build. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7273 From rriggs at openjdk.java.net Fri Jan 28 20:53:05 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 28 Jan 2022 20:53:05 GMT Subject: RFR: 8280903: javadoc build fails after JDK-4774868 In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 20:30:57 GMT, Brian Burkhalter wrote: > Prefix `java.io` to FOS and RAF links. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7273 From lancea at openjdk.java.net Fri Jan 28 20:59:10 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 28 Jan 2022 20:59:10 GMT Subject: RFR: 8280903: javadoc build fails after JDK-4774868 In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 20:30:57 GMT, Brian Burkhalter wrote: > Prefix `java.io` to FOS and RAF links. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7273 From bpb at openjdk.java.net Fri Jan 28 22:50:09 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 28 Jan 2022 22:50:09 GMT Subject: Withdrawn: 8280903: javadoc build fails after JDK-4774868 In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 20:30:57 GMT, Brian Burkhalter wrote: > Prefix `java.io` to FOS and RAF links. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7273 From bpb at openjdk.java.net Fri Jan 28 23:07:36 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 28 Jan 2022 23:07:36 GMT Subject: RFR: 8280903: javadoc build fails after JDK-4774868 Message-ID: Prefix `java.io` to FOS and RAF links. [(Redo of 7273](https://github.com/openjdk/jdk/pull/7273) whose branch was deleted before integrating). ------------- Commit messages: - 8280903: javadoc build fails after JDK-4774868 Changes: https://git.openjdk.java.net/jdk/pull/7277/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7277&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280903 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7277.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7277/head:pull/7277 PR: https://git.openjdk.java.net/jdk/pull/7277 From lancea at openjdk.java.net Fri Jan 28 23:17:06 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 28 Jan 2022 23:17:06 GMT Subject: RFR: 8280903: javadoc build fails after JDK-4774868 In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 23:00:41 GMT, Brian Burkhalter wrote: > Prefix `java.io` to FOS and RAF links. > [(Redo of 7273](https://github.com/openjdk/jdk/pull/7273) whose branch was deleted before integrating). Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7277 From bpb at openjdk.java.net Fri Jan 28 23:22:09 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 28 Jan 2022 23:22:09 GMT Subject: Integrated: 8280903: javadoc build fails after JDK-4774868 In-Reply-To: References: Message-ID: <2hnklFZVQLS_Cgr75Q6Ynen-5qLlQ_pBIPxporzPHbc=.520c24fc-f52e-4f06-a00a-402eaf1c9305@github.com> On Fri, 28 Jan 2022 23:00:41 GMT, Brian Burkhalter wrote: > Prefix `java.io` to FOS and RAF links. > [(Redo of 7273](https://github.com/openjdk/jdk/pull/7273) whose branch was deleted before integrating). This pull request has now been integrated. Changeset: d366d15d Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/d366d15d67a08833d93a5806edef8145cb7803e5 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8280903: javadoc build fails after JDK-4774868 Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/7277 From bpb at openjdk.java.net Sat Jan 29 04:11:09 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Sat, 29 Jan 2022 04:11:09 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues In-Reply-To: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: <3CPOmjNW6nqOjE9ZTLlr7DCWh-yEMB_AbM0aHWVAaUI=.f649cf65-5610-4934-8439-0d5bf0b58aab@github.com> On Thu, 27 Jan 2022 22:12:32 GMT, Brian Burkhalter wrote: > Add an implementation note to `java.nio.channels.FileLock.overlaps(long,long)` indicating that the method does not check its parameters. Adding such checks would be an incompatible change. Never mind about #2: I know what you mean. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Mon Jan 31 17:55:12 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 31 Jan 2022 17:55:12 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues In-Reply-To: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Thu, 27 Jan 2022 22:12:32 GMT, Brian Burkhalter wrote: > Add an implementation note to `java.nio.channels.FileLock.overlaps(long,long)` indicating that the method does not check its parameters. Adding such checks would be an incompatible change. I already wrote a test but it was not sufficiently cleaned up to include yet. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Mon Jan 31 19:53:11 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 31 Jan 2022 19:53:11 GMT Subject: RFR: 8274112: (fc) Tune FileChannel.transferTo() [v4] In-Reply-To: <1AR4tgaz1JdXutbQMh7FNoG0SHk1nHznl5H9n2Jzk3U=.545d612d-8eee-4290-8571-e5a9e18fe680@github.com> References: <1AR4tgaz1JdXutbQMh7FNoG0SHk1nHznl5H9n2Jzk3U=.545d612d-8eee-4290-8571-e5a9e18fe680@github.com> Message-ID: <-Qvv4_l6qk2F4NfM_uTVy1OndUv1y2iQw4tAWlmcbIE=.6ccadff4-98d1-4672-89a6-c771cb969882@github.com> On Mon, 25 Oct 2021 16:57:41 GMT, Brian Burkhalter wrote: >> Please consider this patch which would improve the performance of >> `FileChannel.transferTo()` on macOS and Windows. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8274112: Make transferTo0() static; remove check for null FileDescriptor continue ... ------------- PR: https://git.openjdk.java.net/jdk/pull/5623