From michaelm at openjdk.java.net Tue Feb 1 14:59:37 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Tue, 1 Feb 2022 14:59:37 GMT Subject: RFR: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism Message-ID: Hi, Could I get the following change reviewed please? 8280233 temporarily disabled AF_UNIX sockets in the windows pipe implementation due to a Windows bug. We would like to re-enable one internal usage of AF_UNIX pipes in the JDK, for the windows NIO selector notification mechanism since this use case does not involve closing the socket and should therefore not encounter the bug. I haven't included a regression test as this change will exercise tests that are currently running into TCP resource limitations on windows 10 client systems. Thanks, Michael ------------- Commit messages: - fixed whitespace - further update - update variable names - fixed problem - should build now - initial impl Changes: https://git.openjdk.java.net/jdk/pull/7302/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7302&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280944 Stats: 32 lines in 3 files changed: 19 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/7302.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7302/head:pull/7302 PR: https://git.openjdk.java.net/jdk/pull/7302 From dfuchs at openjdk.java.net Tue Feb 1 16:41:12 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 1 Feb 2022 16:41:12 GMT Subject: RFR: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism In-Reply-To: References: Message-ID: <0ucQbRxN-kr9-MtwWvDdXSJO5UjKwOFuCuCMsZbbIkM=.597f2d56-1798-4ade-812b-04e1f5e09784@github.com> On Tue, 1 Feb 2022 12:33:00 GMT, Michael McMahon wrote: > Hi, > > Could I get the following change reviewed please? > > 8280233 temporarily disabled AF_UNIX sockets in the windows pipe implementation due to a Windows bug. We would like to re-enable one internal usage of AF_UNIX pipes in the JDK, for the windows NIO selector notification mechanism since this use case does not involve closing the socket and should therefore not encounter the bug. > > I haven't included a regression test as this change will exercise tests that are currently running into TCP resource limitations on windows 10 client systems. > > Thanks, > Michael LGTM, but it would be good to have Brian B. or Alan have a look too. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7302 From alanb at openjdk.java.net Tue Feb 1 17:01:11 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 1 Feb 2022 17:01:11 GMT Subject: RFR: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism In-Reply-To: <0ucQbRxN-kr9-MtwWvDdXSJO5UjKwOFuCuCMsZbbIkM=.597f2d56-1798-4ade-812b-04e1f5e09784@github.com> References: <0ucQbRxN-kr9-MtwWvDdXSJO5UjKwOFuCuCMsZbbIkM=.597f2d56-1798-4ade-812b-04e1f5e09784@github.com> Message-ID: On Tue, 1 Feb 2022 16:38:18 GMT, Daniel Fuchs wrote: > LGTM, but it would be good to have Brian B. or Alan have a look too. I plan to review this. ------------- PR: https://git.openjdk.java.net/jdk/pull/7302 From alanb at openjdk.java.net Tue Feb 1 19:51:12 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 1 Feb 2022 19:51:12 GMT Subject: RFR: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 12:33:00 GMT, Michael McMahon wrote: > Hi, > > Could I get the following change reviewed please? > > 8280233 temporarily disabled AF_UNIX sockets in the windows pipe implementation due to a Windows bug. We would like to re-enable one internal usage of AF_UNIX pipes in the JDK, for the windows NIO selector notification mechanism since this use case does not involve closing the socket and should therefore not encounter the bug. > > I haven't included a regression test as this change will exercise tests that are currently running into TCP resource limitations on windows 10 client systems. > > Thanks, > Michael src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 37: > 35: import java.net.StandardSocketOptions; > 36: import java.net.UnixDomainSocketAddress; > 37: Spurious blank line here. src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 196: > 194: */ > 195: @SuppressWarnings("removal") > 196: PipeImpl(SelectorProvider sp, boolean buffering, boolean preferAfUnix) throws IOException { I think prefer AF_UNIX dominates, buffering is secondary, so I think the parameters should be reversed to make it clearer at the use-sites. src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 226: > 224: listener.bind(null); > 225: return listener; > 226: } catch (IOException | UnsupportedOperationException e) {} Is it possible for isSupported to return true and open throw UOE? ------------- PR: https://git.openjdk.java.net/jdk/pull/7302 From michaelm at openjdk.java.net Wed Feb 2 10:07:47 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 2 Feb 2022 10:07:47 GMT Subject: RFR: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism [v2] In-Reply-To: References: Message-ID: > Hi, > > Could I get the following change reviewed please? > > 8280233 temporarily disabled AF_UNIX sockets in the windows pipe implementation due to a Windows bug. We would like to re-enable one internal usage of AF_UNIX pipes in the JDK, for the windows NIO selector notification mechanism since this use case does not involve closing the socket and should therefore not encounter the bug. > > I haven't included a regression test as this change will exercise tests that are currently running into TCP resource limitations on windows 10 client systems. > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: after review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7302/files - new: https://git.openjdk.java.net/jdk/pull/7302/files/8f91d68c..2e5750c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7302&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7302&range=00-01 Stats: 9 lines in 3 files changed: 2 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7302.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7302/head:pull/7302 PR: https://git.openjdk.java.net/jdk/pull/7302 From michaelm at openjdk.java.net Wed Feb 2 10:07:48 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 2 Feb 2022 10:07:48 GMT Subject: RFR: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism [v2] In-Reply-To: References: Message-ID: <0N5OEaFJPqKEL1Kxz6IbO6vL8VNFQMVqQWCFlv9C2A0=.4dae31ce-36b0-4dca-8237-112051636a3d@github.com> On Tue, 1 Feb 2022 19:47:04 GMT, Alan Bateman wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> after review comments > > src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 226: > >> 224: listener.bind(null); >> 225: return listener; >> 226: } catch (IOException | UnsupportedOperationException e) {} > > Is it possible for isSupported to return true and open throw UOE? In practice no. I'll remove the UOE. ------------- PR: https://git.openjdk.java.net/jdk/pull/7302 From alanb at openjdk.java.net Wed Feb 2 11:46:04 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 2 Feb 2022 11:46:04 GMT Subject: RFR: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism [v2] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 10:07:47 GMT, Michael McMahon wrote: >> Hi, >> >> Could I get the following change reviewed please? >> >> 8280233 temporarily disabled AF_UNIX sockets in the windows pipe implementation due to a Windows bug. We would like to re-enable one internal usage of AF_UNIX pipes in the JDK, for the windows NIO selector notification mechanism since this use case does not involve closing the socket and should therefore not encounter the bug. >> >> I haven't included a regression test as this change will exercise tests that are currently running into TCP resource limitations on windows 10 client systems. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > after review comments src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 223: > 221: try { > 222: listener = ServerSocketChannel.open(UNIX); > 223: listener.bind(null); Updating version looks okay, I just wondering if bind can fail, in which case it would leak a socket. ------------- PR: https://git.openjdk.java.net/jdk/pull/7302 From michaelm at openjdk.java.net Wed Feb 2 12:02:07 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 2 Feb 2022 12:02:07 GMT Subject: RFR: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism [v2] In-Reply-To: <0N5OEaFJPqKEL1Kxz6IbO6vL8VNFQMVqQWCFlv9C2A0=.4dae31ce-36b0-4dca-8237-112051636a3d@github.com> References: <0N5OEaFJPqKEL1Kxz6IbO6vL8VNFQMVqQWCFlv9C2A0=.4dae31ce-36b0-4dca-8237-112051636a3d@github.com> Message-ID: On Wed, 2 Feb 2022 10:00:33 GMT, Michael McMahon wrote: >> src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 226: >> >>> 224: listener.bind(null); >>> 225: return listener; >>> 226: } catch (IOException | UnsupportedOperationException e) {} >> >> Is it possible for isSupported to return true and open throw UOE? > > In practice no. I'll remove the UOE. Actually, it turns out this is not the entirely true. isSupported can return true, but if the temp directory (where unnamed sockets are created) is set to a non-default filesystem, then UOE does get thrown. We have a test that does this. I'll have to put it back. ------------- PR: https://git.openjdk.java.net/jdk/pull/7302 From michaelm at openjdk.java.net Wed Feb 2 12:08:08 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 2 Feb 2022 12:08:08 GMT Subject: RFR: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism [v2] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 11:42:30 GMT, Alan Bateman wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> after review comments > > src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 223: > >> 221: try { >> 222: listener = ServerSocketChannel.open(UNIX); >> 223: listener.bind(null); > > Updating version looks okay, I just wondering if bind can fail, in which case it would leak a socket. bind would only fail if it can't find a random unique name in the temp directory. Probability low, but not zero. It doesn't cost much to check if listener != null and close it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7302 From michaelm at openjdk.java.net Wed Feb 2 12:12:36 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 2 Feb 2022 12:12:36 GMT Subject: RFR: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism [v3] In-Reply-To: References: Message-ID: > Hi, > > Could I get the following change reviewed please? > > 8280233 temporarily disabled AF_UNIX sockets in the windows pipe implementation due to a Windows bug. We would like to re-enable one internal usage of AF_UNIX pipes in the JDK, for the windows NIO selector notification mechanism since this use case does not involve closing the socket and should therefore not encounter the bug. > > I haven't included a regression test as this change will exercise tests that are currently running into TCP resource limitations on windows 10 client systems. > > Thanks, > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: second review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7302/files - new: https://git.openjdk.java.net/jdk/pull/7302/files/2e5750c2..a5edc6ce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7302&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7302&range=01-02 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7302.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7302/head:pull/7302 PR: https://git.openjdk.java.net/jdk/pull/7302 From alanb at openjdk.java.net Wed Feb 2 12:34:07 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 2 Feb 2022 12:34:07 GMT Subject: RFR: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism [v3] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 12:12:36 GMT, Michael McMahon wrote: >> Hi, >> >> Could I get the following change reviewed please? >> >> 8280233 temporarily disabled AF_UNIX sockets in the windows pipe implementation due to a Windows bug. We would like to re-enable one internal usage of AF_UNIX pipes in the JDK, for the windows NIO selector notification mechanism since this use case does not involve closing the socket and should therefore not encounter the bug. >> >> I haven't included a regression test as this change will exercise tests that are currently running into TCP resource limitations on windows 10 client systems. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > second review comments Thanks for the updates and the clarification that UOE is thrown when the default file system provider is not the built-in provider. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7302 From dfuchs at openjdk.java.net Wed Feb 2 13:06:05 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 2 Feb 2022 13:06:05 GMT Subject: RFR: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism [v3] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 12:12:36 GMT, Michael McMahon wrote: >> Hi, >> >> Could I get the following change reviewed please? >> >> 8280233 temporarily disabled AF_UNIX sockets in the windows pipe implementation due to a Windows bug. We would like to re-enable one internal usage of AF_UNIX pipes in the JDK, for the windows NIO selector notification mechanism since this use case does not involve closing the socket and should therefore not encounter the bug. >> >> I haven't included a regression test as this change will exercise tests that are currently running into TCP resource limitations on windows 10 client systems. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > second review comments Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7302 From michaelm at openjdk.java.net Wed Feb 2 15:08:09 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 2 Feb 2022 15:08:09 GMT Subject: Integrated: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism In-Reply-To: References: Message-ID: <5tMCrf-Z3BxItWd-1NYzUqsvu4lG2dirmaeF91x0Xok=.da8cf606-4ec0-480f-824c-766602b8daf5@github.com> On Tue, 1 Feb 2022 12:33:00 GMT, Michael McMahon wrote: > Hi, > > Could I get the following change reviewed please? > > 8280233 temporarily disabled AF_UNIX sockets in the windows pipe implementation due to a Windows bug. We would like to re-enable one internal usage of AF_UNIX pipes in the JDK, for the windows NIO selector notification mechanism since this use case does not involve closing the socket and should therefore not encounter the bug. > > I haven't included a regression test as this change will exercise tests that are currently running into TCP resource limitations on windows 10 client systems. > > Thanks, > Michael This pull request has now been integrated. Changeset: 87ab0994 Author: Michael McMahon URL: https://git.openjdk.java.net/jdk/commit/87ab0994ded3b535a160bb87b6540bd072042c44 Stats: 35 lines in 3 files changed: 22 ins; 1 del; 12 mod 8280944: Enable Unix domain sockets in Windows Selector notification mechanism Reviewed-by: dfuchs, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7302 From bpb at openjdk.java.net Wed Feb 2 18:46:09 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 2 Feb 2022 18:46:09 GMT Subject: RFR: 4750574: (se spec) Selector spec should clarify calculation of select return value In-Reply-To: <0Ou95IEz9TAZhnfWJaXw0nrx1ktx7qJMi0SV6rZL84s=.a4a1fcd5-ba41-4e91-8c84-326a433a7b25@github.com> References: <0Ou95IEz9TAZhnfWJaXw0nrx1ktx7qJMi0SV6rZL84s=.a4a1fcd5-ba41-4e91-8c84-326a433a7b25@github.com> Message-ID: On Wed, 26 Jan 2022 10:18:31 GMT, Daniel Fuchs 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. @dfuch Regarding the API note, maybe add an example snippet instead under a separate issue to be created? ------------- PR: https://git.openjdk.java.net/jdk/pull/7220 From daniel.fuchs at oracle.com Wed Feb 2 19:18:02 2022 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Feb 2022 19:18:02 +0000 Subject: RFR: 4750574: (se spec) Selector spec should clarify calculation of select return value In-Reply-To: References: <0Ou95IEz9TAZhnfWJaXw0nrx1ktx7qJMi0SV6rZL84s=.a4a1fcd5-ba41-4e91-8c84-326a433a7b25@github.com> Message-ID: <565e46d2-084a-e2db-d33b-2d3e83cd0bba@oracle.com> No problem with that Brian. Thanks! best regards, -- daniel On 02/02/2022 18:46, Brian Burkhalter wrote: > On Wed, 26 Jan 2022 10:18:31 GMT, Daniel Fuchs 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. > > @dfuch Regarding the API note, maybe add an example snippet instead under a separate issue to be created? > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/7220 From aturbanov at openjdk.java.net Thu Feb 3 10:37:39 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 3 Feb 2022 10:37:39 GMT Subject: RFR: 8280896: java/nio/file/Files/probeContentType/Basic.java fails on Windows 11 Message-ID: Amazon Corretto installer set this content type to Windows registry. ![???????????](https://user-images.githubusercontent.com/741251/152308738-58d790ea-167a-45c7-9e08-8d619c4f316d.png) ------------- Commit messages: - 8280896: java/nio/file/Files/probeContentType/Basic.java fails on Windows 11 Changes: https://git.openjdk.java.net/jdk/pull/7334/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7334&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280896 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7334.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7334/head:pull/7334 PR: https://git.openjdk.java.net/jdk/pull/7334 From bpb at openjdk.java.net Thu Feb 3 19:16:10 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 3 Feb 2022 19:16:10 GMT Subject: Integrated: 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. This pull request has now been integrated. Changeset: 130cf46d Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/130cf46dcb7b089fcf4a4e950cdc701513f7b53f Stats: 9 lines in 1 file changed: 3 ins; 0 del; 6 mod 4750574: (se spec) Selector spec should clarify calculation of select return value Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7220 From daniel.fuchs at oracle.com Fri Feb 4 17:25:00 2022 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 4 Feb 2022 17:25:00 +0000 Subject: Seeking inputs on 8224794: ZipFile/JarFile should open zip/JAR file with FILE_SHARE_DELETE sharing mode on Windows In-Reply-To: <352c3fdb-e6e6-d03c-cea5-91ad2309b3f2@gmail.com> References: <352c3fdb-e6e6-d03c-cea5-91ad2309b3f2@gmail.com> Message-ID: Hi Jaikiran, Thanks for working on this and apologies for the long silence. I believe your analysis of the issue is very valuable. Unless there is some clever trick we could do to allow to unlink the file from the file system before deleting it, so that the file path can be reused, it seems indeed that using FILE_SHARE_DELETE doesn't buy us much benefit. It is a pity, but IMO it was well worth the investigation. Unless others on this list disagree, or can suggest other tricks, I would suggest shelving this work for now. best regards, -- daniel On 18/12/2021 06:00, Jaikiran Pai wrote: > Would there be interest in moving this forward? Enabling that > FILE_SHARE_DELETE option has opened up some questions that I noted in my > previous mail below. So in order to move forward I would need some > inputs. If we don't want to do this at this time, I'll close the draft > PR that's currently open https://github.com/openjdk/jdk/pull/6477. > > -Jaikiran > From bpb at openjdk.java.net Sat Feb 5 00:17:46 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Sat, 5 Feb 2022 00:17:46 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v2] 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: > 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. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 5041655: Remove implNote; add special cases for negative and zero sizes; handle overflow; handle zero size on Windows; add test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7254/files - new: https://git.openjdk.java.net/jdk/pull/7254/files/39167237..f97a4125 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=00-01 Stats: 161 lines in 4 files changed: 143 ins; 2 del; 16 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 bpb at openjdk.java.net Sat Feb 5 00:23:10 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Sat, 5 Feb 2022 00:23:10 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v2] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Sat, 5 Feb 2022 00:17:46 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. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 5041655: Remove implNote; add special cases for negative and zero sizes; handle overflow; handle zero size on Windows; add test Updates in commit 01: 1. `FileChannel` `lock()` and `tryLock()` now indicate that a lock of size zero means lock to end of file. 2. The `FileLock` constructors now also state that size zero is to end of file. 3. `FileLock.overlaps()` was revised. 4. Windows native locking functions now recognize size zero as signifying an unbounded range. 5. A test was added. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From alanb at openjdk.java.net Sun Feb 6 16:49:07 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 6 Feb 2022 16:49:07 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v2] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Sat, 5 Feb 2022 00:17:46 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. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 5041655: Remove implNote; add special cases for negative and zero sizes; handle overflow; handle zero size on Windows; add test Changing the overlaps method to return false when size is negative is good. The updated range check that allows for the position to be negative looks good too. The compatibility impact should be negligible for this part. Changing the lock method to treat size==0 as Long.MAX_VALUE-position is the behavior on some platforms already and is implementable in a consistent way on all platforms. So on the surface it's probably the right thing to do. However as proposed, it creates a FileLock with size == 0 that will not overlap with any other lock. To work correctly, it will need to be "promoted" to Long.MAX_VALUE-position before creating the FileLock. That will allow you to drop the change to the native code from the patch. I have several comments on the javadoc changes but I think we need to get to agreement on size=0 first. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Tue Feb 8 18:07:07 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 8 Feb 2022 18:07:07 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v2] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Sat, 5 Feb 2022 00:17:46 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. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 5041655: Remove implNote; add special cases for negative and zero sizes; handle overflow; handle zero size on Windows; add test I don't understand your comments about `size == 0` in the second paragraph. The changes to `FileLock::overlaps` treat zero size as effectively infinite. The change to the Windows version of `FileDispatcherImpl.c` bring it functionally in line with the Unix version, although on Windows `size` has to be promoted whereas on Unix if it is `Long.MAX_VALUE` it is changed to zero in accord with `fcntl()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From alanb at openjdk.java.net Tue Feb 8 18:24:03 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Feb 2022 18:24:03 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v2] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Tue, 8 Feb 2022 18:04:03 GMT, Brian Burkhalter wrote: > The change to the Windows version of `FileDispatcherImpl.c` brings it functionally in line with the Unix version, although on Windows `size` has to be promoted whereas on Unix if it is `Long.MAX_VALUE` it is changed to zero in accord with `fcntl()`. With the proposal, fc.lock(pos, 0L, shared) returns a FileLock where size() returns 0L. Can you try having this create a FileLock that reports its size as Long.MAX_VALUE - pos ? That should eliminate the inconsistencies in the proposal and the native code changes will go away too. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Tue Feb 8 18:24:04 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 8 Feb 2022 18:24:04 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v2] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Sat, 5 Feb 2022 00:17:46 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. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 5041655: Remove implNote; add special cases for negative and zero sizes; handle overflow; handle zero size on Windows; add test I can change it as suggested. Note that the extant Unix version for size zero creates a lock where `size()` returns zero while in reality locking the whole file. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From alanb at openjdk.java.net Tue Feb 8 18:30:05 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Feb 2022 18:30:05 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v2] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: <-sTT7A8qwxPaKjRszOcrZOJ5p78qyol1vBq9SZAgZws=.fab125b6-bd35-4751-8807-2da7dafb7d1d@github.com> On Tue, 8 Feb 2022 18:20:51 GMT, Brian Burkhalter wrote: > Note that the extant Unix version for size zero creates a lock where `size()` returns zero while in reality locking the whole file. Right, so you end up with a FileLock that says it doesn't overlap with any other lock but it actually locks the region to the end of file. I think the inconsistencies will go if you promote 0 to MAX_VALUE-pos before create the FileLock object. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Tue Feb 8 18:35:11 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 8 Feb 2022 18:35:11 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v2] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Sat, 5 Feb 2022 00:17:46 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. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 5041655: Remove implNote; add special cases for negative and zero sizes; handle overflow; handle zero size on Windows; add test I think that `overlaps()` as-is would return `true` if the size were left at zero, but returning zero from `size()` does seem strange. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Tue Feb 8 19:24:11 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 8 Feb 2022 19:24:11 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v3] 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: <6iiVv2yHw7nCTDHxykw1EKSxt6BtLjGTtwEi0UM25iI=.786c6c96-ee93-4448-81dd-e0c6c3e071d5@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. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 5041655: Force zero size of Long.MAX_VALUE - position; revert Windows change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7254/files - new: https://git.openjdk.java.net/jdk/pull/7254/files/f97a4125..30ce90ce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=01-02 Stats: 43 lines in 2 files changed: 8 ins; 28 del; 7 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 bpb at openjdk.java.net Tue Feb 8 19:24:12 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 8 Feb 2022 19:24:12 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v2] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Sat, 5 Feb 2022 00:17:46 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. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 5041655: Remove implNote; add special cases for negative and zero sizes; handle overflow; handle zero size on Windows; add test Commit 02: suggested source changes made; javadoc not yet changed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From alanb at openjdk.java.net Tue Feb 8 20:02:09 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Feb 2022 20:02:09 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v2] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Tue, 8 Feb 2022 19:21:04 GMT, Brian Burkhalter wrote: > Commit 02: suggested source changes made; javadoc not yet changed. I think the change will be in FileChannelImpl.lock so that the same size is used to create the FileLock and passed through to the native dispatcher. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Tue Feb 8 20:12:05 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 8 Feb 2022 20:12:05 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v3] In-Reply-To: <6iiVv2yHw7nCTDHxykw1EKSxt6BtLjGTtwEi0UM25iI=.786c6c96-ee93-4448-81dd-e0c6c3e071d5@github.com> References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> <6iiVv2yHw7nCTDHxykw1EKSxt6BtLjGTtwEi0UM25iI=.786c6c96-ee93-4448-81dd-e0c6c3e071d5@github.com> Message-ID: <18QoY2tB0AhMTyIsU2oynnxA3W88l_ocUG1H3k2tB04=.307b0433-fafc-4528-97a5-0d6c475140f2@github.com> On Tue, 8 Feb 2022 19:24:11 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. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 5041655: Force zero size of Long.MAX_VALUE - position; revert Windows change Note that because of this code in the Unix `FileDispatcherImpl.c` setting `size` to `MAX_VALUE - position` is not quite the same as what is there now: fl.l_whence = SEEK_SET; if (size == (jlong)java_lang_Long_MAX_VALUE) { fl.l_len = (off64_t)0; } else { fl.l_len = (off64_t)size; } ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From alanb at openjdk.java.net Tue Feb 8 20:21:14 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Feb 2022 20:21:14 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v3] In-Reply-To: <18QoY2tB0AhMTyIsU2oynnxA3W88l_ocUG1H3k2tB04=.307b0433-fafc-4528-97a5-0d6c475140f2@github.com> References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> <6iiVv2yHw7nCTDHxykw1EKSxt6BtLjGTtwEi0UM25iI=.786c6c96-ee93-4448-81dd-e0c6c3e071d5@github.com> <18QoY2tB0AhMTyIsU2oynnxA3W88l_ocUG1H3k2tB04=.307b0433-fafc-4528-97a5-0d6c475140f2@github.com> Message-ID: On Tue, 8 Feb 2022 20:09:10 GMT, Brian Burkhalter wrote: > Note that because of this code in the Unix `FileDispatcherImpl.c` setting `size` to `MAX_VALUE - position` is not quite the same as what is there now: > > ``` > fl.l_whence = SEEK_SET; > if (size == (jlong)java_lang_Long_MAX_VALUE) { > fl.l_len = (off64_t)0; > } else { > fl.l_len = (off64_t)size; > } > ``` There should be no impact here. If someone calls fc.lock() then it's the equivalent of fc.lock(0, MAX_VALUE, false). The FileLock will be created with size=MAX_VALUE. The code above will just map it to 0 for the call to fcntl. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Wed Feb 9 02:01:38 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 9 Feb 2022 02:01:38 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v4] 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: > 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. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 5041655: Move size zero handling to file channel impl classes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7254/files - new: https://git.openjdk.java.net/jdk/pull/7254/files/30ce90ce..e5d88e23 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=02-03 Stats: 42 lines in 6 files changed: 17 ins; 7 del; 18 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 bpb at openjdk.java.net Wed Feb 9 02:57:46 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 9 Feb 2022 02:57:46 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v5] 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: > 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. 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: 5041655: Move size zero handling to file channel impl classes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7254/files - new: https://git.openjdk.java.net/jdk/pull/7254/files/e5d88e23..d1001cc6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 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 Wed Feb 9 14:21:17 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 9 Feb 2022 14:21:17 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v5] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Wed, 9 Feb 2022 02:57:46 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. > > 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: > > 5041655: Move size zero handling to file channel impl classes Thanks for the update, I think this change is on the right track now. For FileChannel.lock we'll need to come up with wording that perceivably describes the behavior for the size==0 case. The issue with phrases like "remainder of the file" is that file may be extended after locking. The update to the FileLock protected constructors will need attention too. Extending FileLock and calling the constructor with size==0 does align the proposed spec change. I think it will work if you drop "A value of zero indicates the remainder of the file" from the javadoc. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Wed Feb 9 23:58:43 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 9 Feb 2022 23:58:43 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v6] 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: > 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. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 5041655: Update spec of zero lock size in channels and remove from FileLock spec ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7254/files - new: https://git.openjdk.java.net/jdk/pull/7254/files/d1001cc6..1e124575 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=04-05 Stats: 21 lines in 3 files changed: 10 ins; 3 del; 8 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 jai.forums2013 at gmail.com Thu Feb 10 13:27:42 2022 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 10 Feb 2022 18:57:42 +0530 Subject: Seeking inputs on 8224794: ZipFile/JarFile should open zip/JAR file with FILE_SHARE_DELETE sharing mode on Windows In-Reply-To: References: <352c3fdb-e6e6-d03c-cea5-91ad2309b3f2@gmail.com> Message-ID: <0b20ce60-4d96-83e4-533f-5393e5cd759c@gmail.com> Thank you Daniel for your inputs. I'll stop any further investigation/work on this one and update the JBS issue with the details of the investigation so far. -Jaikiran On 04/02/22 10:55 pm, Daniel Fuchs wrote: > Hi Jaikiran, > > Thanks for working on this and apologies for the long silence. > > I believe your analysis of the issue is very valuable. > > Unless there is some clever trick we could do to allow to unlink > the file from the file system before deleting it, so that the file > path can be reused, it seems indeed that using FILE_SHARE_DELETE > doesn't buy us much benefit. > It is a pity, but IMO it was well worth the investigation. > > Unless others on this list disagree, or can suggest other tricks, > I would suggest shelving this work for now. > > best regards, > > -- daniel > > > On 18/12/2021 06:00, Jaikiran Pai wrote: >> Would there be interest in moving this forward? Enabling that >> FILE_SHARE_DELETE option has opened up some questions that I noted in >> my previous mail below. So in order to move forward I would need some >> inputs. If we don't want to do this at this time, I'll close the >> draft PR that's currently open https://github.com/openjdk/jdk/pull/6477. >> >> -Jaikiran >> > From alanb at openjdk.java.net Thu Feb 10 13:39:06 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 10 Feb 2022 13:39:06 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v6] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Wed, 9 Feb 2022 23:58:43 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. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 5041655: Update spec of zero lock size in channels and remove from FileLock spec src/java.base/share/classes/java/nio/channels/FileLock.java line 269: > 267: *

If {@code size} is negative, {@code false} is returned regardless > 268: * of the value of {@code position}. > 269: * This is okay but maybe it should move to the "@returns" description. The "@returns" description states the condition when true is returned. We could add "false if size is negative of the lock range does not overlap". Try it and see if it looks a bit better. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From alanb at openjdk.java.net Thu Feb 10 13:44:10 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 10 Feb 2022 13:44:10 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v6] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Wed, 9 Feb 2022 23:58:43 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. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 5041655: Update spec of zero lock size in channels and remove from FileLock spec src/java.base/share/classes/java/nio/channels/FileChannel.java line 1005: > 1003: * A value of zero means to lock all bytes from the specified > 1004: * starting position to the end of the file, regardless of whether > 1005: * the file is subsequently extended or truncated This looks okay but I think we will need to say something about the return FileLock object. It may be that we need to add text to the method description to say that a FileLock with size "Long.MAX_VALUE - position" is returning when called with a size of 0. What do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Thu Feb 10 19:36:13 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 10 Feb 2022 19:36:13 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v6] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Thu, 10 Feb 2022 13:41:01 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 5041655: Update spec of zero lock size in channels and remove from FileLock spec > > src/java.base/share/classes/java/nio/channels/FileChannel.java line 1005: > >> 1003: * A value of zero means to lock all bytes from the specified >> 1004: * starting position to the end of the file, regardless of whether >> 1005: * the file is subsequently extended or truncated > > This looks okay but I think we will need to say something about the return FileLock object. It may be that we need to add text to the method description to say that a FileLock with size "Long.MAX_VALUE - position" is returning when called with a size of 0. What do you think? I had wondered about adding that: - * Long#MAX_VALUE}. + * Long#MAX_VALUE}. If a lock is created with a valid {@code position} + * and a {@code size} parameter of zero, then a lock of size + * {@code Long.MAX_VALUE - position} is returned. > src/java.base/share/classes/java/nio/channels/FileLock.java line 269: > >> 267: *

If {@code size} is negative, {@code false} is returned regardless >> 268: * of the value of {@code position}. >> 269: * > > This is okay but maybe it should move to the "@returns" description. The "@returns" description states the condition when true is returned. We could add "false if size is negative of the lock range does not overlap". Try it and see if it looks a bit better. I think it does look better: - * @return {@code true} if, and only if, this lock and the given lock - * range overlap by at least one byte + * @return {@code true} if this lock and the given lock range overlap + * by at least one byte; {@code false} if {@code size} is + * negative or the lock range does not overlap this lock ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From alanb at openjdk.java.net Thu Feb 10 20:10:15 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 10 Feb 2022 20:10:15 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v6] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Thu, 10 Feb 2022 19:33:16 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/nio/channels/FileChannel.java line 1005: >> >>> 1003: * A value of zero means to lock all bytes from the specified >>> 1004: * starting position to the end of the file, regardless of whether >>> 1005: * the file is subsequently extended or truncated >> >> This looks okay but I think we will need to say something about the return FileLock object. It may be that we need to add text to the method description to say that a FileLock with size "Long.MAX_VALUE - position" is returning when called with a size of 0. What do you think? > > I had wondered about adding that: > > - * Long#MAX_VALUE}. > + * Long#MAX_VALUE}. If a lock is created with a valid {@code position} > + * and a {@code size} parameter of zero, then a lock of size > + * {@code Long.MAX_VALUE - position} is returned. Good. >> src/java.base/share/classes/java/nio/channels/FileLock.java line 269: >> >>> 267: *

If {@code size} is negative, {@code false} is returned regardless >>> 268: * of the value of {@code position}. >>> 269: * >> >> This is okay but maybe it should move to the "@returns" description. The "@returns" description states the condition when true is returned. We could add "false if size is negative of the lock range does not overlap". Try it and see if it looks a bit better. > > I think it does look better: > > - * @return {@code true} if, and only if, this lock and the given lock > - * range overlap by at least one byte > + * @return {@code true} if this lock and the given lock range overlap > + * by at least one byte; {@code false} if {@code size} is > + * negative or the lock range does not overlap this lock Good. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Thu Feb 10 21:01:03 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 10 Feb 2022 21:01:03 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v7] 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: > 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. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 5041655: Further refinement of zero size lock specification ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7254/files - new: https://git.openjdk.java.net/jdk/pull/7254/files/1e124575..8e0de59e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=05-06 Stats: 23 lines in 3 files changed: 11 ins; 3 del; 9 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 bpb at openjdk.java.net Thu Feb 10 21:14:08 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 10 Feb 2022 21:14:08 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v6] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Thu, 10 Feb 2022 19:59:49 GMT, Alan Bateman wrote: >> I had wondered about adding that: >> >> - * Long#MAX_VALUE}. >> + * Long#MAX_VALUE}. If a lock is created with a valid {@code position} >> + * and a {@code size} parameter of zero, then a lock of size >> + * {@code Long.MAX_VALUE - position} is returned. > > Good. Resolved in commit 8e0de59. >> I think it does look better: >> >> - * @return {@code true} if, and only if, this lock and the given lock >> - * range overlap by at least one byte >> + * @return {@code true} if this lock and the given lock range overlap >> + * by at least one byte; {@code false} if {@code size} is >> + * negative or the lock range does not overlap this lock > > Good. Resolved in commit 8e0de59. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Fri Feb 11 01:46:10 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 11 Feb 2022 01:46:10 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v7] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Thu, 10 Feb 2022 21:01:03 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. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 5041655: Further refinement of zero size lock specification In the Unix version of `Java_sun_nio_ch_FileDispatcherImpl_lock0()`, I wonder whether in this block if (size == (jlong)java_lang_Long_MAX_VALUE) { fl.l_len = (off64_t)0; } else { fl.l_len = (off64_t)size; } the check should be changed to if (pos + size == (jlong)java_lang_Long_MAX_VALUE) { Similar question for `release0()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Fri Feb 11 02:04:10 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 11 Feb 2022 02:04:10 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v7] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Thu, 10 Feb 2022 21:01:03 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. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 5041655: Further refinement of zero size lock specification CSR JDK-8281623 filed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From alanb at openjdk.java.net Fri Feb 11 10:25:11 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 11 Feb 2022 10:25:11 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v7] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: <5tfvqvjlSTB9h4Rw_EEYO0gQzsjIxbzzHyIkzxMJsdE=.9d9aae3e-966b-4b2c-9a94-d8f6e13ea949@github.com> On Thu, 10 Feb 2022 21:01:03 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. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 5041655: Further refinement of zero size lock specification src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java line 429: > 427: * {@link #lock(Object,CompletionHandler)} method simply locks a region > 428: * of size {@link Long#MAX_VALUE}. If a lock is created with a valid > 429: * {@code position} and a {@code size} parameter of zero, then a lock of I think we've got the javadoc change to a good place. One minor point is that "created with a valid position" may be a bit confusing as you can't create a lock with an invalid position. What would you think of "If the position is non-negative and the size is zero then a lock of size ...". ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Fri Feb 11 15:27:05 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 11 Feb 2022 15:27:05 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v7] In-Reply-To: <5tfvqvjlSTB9h4Rw_EEYO0gQzsjIxbzzHyIkzxMJsdE=.9d9aae3e-966b-4b2c-9a94-d8f6e13ea949@github.com> References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> <5tfvqvjlSTB9h4Rw_EEYO0gQzsjIxbzzHyIkzxMJsdE=.9d9aae3e-966b-4b2c-9a94-d8f6e13ea949@github.com> Message-ID: On Fri, 11 Feb 2022 10:22:15 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 5041655: Further refinement of zero size lock specification > > src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java line 429: > >> 427: * {@link #lock(Object,CompletionHandler)} method simply locks a region >> 428: * of size {@link Long#MAX_VALUE}. If a lock is created with a valid >> 429: * {@code position} and a {@code size} parameter of zero, then a lock of > > I think we've got the javadoc change to a good place. One minor point is that "created with a valid position" may be a bit confusing as you can't create a lock with an invalid position. What would you think of "If the position is non-negative and the size is zero then a lock of size ...". That would likely be better; will change. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Fri Feb 11 16:00:05 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 11 Feb 2022 16:00:05 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v7] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> <5tfvqvjlSTB9h4Rw_EEYO0gQzsjIxbzzHyIkzxMJsdE=.9d9aae3e-966b-4b2c-9a94-d8f6e13ea949@github.com> Message-ID: On Fri, 11 Feb 2022 15:24:09 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java line 429: >> >>> 427: * {@link #lock(Object,CompletionHandler)} method simply locks a region >>> 428: * of size {@link Long#MAX_VALUE}. If a lock is created with a valid >>> 429: * {@code position} and a {@code size} parameter of zero, then a lock of >> >> I think we've got the javadoc change to a good place. One minor point is that "created with a valid position" may be a bit confusing as you can't create a lock with an invalid position. What would you think of "If the position is non-negative and the size is zero then a lock of size ...". > > That would likely be better; will change. Fixed and CSR updated accordingly. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Fri Feb 11 16:00:04 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 11 Feb 2022 16:00:04 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v8] 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: > 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. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 5041655: Update description of when a lock is created with size Long.MAX_VALUE - position ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7254/files - new: https://git.openjdk.java.net/jdk/pull/7254/files/8e0de59e..d56daa9b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=06-07 Stats: 10 lines in 2 files changed: 0 ins; 1 del; 9 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 bpb at openjdk.java.net Fri Feb 11 18:33:56 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 11 Feb 2022 18:33:56 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v9] 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: > 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. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 5041655: Modify existing tests to verify that creating a lock with size zero yields size Long.MAX_VALUE - position ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7254/files - new: https://git.openjdk.java.net/jdk/pull/7254/files/d56daa9b..537525ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=07-08 Stats: 68 lines in 2 files changed: 49 ins; 3 del; 16 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 bpb at openjdk.java.net Fri Feb 11 21:25:04 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 11 Feb 2022 21:25:04 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v10] 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: > 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. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 5041655: Fix problem exposed by modified lock tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7254/files - new: https://git.openjdk.java.net/jdk/pull/7254/files/537525ea..f1e1dfa1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=08-09 Stats: 9 lines in 3 files changed: 4 ins; 0 del; 5 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 duke at openjdk.java.net Sat Feb 12 14:18:05 2022 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 12 Feb 2022 14:18:05 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 Please keep open, still worken in it. ------------- PR: https://git.openjdk.java.net/jdk/pull/6711 From duke at openjdk.java.net Sun Feb 13 07:58:16 2022 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 13 Feb 2022 07:58:16 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. I am still working on it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From bpb at openjdk.java.net Mon Feb 14 21:27:37 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 14 Feb 2022 21:27:37 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException Message-ID: Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate. ------------- Commit messages: - 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException Changes: https://git.openjdk.java.net/jdk/pull/7467/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7467&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280881 Stats: 112 lines in 8 files changed: 78 ins; 0 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/7467.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7467/head:pull/7467 PR: https://git.openjdk.java.net/jdk/pull/7467 From lancea at openjdk.java.net Mon Feb 14 22:03:04 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 14 Feb 2022 22:03:04 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 21:21:14 GMT, Brian Burkhalter wrote: > Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate. The changes look reasonable to throw an IOException vs the specific UnixException ------------- PR: https://git.openjdk.java.net/jdk/pull/7467 From jpai at openjdk.java.net Tue Feb 15 04:31:13 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Feb 2022 04:31:13 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 21:21:14 GMT, Brian Burkhalter wrote: > Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate. src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java line 438: > 436: UnixNativeDispatcher.close(dfd1); > 437: } catch (UnixException y) { > 438: x.addSuppressed(y); Hello Brian, I think, even after adding this as suppressed exception, this (suprressed) exception will be "lost" because at the end of this outer catch block there's this code: x.rethrowAsIOException(dir); and the implementation of `rethrowAsIOException` internally just creates a new exception instance (depending on the error code) but doesn't capture any suppressed exceptions from the original `x`. src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.java line 128: > 126: UnixNativeDispatcher.close(newdfd1); > 127: } catch (UnixException e) { > 128: x.addSuppressed(e); Same here with respect to suppressed exception and what happens at the end of this catch block with `x.rethrowAsIOException(file);` ------------- PR: https://git.openjdk.java.net/jdk/pull/7467 From jpai at openjdk.java.net Tue Feb 15 04:59:08 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Feb 2022 04:59:08 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 21:21:14 GMT, Brian Burkhalter wrote: > Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate. src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java line 139: > 137: close(fd); > 138: } catch (UnixException y) { > 139: y.rethrowAsIOException(file); Hello Brian, A few lines above this code in the finally block, there's a catch block which catches the `UnixException` and rethrows it as a `FileSystemException`. With the change being done in this finally block, this finally block now potentially can throw an `IOException` from a failed call to `close()` and thus the original `FileSystemException` can get lost. Do you think it would be better to keep track any potential `FileSystemException` from the previous catch block and add this `IOException` from this `close()` call as a suppressed exception to that `FileSystemException` and rethrow that original exception? Loosely, something like: IOException failure = null; try { .... } catch (UnixException x) { failure = new FileSystemException(file.getPathForExceptionMessage(), null, "Unable to get list of extended attributes: " + x.getMessage()); } finally { try { close(fd); } catch (UnixException y) { if (failure == null) { // throw the exception that happened during close y.rethrowAsIOException(file); } else { // add the failure to close as a suppressed exception to // the previously caught failure failure.addSuppressed(y.asIOException(file)); } } // throw any previously caught failure if (failure != null) { throw failure; } } This applies to few others places that have changed in this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7467 From jpai at openjdk.java.net Tue Feb 15 05:19:18 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Feb 2022 05:19:18 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException In-Reply-To: References: Message-ID: <-BhFUVnpM-LZXSr2Z7WbvGTgPvJMXEcTGCvgZ-xn8TA=.49d59463-abbb-4438-a642-ff46489b6eac@github.com> On Mon, 14 Feb 2022 21:21:14 GMT, Brian Burkhalter wrote: > Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate. Additionally the GitHub actions job on Linux system seems to have caught a few other places where the call to `close` now needs to catch the `UnixException`: 2022-02-14T21:24:09.6575143Z Compiling 3090 files for java.base 2022-02-14T21:24:37.0964078Z /home/runner/work/jdk/jdk/jdk/src/java.base/linux/classes/sun/nio/fs/LinuxDosFileAttributeView.java:185: error: unreported exception UnixException; must be caught or declared to be thrown 2022-02-14T21:24:37.0964759Z close(fd); 2022-02-14T21:24:37.0964944Z ^ 2022-02-14T21:24:37.0965316Z /home/runner/work/jdk/jdk/jdk/src/java.base/linux/classes/sun/nio/fs/LinuxDosFileAttributeView.java:280: error: unreported exception UnixException; must be caught or declared to be thrown 2022-02-14T21:24:37.0965679Z close(fd); 2022-02-14T21:24:37.0965857Z ^ 2022-02-14T21:24:37.0966014Z 2 errors ------------- PR: https://git.openjdk.java.net/jdk/pull/7467 From bpb at openjdk.java.net Tue Feb 15 17:26:03 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 15 Feb 2022 17:26:03 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException In-Reply-To: <-BhFUVnpM-LZXSr2Z7WbvGTgPvJMXEcTGCvgZ-xn8TA=.49d59463-abbb-4438-a642-ff46489b6eac@github.com> References: <-BhFUVnpM-LZXSr2Z7WbvGTgPvJMXEcTGCvgZ-xn8TA=.49d59463-abbb-4438-a642-ff46489b6eac@github.com> Message-ID: On Tue, 15 Feb 2022 05:15:44 GMT, Jaikiran Pai wrote: > Additionally the GitHub actions job on Linux system seems to have caught a few other places where the call to `close` now needs to catch the `UnixException`: Indeed I had not addressed Linux yet. ------------- PR: https://git.openjdk.java.net/jdk/pull/7467 From bpb at openjdk.java.net Tue Feb 15 18:05:11 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 15 Feb 2022 18:05:11 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 04:25:32 GMT, Jaikiran Pai wrote: >> Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate. > > src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java line 438: > >> 436: UnixNativeDispatcher.close(dfd1); >> 437: } catch (UnixException y) { >> 438: x.addSuppressed(y); > > Hello Brian, > I think, even after adding this as suppressed exception, this (suprressed) exception will be "lost" because at the end of this outer catch block there's this code: > > x.rethrowAsIOException(dir); > > and the implementation of `rethrowAsIOException` internally just creates a new exception instance (depending on the error code) but doesn't capture any suppressed exceptions from the original `x`. Good point. > src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.java line 128: > >> 126: UnixNativeDispatcher.close(newdfd1); >> 127: } catch (UnixException e) { >> 128: x.addSuppressed(e); > > Same here with respect to suppressed exception and what happens at the end of this catch block with `x.rethrowAsIOException(file);` Ditto. > src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java line 139: > >> 137: close(fd); >> 138: } catch (UnixException y) { >> 139: y.rethrowAsIOException(file); > > Hello Brian, > A few lines above this code in the finally block, there's a catch block which catches the `UnixException` and rethrows it as a `FileSystemException`. With the change being done in this finally block, this finally block now potentially can throw an `IOException` from a failed call to `close()` and thus the original `FileSystemException` can get lost. Do you think it would be better to keep track any potential `FileSystemException` from the previous catch block and add this `IOException` from this `close()` call as a suppressed exception to that `FileSystemException` and rethrow that original exception? Loosely, something like: > > > IOException failure = null; > try { > .... > > } catch (UnixException x) { > failure = new FileSystemException(file.getPathForExceptionMessage(), > null, "Unable to get list of extended attributes: " + > x.getMessage()); > } finally { > try { > close(fd); > } catch (UnixException y) { > if (failure == null) { > // throw the exception that happened during close > y.rethrowAsIOException(file); > } else { > // add the failure to close as a suppressed exception to > // the previously caught failure > failure.addSuppressed(y.asIOException(file)); > } > } > // throw any previously caught failure > if (failure != null) { > throw failure; > } > } > > > This applies to few others places that have changed in this PR. This might be a good idea. I think I need to revisit all the changes in this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/7467 From bpb at openjdk.java.net Wed Feb 16 00:44:37 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 16 Feb 2022 00:44:37 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException [v2] In-Reply-To: References: Message-ID: > Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8280881: Correct previous version; make Linux changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7467/files - new: https://git.openjdk.java.net/jdk/pull/7467/files/d185a8e1..0e7b72fb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7467&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7467&range=00-01 Stats: 77 lines in 8 files changed: 29 ins; 14 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/7467.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7467/head:pull/7467 PR: https://git.openjdk.java.net/jdk/pull/7467 From bpb at openjdk.java.net Wed Feb 16 00:56:12 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 16 Feb 2022 00:56:12 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException [v2] In-Reply-To: References: Message-ID: <7EEmQ_I1MhtISKpO0ZIzHfw30j8o90MQG9a_v8YktKc=.c14b0630-3661-4840-adf6-b877929c3b6a@github.com> On Tue, 15 Feb 2022 18:02:26 GMT, Brian Burkhalter wrote: >> src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java line 139: >> >>> 137: close(fd); >>> 138: } catch (UnixException y) { >>> 139: y.rethrowAsIOException(file); >> >> Hello Brian, >> A few lines above this code in the finally block, there's a catch block which catches the `UnixException` and rethrows it as a `FileSystemException`. With the change being done in this finally block, this finally block now potentially can throw an `IOException` from a failed call to `close()` and thus the original `FileSystemException` can get lost. Do you think it would be better to keep track any potential `FileSystemException` from the previous catch block and add this `IOException` from this `close()` call as a suppressed exception to that `FileSystemException` and rethrow that original exception? Loosely, something like: >> >> >> IOException failure = null; >> try { >> .... >> >> } catch (UnixException x) { >> failure = new FileSystemException(file.getPathForExceptionMessage(), >> null, "Unable to get list of extended attributes: " + >> x.getMessage()); >> } finally { >> try { >> close(fd); >> } catch (UnixException y) { >> if (failure == null) { >> // throw the exception that happened during close >> y.rethrowAsIOException(file); >> } else { >> // add the failure to close as a suppressed exception to >> // the previously caught failure >> failure.addSuppressed(y.asIOException(file)); >> } >> } >> // throw any previously caught failure >> if (failure != null) { >> throw failure; >> } >> } >> >> >> This applies to few others places that have changed in this PR. > > This might be a good idea. I think I need to revisit all the changes in this patch. In commit 0e7b72f I elected to do the following: 1. If `close()` throws a `UnixException` in a finally block, then it is ignored unless it can be ascertained that it would would _not_ mask an exception thrown in the try block, in which case it is rethrown as an `IOException`. 2. The `UnixException` is also ignored if the calling method does not throw `IOException`. 3. If the `UnixException` can be added as a suppressed exception to a preexisting `IOException` then that is done. 4. Otherwise if the `UnixException` can be rethrown as an `IOException` without masking another exception than that is done. ------------- PR: https://git.openjdk.java.net/jdk/pull/7467 From jpai at openjdk.java.net Thu Feb 17 04:05:03 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 17 Feb 2022 04:05:03 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException [v2] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 00:44:37 GMT, Brian Burkhalter wrote: >> Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8280881: Correct previous version; make Linux changes src/java.base/linux/classes/sun/nio/fs/LinuxWatchService.java line 308: > 306: UnixNativeDispatcher.close(socketpair[1]); > 307: UnixNativeDispatcher.close(ifd); > 308: } catch (UnixException ignore) { Hello Brian, Do you think it would be better for each of these `close` calls to have a try/catch/ignore block of its own? That way, for example, if the close for `socketpair[0]` fails, then we at least attempt closing the other open ones (`socketpair[1]` and `ifd`)? ------------- PR: https://git.openjdk.java.net/jdk/pull/7467 From jpai at openjdk.java.net Thu Feb 17 04:14:13 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 17 Feb 2022 04:14:13 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException [v2] In-Reply-To: <7EEmQ_I1MhtISKpO0ZIzHfw30j8o90MQG9a_v8YktKc=.c14b0630-3661-4840-adf6-b877929c3b6a@github.com> References: <7EEmQ_I1MhtISKpO0ZIzHfw30j8o90MQG9a_v8YktKc=.c14b0630-3661-4840-adf6-b877929c3b6a@github.com> Message-ID: On Wed, 16 Feb 2022 00:53:02 GMT, Brian Burkhalter wrote: >> This might be a good idea. I think I need to revisit all the changes in this patch. > > In commit 0e7b72f I elected to do the following: > > 1. If `close()` throws a `UnixException` in a finally block, then it is ignored unless it can be ascertained that it would would _not_ mask an exception thrown in the try block, in which case it is rethrown as an `IOException`. > 2. The `UnixException` is also ignored if the calling method does not throw `IOException`. > 3. If the `UnixException` can be added as a suppressed exception to a preexisting `IOException` then that is done. > 4. Otherwise if the `UnixException` can be rethrown as an `IOException` without masking another exception than that is done. Thank you for these changes, Brian. Overall these look fine to me. There's one part in this change which I'm unsure about given my lack of knowledge - the place where we throw an `IOException` depending on whether or not the operation is `done` or `complete`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7467 From jpai at openjdk.java.net Thu Feb 17 04:18:04 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 17 Feb 2022 04:18:04 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException [v2] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 00:44:37 GMT, Brian Burkhalter wrote: >> Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8280881: Correct previous version; make Linux changes src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 221: > 219: } catch (UnixException e) { > 220: if (done) > 221: e.rethrowAsIOException(target); Should we just ignore the exception irrespective of whether or not it is `done`? That I think would probably be a bit more consistent with some other places where we ignore exception from `close`. I think ignoring this instead of (conditionally) throwing this will also help propagate any previous raised exception, where a few lines above this `finally` block there's an "inner" try/catch which can potentially throw an `IOException` (line 211). ------------- PR: https://git.openjdk.java.net/jdk/pull/7467 From alanb at openjdk.java.net Thu Feb 17 13:28:10 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 17 Feb 2022 13:28:10 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v10] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Fri, 11 Feb 2022 21:25:04 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. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 5041655: Fix problem exposed by modified lock tests src/java.base/share/classes/java/nio/channels/FileLock.java line 286: > 284: // the sum of this.position and this.size overflows the range of > 285: // long hence their mathematical sum is greater than position > 286: } I think it would be a bit clearer if you move the comment "This is below that" to above the try as something "Test if this is below that". Same for the test to see if that is below this. src/java.base/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java line 184: > 182: throw new NonWritableChannelException(); > 183: > 184: long len = size != 0 ? size : Long.MAX_VALUE - Math.max(0, position); In other places, the changes just checks if size is 0 and set it to Long.MAX_VALUE - Math.max(0, position). This avoids having both "len" and "size" and avoids potential mistakes. Can we do the same here and in the Windows implementation? ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Thu Feb 17 16:53:05 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 17 Feb 2022 16:53:05 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v10] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Thu, 17 Feb 2022 13:23:37 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 5041655: Fix problem exposed by modified lock tests > > src/java.base/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java line 184: > >> 182: throw new NonWritableChannelException(); >> 183: >> 184: long len = size != 0 ? size : Long.MAX_VALUE - Math.max(0, position); > > In other places, the changes just checks if size is 0 and set it to Long.MAX_VALUE - Math.max(0, position). This avoids having both "len" and "size" and avoids potential mistakes. Can we do the same here and in the Windows implementation? In both cases the `size` parameter is final and cannot be reassigned, so either the parameter has to be made non-final or a new variable has to be used. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From bpb at openjdk.java.net Thu Feb 17 17:14:43 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 17 Feb 2022 17:14:43 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v11] 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: > 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. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 5041655: Move x is below y comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7254/files - new: https://git.openjdk.java.net/jdk/pull/7254/files/f1e1dfa1..ef5b46e8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=09-10 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 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 Feb 18 15:21:10 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Feb 2022 15:21:10 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v11] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Thu, 17 Feb 2022 17:14:43 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. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 5041655: Move x is below y comments Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From alanb at openjdk.java.net Fri Feb 18 15:21:12 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Feb 2022 15:21:12 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v10] In-Reply-To: References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com> Message-ID: On Thu, 17 Feb 2022 16:49:45 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java line 184: >> >>> 182: throw new NonWritableChannelException(); >>> 183: >>> 184: long len = size != 0 ? size : Long.MAX_VALUE - Math.max(0, position); >> >> In other places, the changes just checks if size is 0 and set it to Long.MAX_VALUE - Math.max(0, position). This avoids having both "len" and "size" and avoids potential mistakes. Can we do the same here and in the Windows implementation? > > In both cases the `size` parameter is final and cannot be reassigned, so either the parameter has to be made non-final or a new variable has to be used. Okay, I see it would be disruptive to do that. In that case, let's go with what you have (maybe put parentheses around the size != 0 condition in the ternary to make it a bit clearer). Overall I think we've got the two original corner cases to a good place with minimal-to-no impact. ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From alanb at openjdk.java.net Fri Feb 18 15:40:47 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Feb 2022 15:40:47 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException [v2] In-Reply-To: References: Message-ID: <-qVVvmja6lX5DfiL90t6FoV6VuyCvz6yGDz8VatccQc=.c487ea8b-3c74-49a5-b650-13504044764d@github.com> On Wed, 16 Feb 2022 00:44:37 GMT, Brian Burkhalter wrote: >> Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8280881: Correct previous version; make Linux changes One idea to try is to add: static void close(int fd, Function mapper) throws IOException That would eliminate the need to wrap close everywhere. It would replace them with code like: close(fd, e -> e.asIOException(source)); ------------- PR: https://git.openjdk.java.net/jdk/pull/7467 From bpb at openjdk.java.net Fri Feb 18 17:24:51 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 18 Feb 2022 17:24:51 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException [v2] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 00:44:37 GMT, Brian Burkhalter wrote: >> Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8280881: Correct previous version; make Linux changes So in finally blocks where throwing an `IOException` because of a `close()` failure would mask any exception thrown in the `try` block it would be close(fd, null); which would mean ignoring the `UnixException` of `close()`? ------------- PR: https://git.openjdk.java.net/jdk/pull/7467 From alanb at openjdk.java.net Fri Feb 18 17:28:53 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Feb 2022 17:28:53 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException [v2] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 17:21:40 GMT, Brian Burkhalter wrote: > So in finally blocks where throwing an `IOException` because of a `close()` failure would mask any exception thrown in the `try` block it would be > > ``` > close(fd, null); > ``` > > which would mean ignoring the `UnixException` of `close()`? close(fd, e -> null) should work for the cases where it's okay to ignore. The important cases to throw is when writing but most of the cases will be reading. ------------- PR: https://git.openjdk.java.net/jdk/pull/7467 From aturbanov at openjdk.java.net Fri Feb 18 20:14:28 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Fri, 18 Feb 2022 20:14:28 GMT Subject: RFR: 8282130: (bf) Remove unused ARRAY_BASE_OFFSET, ARRAY_INDEX_SCALE from read-only Heap Buffers Message-ID: IDEA noticed unused fields in ReadOnly Heap buffer classes: `HeapByteBufferR`, `HeapCharBufferR`, `HeapDoubleBufferR`, `HeapFloatBufferR`, `HeapIntBufferR`, `HeapLongBufferR`, `HeapShortBufferR`. ![???????????](https://user-images.githubusercontent.com/741251/154662464-1bfc7860-72f9-41bc-ad2a-35ba23b49011.png) ------------- Commit messages: - [PATCH] Adjust template to remove unused ARRAY_BASE_OFFSET/ARRAY_INDEX_SCALE fields from read-only ByteBuffer's - [PATCH] Adjust template to remove unused ARRAY_BASE_OFFSET/ARRAY_INDEX_SCALE fields from read-only ByteBuffer's Changes: https://git.openjdk.java.net/jdk/pull/7530/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7530&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282130 Stats: 6 lines in 1 file changed: 2 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7530.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7530/head:pull/7530 PR: https://git.openjdk.java.net/jdk/pull/7530 From bpb at openjdk.java.net Fri Feb 18 22:05:00 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 18 Feb 2022 22:05:00 GMT Subject: RFR: 8282130: (bf) Remove unused ARRAY_BASE_OFFSET, ARRAY_INDEX_SCALE from read-only Heap Buffers In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 10:11:42 GMT, Andrey Turbanov wrote: > IDEA noticed unused fields in ReadOnly Heap buffer classes: `HeapByteBufferR`, `HeapCharBufferR`, `HeapDoubleBufferR`, `HeapFloatBufferR`, `HeapIntBufferR`, `HeapLongBufferR`, `HeapShortBufferR`. > ![???????????](https://user-images.githubusercontent.com/741251/154662464-1bfc7860-72f9-41bc-ad2a-35ba23b49011.png) Looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7530 From bpb at openjdk.java.net Fri Feb 18 22:49:32 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 18 Feb 2022 22:49:32 GMT Subject: RFR: 5041655: (ch) FileLock: negative param and overflow issues [v12] 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: > 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. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 5041655: Add parentheses around boolean in ternary expression ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7254/files - new: https://git.openjdk.java.net/jdk/pull/7254/files/ef5b46e8..cbcdcf00 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7254&range=10-11 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 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 Sat Feb 19 08:04:51 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 19 Feb 2022 08:04:51 GMT Subject: RFR: 8282130: (bf) Remove unused ARRAY_BASE_OFFSET, ARRAY_INDEX_SCALE from read-only Heap Buffers In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 10:11:42 GMT, Andrey Turbanov wrote: > IDEA noticed unused fields in ReadOnly Heap buffer classes: `HeapByteBufferR`, `HeapCharBufferR`, `HeapDoubleBufferR`, `HeapFloatBufferR`, `HeapIntBufferR`, `HeapLongBufferR`, `HeapShortBufferR`. > ![???????????](https://user-images.githubusercontent.com/741251/154662464-1bfc7860-72f9-41bc-ad2a-35ba23b49011.png) Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7530 From aturbanov at openjdk.java.net Mon Feb 21 09:06:53 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 21 Feb 2022 09:06:53 GMT Subject: Integrated: 8282130: (bf) Remove unused ARRAY_BASE_OFFSET, ARRAY_INDEX_SCALE from read-only Heap Buffers In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 10:11:42 GMT, Andrey Turbanov wrote: > IDEA noticed unused fields in ReadOnly Heap buffer classes: `HeapByteBufferR`, `HeapCharBufferR`, `HeapDoubleBufferR`, `HeapFloatBufferR`, `HeapIntBufferR`, `HeapLongBufferR`, `HeapShortBufferR`. > ![???????????](https://user-images.githubusercontent.com/741251/154662464-1bfc7860-72f9-41bc-ad2a-35ba23b49011.png) This pull request has now been integrated. Changeset: 51f44207 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/51f4420711b8cace5733180b3291779f11291895 Stats: 6 lines in 1 file changed: 2 ins; 3 del; 1 mod 8282130: (bf) Remove unused ARRAY_BASE_OFFSET, ARRAY_INDEX_SCALE from read-only Heap Buffers Reviewed-by: bpb, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7530 From bpb at openjdk.java.net Tue Feb 22 17:28:54 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 22 Feb 2022 17:28:54 GMT Subject: Integrated: 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. This pull request has now been integrated. Changeset: 6445ee46 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/6445ee46b5c3d1a46f8154b6e867c25d495d76b1 Stats: 250 lines in 9 files changed: 205 ins; 3 del; 42 mod 5041655: (ch) FileLock: negative param and overflow issues Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7254 From duke at openjdk.java.net Tue Feb 22 22:44:50 2022 From: duke at openjdk.java.net (ExE Boss) Date: Tue, 22 Feb 2022 22:44:50 GMT Subject: RFR: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism [v3] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 12:12:36 GMT, Michael McMahon wrote: >> Hi, >> >> Could I get the following change reviewed please? >> >> 8280233 temporarily disabled AF_UNIX sockets in the windows pipe implementation due to a Windows bug. We would like to re-enable one internal usage of AF_UNIX pipes in the JDK, for the windows NIO selector notification mechanism since this use case does not involve closing the socket and should therefore not encounter the bug. >> >> I haven't included a regression test as this change will exercise tests that are currently running into TCP resource limitations on windows 10 client systems. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > second review comments src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 182: > 180: */ > 181: PipeImpl(SelectorProvider sp) throws IOException { > 182: this(sp, true, false); I?m?pretty?sure that?this?should actually?be: Suggestion: this(sp, /*AF_UNIX*/ false, /*buffering*/ true); ------------- PR: https://git.openjdk.java.net/jdk/pull/7302 From dfuchs at openjdk.java.net Wed Feb 23 10:14:53 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 23 Feb 2022 10:14:53 GMT Subject: RFR: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism [v3] In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 22:41:10 GMT, ExE Boss wrote: >> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: >> >> second review comments > > src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 182: > >> 180: */ >> 181: PipeImpl(SelectorProvider sp) throws IOException { >> 182: this(sp, true, false); > > I?m?pretty?sure that?this?should actually?be: > Suggestion: > > this(sp, /*AF_UNIX*/ false, /*buffering*/ true); Good catch. I will log a bug for that. In practice (and fortunately) it doesn't really matter since AFAICT this constructor is never called. ------------- PR: https://git.openjdk.java.net/jdk/pull/7302 From daniel.fuchs at oracle.com Wed Feb 23 10:26:44 2022 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 23 Feb 2022 10:26:44 +0000 Subject: RFR: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism [v3] In-Reply-To: References: Message-ID: <5b0bd588-14f5-3ca6-e3f9-9575d878b35d@oracle.com> On 23/02/2022 10:14, Daniel Fuchs wrote: > Good catch. I will log a bug for that. In practice (and fortunately) it doesn't really matter since AFAICT this constructor is never called. Correction: the constructor is called once in SelectorProviderImpl.java. Logged JDK-8282296 -- daniel From alanb at openjdk.java.net Wed Feb 23 10:31:50 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 23 Feb 2022 10:31:50 GMT Subject: RFR: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism [v3] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 10:11:16 GMT, Daniel Fuchs wrote: >> src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 182: >> >>> 180: */ >>> 181: PipeImpl(SelectorProvider sp) throws IOException { >>> 182: this(sp, true, false); >> >> I?m?pretty?sure that?this?should actually?be: >> Suggestion: >> >> this(sp, /*AF_UNIX*/ false, /*buffering*/ true); > > Good catch. I will log a bug for that. > Good catch. I will log a bug for that. In practice (and fortunately) it doesn't really matter since AFAICT this constructor is never called. The SelectorProvider's openPipe method creates the pipe implementation with the 1-arg constructor. The Selector creates the pipe for the wakeup mechanism with the 3-arg constructor. This PR is about the latter rather than the former. It is true that the comment in constructor description doesn't match the implementation but I read the comment from ExE-Boss to be asking for the openPipe to return an implementation that uses TCP sockets. ------------- PR: https://git.openjdk.java.net/jdk/pull/7302 From michaelm at openjdk.java.net Wed Feb 23 12:11:50 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 23 Feb 2022 12:11:50 GMT Subject: RFR: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism [v3] In-Reply-To: References: Message-ID: <6_hktCwwM6KbChBb8hItNxtv3UFiBdPyYXmrjKASF2M=.1d7a2522-8344-49aa-9da2-e62f0b3b0eab@github.com> On Wed, 2 Feb 2022 12:12:36 GMT, Michael McMahon wrote: >> Hi, >> >> Could I get the following change reviewed please? >> >> 8280233 temporarily disabled AF_UNIX sockets in the windows pipe implementation due to a Windows bug. We would like to re-enable one internal usage of AF_UNIX pipes in the JDK, for the windows NIO selector notification mechanism since this use case does not involve closing the socket and should therefore not encounter the bug. >> >> I haven't included a regression test as this change will exercise tests that are currently running into TCP resource limitations on windows 10 client systems. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > second review comments Right. The mistake is in the comment. It should say: "Creates an unbuffered Pipe implementation" rather than "Creates a Pipe implementation that supports buffering" I can fix that easily. Changing the default constructor to create a buffered socket would not work with AF_UNIX sockets as they don't have an equivalent to TCP_NODELAY ------------- PR: https://git.openjdk.java.net/jdk/pull/7302 From michaelm at openjdk.java.net Wed Feb 23 12:50:51 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 23 Feb 2022 12:50:51 GMT Subject: RFR: 8280944: Enable Unix domain sockets in Windows Selector notification mechanism [v3] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 12:12:36 GMT, Michael McMahon wrote: >> Hi, >> >> Could I get the following change reviewed please? >> >> 8280233 temporarily disabled AF_UNIX sockets in the windows pipe implementation due to a Windows bug. We would like to re-enable one internal usage of AF_UNIX pipes in the JDK, for the windows NIO selector notification mechanism since this use case does not involve closing the socket and should therefore not encounter the bug. >> >> I haven't included a regression test as this change will exercise tests that are currently running into TCP resource limitations on windows 10 client systems. >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > second review comments Sorry, my previous comment was wrong, which I deleted. Exe-Boss's comment is correct. The two booleans should be the other way round as the TCP based pipe socket should be buffered. We can discuss further on the PR for the new issue, if necessary. ------------- PR: https://git.openjdk.java.net/jdk/pull/7302 From michaelm at openjdk.java.net Wed Feb 23 17:45:06 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 23 Feb 2022 17:45:06 GMT Subject: RFR: 8282296: (se) Pipe.open() creates a Pipe implementation that uses Unix domain sockets (win) Message-ID: Hi, Can I get this small fix reviewed please. When JDK-8280944 was fixed, two boolean parameters were mixed up in the PipeImpl constructor resulting in AF_UNIX sockets being re-enabled for Windows pipes. Thanks, Michael. ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/7597/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7597&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282296 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7597.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7597/head:pull/7597 PR: https://git.openjdk.java.net/jdk/pull/7597 From dfuchs at openjdk.java.net Wed Feb 23 17:59:04 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 23 Feb 2022 17:59:04 GMT Subject: RFR: 8282296: (se) Pipe.open() creates a Pipe implementation that uses Unix domain sockets (win) In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 17:37:08 GMT, Michael McMahon wrote: > Hi, > > Can I get this small fix reviewed please. When JDK-8280944 was fixed, two boolean parameters were mixed up in the PipeImpl constructor resulting in AF_UNIX sockets being re-enabled for Windows pipes. > > Thanks, > Michael. Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7597 From lancea at openjdk.java.net Wed Feb 23 18:24:53 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 23 Feb 2022 18:24:53 GMT Subject: RFR: 8282296: (se) Pipe.open() creates a Pipe implementation that uses Unix domain sockets (win) In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 17:37:08 GMT, Michael McMahon wrote: > Hi, > > Can I get this small fix reviewed please. When JDK-8280944 was fixed, two boolean parameters were mixed up in the PipeImpl constructor resulting in AF_UNIX sockets being re-enabled for Windows pipes. > > Thanks, > Michael. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7597 From bpb at openjdk.java.net Wed Feb 23 18:32:49 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 23 Feb 2022 18:32:49 GMT Subject: RFR: 8282296: (se) Pipe.open() creates a Pipe implementation that uses Unix domain sockets (win) In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 17:37:08 GMT, Michael McMahon wrote: > Hi, > > Can I get this small fix reviewed please. When JDK-8280944 was fixed, two boolean parameters were mixed up in the PipeImpl constructor resulting in AF_UNIX sockets being re-enabled for Windows pipes. > > Thanks, > Michael. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7597 From michaelm at openjdk.java.net Wed Feb 23 20:06:51 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Wed, 23 Feb 2022 20:06:51 GMT Subject: Integrated: 8282296: (se) Pipe.open() creates a Pipe implementation that uses Unix domain sockets (win) In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 17:37:08 GMT, Michael McMahon wrote: > Hi, > > Can I get this small fix reviewed please. When JDK-8280944 was fixed, two boolean parameters were mixed up in the PipeImpl constructor resulting in AF_UNIX sockets being re-enabled for Windows pipes. > > Thanks, > Michael. This pull request has now been integrated. Changeset: e540e0a8 Author: Michael McMahon URL: https://git.openjdk.java.net/jdk/commit/e540e0a81b923cce8b2f2689e01703509a4df1de Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8282296: (se) Pipe.open() creates a Pipe implementation that uses Unix domain sockets (win) Reviewed-by: dfuchs, lancea, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/7597 From bpb at openjdk.java.net Thu Feb 24 02:33:46 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 24 Feb 2022 02:33:46 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException [v3] In-Reply-To: References: Message-ID: > Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8280881: Add close variants to UnixNativeDispatcher; clean up close use sites ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7467/files - new: https://git.openjdk.java.net/jdk/pull/7467/files/0e7b72fb..546ec82f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7467&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7467&range=01-02 Stats: 163 lines in 9 files changed: 44 ins; 85 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/7467.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7467/head:pull/7467 PR: https://git.openjdk.java.net/jdk/pull/7467 From bpb at openjdk.java.net Thu Feb 24 23:23:46 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 24 Feb 2022 23:23:46 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException [v4] In-Reply-To: References: Message-ID: <6KT8rGT7exnvE7pFv_U0RoAjQ4g-aN0jeJHudEl2vBE=.40268830-7add-4900-aa26-483c9df290c7@github.com> > Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8280881: s/close(fd,null)/close(fd, e-> null)/ ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7467/files - new: https://git.openjdk.java.net/jdk/pull/7467/files/546ec82f..205578d8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7467&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7467&range=02-03 Stats: 18 lines in 7 files changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/7467.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7467/head:pull/7467 PR: https://git.openjdk.java.net/jdk/pull/7467 From alanb at openjdk.java.net Fri Feb 25 15:48:54 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 25 Feb 2022 15:48:54 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException [v4] In-Reply-To: <6KT8rGT7exnvE7pFv_U0RoAjQ4g-aN0jeJHudEl2vBE=.40268830-7add-4900-aa26-483c9df290c7@github.com> References: <6KT8rGT7exnvE7pFv_U0RoAjQ4g-aN0jeJHudEl2vBE=.40268830-7add-4900-aa26-483c9df290c7@github.com> Message-ID: <4e4wW0K03yZdDdD6mHUtq5wa_GsdcOC2pSYmrZXFvXs=.ef4cf4b7-6e1a-4046-9edc-dab8548ff63e@github.com> On Thu, 24 Feb 2022 23:23:46 GMT, Brian Burkhalter wrote: >> Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8280881: s/close(fd,null)/close(fd, e-> null)/ This looks much cleaner but it may be a bit overboard in a few places where there is an exception and the cleanup has to close and also fails. src/java.base/linux/classes/sun/nio/fs/LinuxWatchService.java line 74: > 72: } catch (UnixException x) { > 73: throw UnixNativeDispatcher.close(ifd, > 74: new IOException(x.errorString()), y -> y.asIOException(null)); The most likely cause of socketpair failing here would be resources or out of file descriptors. When that happens then it's probably not interesting to also try to report the failure of inotify close. So I think this close can be close(ifd, e-> null) too. src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 189: > 187: if (sfd >= 0) { > 188: source.getFileSystem().copyNonPosixAttributes(sfd, dfd); > 189: close(sfd, x -> x.asIOException(source)); This is the source fd so it's reading. It's not wrong to have it throw IOException, just a bit consistent to the other places where the exception is ignored. src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java line 443: > 441: if (dfd2 != -1) { > 442: ioe = UnixNativeDispatcher.close(dfd2, ioe, > 443: z -> z.asIOException(dir)); It's not clear to me that the closing of dfd1 and dfd2 are interesting here, maybe they should be e -> null too. src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.java line 130: > 128: ioe = UnixNativeDispatcher.close(newdfd1, ioe, > 129: z -> z.asIOException(file)); > 130: } Same as UnixFileSystemProvider, I don't think the errors from closing newfd1 and newfd2 are useful here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7467 From bpb at openjdk.java.net Fri Feb 25 17:39:07 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 25 Feb 2022 17:39:07 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException [v5] In-Reply-To: References: Message-ID: > Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8280881: Suppress some uninteresting exceptions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7467/files - new: https://git.openjdk.java.net/jdk/pull/7467/files/205578d8..0d718f03 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7467&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7467&range=03-04 Stats: 18 lines in 4 files changed: 0 ins; 8 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7467.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7467/head:pull/7467 PR: https://git.openjdk.java.net/jdk/pull/7467 From alanb at openjdk.java.net Fri Feb 25 20:05:01 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 25 Feb 2022 20:05:01 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException [v5] In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 17:39:07 GMT, Brian Burkhalter wrote: >> Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8280881: Suppress some uninteresting exceptions I think it's improving but I think can be simplified. src/java.base/linux/classes/sun/nio/fs/LinuxWatchService.java line 74: > 72: } catch (UnixException x) { > 73: throw UnixNativeDispatcher.close(ifd, > 74: new IOException(x.errorString()), e -> null); If socketpair fails then I'm not sure it's worth trying to report the failure of ifd too. I think I would change this to close(ifd, e -> null) throw new IOException(x.errorString()); src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java line 441: > 439: if (dfd2 != -1) > 440: ioe = UnixNativeDispatcher.close(dfd2, ioe, e -> null); > 441: throw ioe; I think it would be simpler to just revert the change and just call close(dfd1, e -> null) and close(dfd2, e -> null). src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.java line 126: > 124: ioe = UnixNativeDispatcher.close(newdfd1, ioe, e -> null); > 125: if (newdfd2 != -1) > 126: ioe = UnixNativeDispatcher.close(newdfd1, ioe, e -> null); Same comment as UnixFileSystemProvider. ------------- PR: https://git.openjdk.java.net/jdk/pull/7467 From bpb at openjdk.java.net Fri Feb 25 21:26:37 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 25 Feb 2022 21:26:37 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException [v6] In-Reply-To: References: Message-ID: > Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8280881: Suppress some more exceptions; remove no longer needed close() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7467/files - new: https://git.openjdk.java.net/jdk/pull/7467/files/0d718f03..595bd975 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7467&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7467&range=04-05 Stats: 28 lines in 4 files changed: 0 ins; 22 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7467.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7467/head:pull/7467 PR: https://git.openjdk.java.net/jdk/pull/7467 From bpb at openjdk.java.net Fri Feb 25 23:38:12 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 25 Feb 2022 23:38:12 GMT Subject: RFR: 8267820: (fs) Files.copy should attempt to copy POSIX attributes when target file in custom file system Message-ID: In `java.nio.file.Files.copy()` copy POSIX attributes even if the target is from a different file system provided both the source and target file systems support such attributes. ------------- Commit messages: - 8267820: (fs) Files.copy should attempt to copy POSIX attributes when target file in custom file system Changes: https://git.openjdk.java.net/jdk/pull/7627/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7627&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267820 Stats: 68 lines in 5 files changed: 41 ins; 9 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/7627.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7627/head:pull/7627 PR: https://git.openjdk.java.net/jdk/pull/7627 From alanb at openjdk.java.net Sun Feb 27 18:04:48 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 27 Feb 2022 18:04:48 GMT Subject: RFR: 8267820: (fs) Files.copy should attempt to copy POSIX attributes when target file in custom file system In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 23:31:22 GMT, Brian Burkhalter wrote: > In `java.nio.file.Files.copy()` copy POSIX attributes even if the target is from a different file system provided both the source and target file systems support such attributes. src/java.base/share/classes/java/nio/file/CopyMoveHelper.java line 164: > 162: dstPosixView.setOwner(srcPosixAttrs.owner()); > 163: dstPosixView.setGroup(srcPosixAttrs.group()); > 164: } catch (ProviderMismatchException ignore) { I don't think setOwner/setGroup can work here. It may be possible to obtain a UserPrincipalLookupService from the target file system and use it to lookup the string representation of the source user/group but it may not be reliable. It's also likely that these setXXX will fail when the target file is on the default file system. Maybe it would be simpler to limit the copying to just POSIX file permissions. ------------- PR: https://git.openjdk.java.net/jdk/pull/7627 From alanb at openjdk.java.net Sun Feb 27 18:22:52 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 27 Feb 2022 18:22:52 GMT Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException [v6] In-Reply-To: References: Message-ID: <9huvL2cyJtQVAdlrnr--UjXLeQy-ITs5bf5e1me_uAw=.03b6e1db-7a8e-4dba-85a7-e6687f44d24f@github.com> On Fri, 25 Feb 2022 21:26:37 GMT, Brian Burkhalter wrote: >> Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8280881: Suppress some more exceptions; remove no longer needed close() This version is looking much better, just one issue in UnixCopyFile, the rest looks good. src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 189: > 187: if (sfd >= 0) { > 188: source.getFileSystem().copyNonPosixAttributes(sfd, dfd); > 189: close(sfd, null); This should be `close(sfd, e -> null);` ------------- PR: https://git.openjdk.java.net/jdk/pull/7467