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: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>

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: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
References: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
Message-ID: <0ucQbRxN-kr9-MtwWvDdXSJO5UjKwOFuCuCMsZbbIkM=.597f2d56-1798-4ade-812b-04e1f5e09784@github.com>

On Tue, 1 Feb 2022 12:33:00 GMT, Michael McMahon <michaelm at openjdk.org> 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: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
 <0ucQbRxN-kr9-MtwWvDdXSJO5UjKwOFuCuCMsZbbIkM=.597f2d56-1798-4ade-812b-04e1f5e09784@github.com>
Message-ID: <Y78LaaVmo25JpfhAM1Jjp-TIVhVdtip2fi9GFwB8W80=.7079c34e-dc7f-442d-8885-d82d4acf3c23@github.com>

On Tue, 1 Feb 2022 16:38:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> 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: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
References: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
Message-ID: <MUi9eYqPgKf5wo-k7tbwgCyDx-gL1v6yPCAZmOZY2Fc=.e14e9d3b-60c4-4b4e-928f-ae34e23e6285@github.com>

On Tue, 1 Feb 2022 12:33:00 GMT, Michael McMahon <michaelm at openjdk.org> 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: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
References: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
Message-ID: <yiQ2fCXdGqWLbBVZ3PWaoagVv4nUvrjoiyx1AAu8BM0=.7a189cdf-7d9c-4a99-8ccf-b751581e72bc@github.com>

> 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: <MUi9eYqPgKf5wo-k7tbwgCyDx-gL1v6yPCAZmOZY2Fc=.e14e9d3b-60c4-4b4e-928f-ae34e23e6285@github.com>
References: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
 <MUi9eYqPgKf5wo-k7tbwgCyDx-gL1v6yPCAZmOZY2Fc=.e14e9d3b-60c4-4b4e-928f-ae34e23e6285@github.com>
Message-ID: <0N5OEaFJPqKEL1Kxz6IbO6vL8VNFQMVqQWCFlv9C2A0=.4dae31ce-36b0-4dca-8237-112051636a3d@github.com>

On Tue, 1 Feb 2022 19:47:04 GMT, Alan Bateman <alanb at openjdk.org> 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: <yiQ2fCXdGqWLbBVZ3PWaoagVv4nUvrjoiyx1AAu8BM0=.7a189cdf-7d9c-4a99-8ccf-b751581e72bc@github.com>
References: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
 <yiQ2fCXdGqWLbBVZ3PWaoagVv4nUvrjoiyx1AAu8BM0=.7a189cdf-7d9c-4a99-8ccf-b751581e72bc@github.com>
Message-ID: <L0AMrb7pGgWgRSErz-JxRuKHwkWs5ajpVZk6Ky0eqbw=.f9b9b704-2c39-45a5-823f-9dab589399e3@github.com>

On Wed, 2 Feb 2022 10:07:47 GMT, Michael McMahon <michaelm at openjdk.org> 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: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
 <MUi9eYqPgKf5wo-k7tbwgCyDx-gL1v6yPCAZmOZY2Fc=.e14e9d3b-60c4-4b4e-928f-ae34e23e6285@github.com>
 <0N5OEaFJPqKEL1Kxz6IbO6vL8VNFQMVqQWCFlv9C2A0=.4dae31ce-36b0-4dca-8237-112051636a3d@github.com>
Message-ID: <PjLC9tr0dLUZ98QkIuNyNeuYrEy_El6FwCJzzpJQ_bI=.a84579de-da7e-42ea-b9fc-e2ed8a710e35@github.com>

On Wed, 2 Feb 2022 10:00:33 GMT, Michael McMahon <michaelm at openjdk.org> 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: <L0AMrb7pGgWgRSErz-JxRuKHwkWs5ajpVZk6Ky0eqbw=.f9b9b704-2c39-45a5-823f-9dab589399e3@github.com>
References: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
 <yiQ2fCXdGqWLbBVZ3PWaoagVv4nUvrjoiyx1AAu8BM0=.7a189cdf-7d9c-4a99-8ccf-b751581e72bc@github.com>
 <L0AMrb7pGgWgRSErz-JxRuKHwkWs5ajpVZk6Ky0eqbw=.f9b9b704-2c39-45a5-823f-9dab589399e3@github.com>
Message-ID: <eOdLh94NyG3bBVPE1j0TJscgrEpJUk0a-3Wfa4fPZ-E=.5587804c-b498-4976-a6e6-9179c887cad6@github.com>

On Wed, 2 Feb 2022 11:42:30 GMT, Alan Bateman <alanb at openjdk.org> 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: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
References: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
Message-ID: <tnYS7TVasktzxu3aJcStPe0svkIpk18UrF1BVi0Dfrs=.4abc4d07-ff23-417c-84a0-5984b631a94d@github.com>

> 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: <tnYS7TVasktzxu3aJcStPe0svkIpk18UrF1BVi0Dfrs=.4abc4d07-ff23-417c-84a0-5984b631a94d@github.com>
References: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
 <tnYS7TVasktzxu3aJcStPe0svkIpk18UrF1BVi0Dfrs=.4abc4d07-ff23-417c-84a0-5984b631a94d@github.com>
Message-ID: <s3JC4NbHZL9bSZnHH58pBs8Lvy2yY2Vene5hxDER1GM=.6edc0dcd-786e-4403-be6e-15aa44d3a9b6@github.com>

On Wed, 2 Feb 2022 12:12:36 GMT, Michael McMahon <michaelm at openjdk.org> 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: <tnYS7TVasktzxu3aJcStPe0svkIpk18UrF1BVi0Dfrs=.4abc4d07-ff23-417c-84a0-5984b631a94d@github.com>
References: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
 <tnYS7TVasktzxu3aJcStPe0svkIpk18UrF1BVi0Dfrs=.4abc4d07-ff23-417c-84a0-5984b631a94d@github.com>
Message-ID: <DD_vwWSrviYKoN5JsMiX7KCLh459YjaGiU-xR6HCktQ=.ede3d9bc-76ca-4cc3-9c00-3c42147dcd3c@github.com>

On Wed, 2 Feb 2022 12:12:36 GMT, Michael McMahon <michaelm at openjdk.org> 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: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
References: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
Message-ID: <5tMCrf-Z3BxItWd-1NYzUqsvu4lG2dirmaeF91x0Xok=.da8cf606-4ec0-480f-824c-766602b8daf5@github.com>

On Tue, 1 Feb 2022 12:33:00 GMT, Michael McMahon <michaelm at openjdk.org> 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 <michaelm at openjdk.org>
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: <BfacMonyISy3tZRfhW0r6WPG9WIyqwDTeKY23LmZoso=.3df69aa2-104f-4eef-9152-e38190dee010@github.com>
 <0Ou95IEz9TAZhnfWJaXw0nrx1ktx7qJMi0SV6rZL84s=.a4a1fcd5-ba41-4e91-8c84-326a433a7b25@github.com>
Message-ID: <ovbAVHMMh_ThUmEPgdRNScUbqLExgL3ghhe0t6m2RKs=.22939ce4-8942-45bf-8af8-7d2c2a3f20ce@github.com>

On Wed, 26 Jan 2022 10:18:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> 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: <ovbAVHMMh_ThUmEPgdRNScUbqLExgL3ghhe0t6m2RKs=.22939ce4-8942-45bf-8af8-7d2c2a3f20ce@github.com>
References: <BfacMonyISy3tZRfhW0r6WPG9WIyqwDTeKY23LmZoso=.3df69aa2-104f-4eef-9152-e38190dee010@github.com>
 <0Ou95IEz9TAZhnfWJaXw0nrx1ktx7qJMi0SV6rZL84s=.a4a1fcd5-ba41-4e91-8c84-326a433a7b25@github.com>
 <ovbAVHMMh_ThUmEPgdRNScUbqLExgL3ghhe0t6m2RKs=.22939ce4-8942-45bf-8af8-7d2c2a3f20ce@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 <dfuchs at openjdk.org> 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: <O4DOw_7AWeIP4yDuQwYlcGBqWfwE_TfJM9iwN30NqmQ=.00280591-1bad-4739-8c39-298002a6a7e9@github.com>

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: <BfacMonyISy3tZRfhW0r6WPG9WIyqwDTeKY23LmZoso=.3df69aa2-104f-4eef-9152-e38190dee010@github.com>
References: <BfacMonyISy3tZRfhW0r6WPG9WIyqwDTeKY23LmZoso=.3df69aa2-104f-4eef-9152-e38190dee010@github.com>
Message-ID: <msU6rWyslPd_yTpvs0pyrnh75eouTGeoeYBCFyIONUo=.7fe8c181-a22f-4e16-997f-0405d6533b25@github.com>

On Wed, 26 Jan 2022 00:19:36 GMT, Brian Burkhalter <bpb at openjdk.org> 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 <bpb at openjdk.org>
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: <e6527894-d274-f573-a2f4-ca4542430ebe@gmail.com>
 <352c3fdb-e6e6-d03c-cea5-91ad2309b3f2@gmail.com>
Message-ID: <b099340e-2796-3782-cef8-cf1829da84fd@oracle.com>

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: <v0hjPwtLcTAImnBq9SgwwPzsmkzU-mG8-lbyZqF8Njg=.f05f731c-6474-46db-a4ca-2f3fd508798c@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: 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: <v0hjPwtLcTAImnBq9SgwwPzsmkzU-mG8-lbyZqF8Njg=.f05f731c-6474-46db-a4ca-2f3fd508798c@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <v0hjPwtLcTAImnBq9SgwwPzsmkzU-mG8-lbyZqF8Njg=.f05f731c-6474-46db-a4ca-2f3fd508798c@github.com>
Message-ID: <yQMFbuEDzzfJf-1MHgku0ElE4tmwnkj-imKu88EeKb8=.125f09ff-0afb-4095-a4c8-2f3197c58a59@github.com>

On Sat, 5 Feb 2022 00:17:46 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <v0hjPwtLcTAImnBq9SgwwPzsmkzU-mG8-lbyZqF8Njg=.f05f731c-6474-46db-a4ca-2f3fd508798c@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <v0hjPwtLcTAImnBq9SgwwPzsmkzU-mG8-lbyZqF8Njg=.f05f731c-6474-46db-a4ca-2f3fd508798c@github.com>
Message-ID: <ZpeElq3U28BQNXE-7H5l9RUUqDHCsTypXU48lAQsOmk=.3c51eca3-4b34-4f79-808b-e9a697d78218@github.com>

On Sat, 5 Feb 2022 00:17:46 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <v0hjPwtLcTAImnBq9SgwwPzsmkzU-mG8-lbyZqF8Njg=.f05f731c-6474-46db-a4ca-2f3fd508798c@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <v0hjPwtLcTAImnBq9SgwwPzsmkzU-mG8-lbyZqF8Njg=.f05f731c-6474-46db-a4ca-2f3fd508798c@github.com>
Message-ID: <Vf09Fla7yWkzIHU_oz1HJyr8SJKPVeELq2uZLo7ZW4w=.d0e7d022-432f-4020-913d-1b29b0947b54@github.com>

On Sat, 5 Feb 2022 00:17:46 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <Vf09Fla7yWkzIHU_oz1HJyr8SJKPVeELq2uZLo7ZW4w=.d0e7d022-432f-4020-913d-1b29b0947b54@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <v0hjPwtLcTAImnBq9SgwwPzsmkzU-mG8-lbyZqF8Njg=.f05f731c-6474-46db-a4ca-2f3fd508798c@github.com>
 <Vf09Fla7yWkzIHU_oz1HJyr8SJKPVeELq2uZLo7ZW4w=.d0e7d022-432f-4020-913d-1b29b0947b54@github.com>
Message-ID: <VscB9_ho2cwMui1exM1y98WB2xv5kTrxJXEDKEDaFXA=.0667129e-8e9f-4f21-a606-378a0960b0df@github.com>

On Tue, 8 Feb 2022 18:04:03 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <v0hjPwtLcTAImnBq9SgwwPzsmkzU-mG8-lbyZqF8Njg=.f05f731c-6474-46db-a4ca-2f3fd508798c@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <v0hjPwtLcTAImnBq9SgwwPzsmkzU-mG8-lbyZqF8Njg=.f05f731c-6474-46db-a4ca-2f3fd508798c@github.com>
Message-ID: <q5ySvfyGsU4danmjOPSzBs6NMCkDyPBbG4465msyPt0=.bd8a16d5-15a7-4159-a115-a89e425db173@github.com>

On Sat, 5 Feb 2022 00:17:46 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <q5ySvfyGsU4danmjOPSzBs6NMCkDyPBbG4465msyPt0=.bd8a16d5-15a7-4159-a115-a89e425db173@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <v0hjPwtLcTAImnBq9SgwwPzsmkzU-mG8-lbyZqF8Njg=.f05f731c-6474-46db-a4ca-2f3fd508798c@github.com>
 <q5ySvfyGsU4danmjOPSzBs6NMCkDyPBbG4465msyPt0=.bd8a16d5-15a7-4159-a115-a89e425db173@github.com>
Message-ID: <-sTT7A8qwxPaKjRszOcrZOJ5p78qyol1vBq9SZAgZws=.fab125b6-bd35-4751-8807-2da7dafb7d1d@github.com>

On Tue, 8 Feb 2022 18:20:51 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <v0hjPwtLcTAImnBq9SgwwPzsmkzU-mG8-lbyZqF8Njg=.f05f731c-6474-46db-a4ca-2f3fd508798c@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <v0hjPwtLcTAImnBq9SgwwPzsmkzU-mG8-lbyZqF8Njg=.f05f731c-6474-46db-a4ca-2f3fd508798c@github.com>
Message-ID: <FMEhC2d8trMzdIoSgkaWoFILl0h9CWOXKGfRPJXc3XU=.c9bc6f39-4c17-4d09-b90b-2b3a503cf9f2@github.com>

On Sat, 5 Feb 2022 00:17:46 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <v0hjPwtLcTAImnBq9SgwwPzsmkzU-mG8-lbyZqF8Njg=.f05f731c-6474-46db-a4ca-2f3fd508798c@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <v0hjPwtLcTAImnBq9SgwwPzsmkzU-mG8-lbyZqF8Njg=.f05f731c-6474-46db-a4ca-2f3fd508798c@github.com>
Message-ID: <vGbbEY_2aKFNTFx6uJ7RmSiOspFGcyLL581H80the4w=.395fc012-3bea-4b66-bc50-8ba840d46cb8@github.com>

On Sat, 5 Feb 2022 00:17:46 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <vGbbEY_2aKFNTFx6uJ7RmSiOspFGcyLL581H80the4w=.395fc012-3bea-4b66-bc50-8ba840d46cb8@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <v0hjPwtLcTAImnBq9SgwwPzsmkzU-mG8-lbyZqF8Njg=.f05f731c-6474-46db-a4ca-2f3fd508798c@github.com>
 <vGbbEY_2aKFNTFx6uJ7RmSiOspFGcyLL581H80the4w=.395fc012-3bea-4b66-bc50-8ba840d46cb8@github.com>
Message-ID: <HAuoFC-Ill2piEOR3oO023UDGPxlAIk1teRAOX-nGj0=.f1745d77-1870-42d3-b346-036e960442a1@github.com>

On Tue, 8 Feb 2022 19:21:04 GMT, Brian Burkhalter <bpb at openjdk.org> 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 <bpb at openjdk.org> 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: <cj3v_YOwYaYJ2orDT-mjYge9JTfbjubWQnsq3bTSUdU=.8efd987c-acb6-43fb-91ca-87aeb35a5dbe@github.com>

On Tue, 8 Feb 2022 20:09:10 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <DOaC0l5ltxT6T54fZHjG9dA-yShOvGPdG1Emv1R8-EI=.8cf40154-679b-43cd-bfe6-292ce29d38ba@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: 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: <wN43qVKWFfRznIjmU_0cVnHqjSigHIbt0MOBf63Hg4Q=.e7ce1858-5b1e-441c-af2c-3f39a7739668@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 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: <wN43qVKWFfRznIjmU_0cVnHqjSigHIbt0MOBf63Hg4Q=.e7ce1858-5b1e-441c-af2c-3f39a7739668@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <wN43qVKWFfRznIjmU_0cVnHqjSigHIbt0MOBf63Hg4Q=.e7ce1858-5b1e-441c-af2c-3f39a7739668@github.com>
Message-ID: <NHc3kHnLXix1EVAWwxF7QeNQD_ojyv-Nd2-18xhZmz4=.56ec80d3-3739-423b-98a7-0e1d22cf054c@github.com>

On Wed, 9 Feb 2022 02:57:46 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <SN6JAvfKAcRlPMFgh8AJHETIj_Vln0LI3jKDzQbTNHw=.6cb5f902-c43d-4b0f-a6c5-8ecd9bb0a5e1@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: 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: <b099340e-2796-3782-cef8-cf1829da84fd@oracle.com>
References: <e6527894-d274-f573-a2f4-ca4542430ebe@gmail.com>
 <352c3fdb-e6e6-d03c-cea5-91ad2309b3f2@gmail.com>
 <b099340e-2796-3782-cef8-cf1829da84fd@oracle.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: <SN6JAvfKAcRlPMFgh8AJHETIj_Vln0LI3jKDzQbTNHw=.6cb5f902-c43d-4b0f-a6c5-8ecd9bb0a5e1@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <SN6JAvfKAcRlPMFgh8AJHETIj_Vln0LI3jKDzQbTNHw=.6cb5f902-c43d-4b0f-a6c5-8ecd9bb0a5e1@github.com>
Message-ID: <Jjyeu6P9iELycb2jzWWz4eKkc-F2dm3--VoMquAi3TI=.13d654c6-2aaf-4126-b1ef-072a45d36e9f@github.com>

On Wed, 9 Feb 2022 23:58:43 GMT, Brian Burkhalter <bpb at openjdk.org> 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:      * <p> 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: <SN6JAvfKAcRlPMFgh8AJHETIj_Vln0LI3jKDzQbTNHw=.6cb5f902-c43d-4b0f-a6c5-8ecd9bb0a5e1@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <SN6JAvfKAcRlPMFgh8AJHETIj_Vln0LI3jKDzQbTNHw=.6cb5f902-c43d-4b0f-a6c5-8ecd9bb0a5e1@github.com>
Message-ID: <ZpZU_qZpCB_ii42Jh9LLGRNA6bxEtzV_tZYik_rpDd0=.a592c547-f7ef-4f55-a1b6-78f20b72e403@github.com>

On Wed, 9 Feb 2022 23:58:43 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <ZpZU_qZpCB_ii42Jh9LLGRNA6bxEtzV_tZYik_rpDd0=.a592c547-f7ef-4f55-a1b6-78f20b72e403@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <SN6JAvfKAcRlPMFgh8AJHETIj_Vln0LI3jKDzQbTNHw=.6cb5f902-c43d-4b0f-a6c5-8ecd9bb0a5e1@github.com>
 <ZpZU_qZpCB_ii42Jh9LLGRNA6bxEtzV_tZYik_rpDd0=.a592c547-f7ef-4f55-a1b6-78f20b72e403@github.com>
Message-ID: <SkMhmGuXXBynj-Xq_QVVaimVZA67JnS4hmctjfryMY0=.926ee31d-9c96-43a4-8d6d-fb1d6a8083a8@github.com>

On Thu, 10 Feb 2022 13:41:01 GMT, Alan Bateman <alanb at openjdk.org> 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:      * <p> 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: <SkMhmGuXXBynj-Xq_QVVaimVZA67JnS4hmctjfryMY0=.926ee31d-9c96-43a4-8d6d-fb1d6a8083a8@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <SN6JAvfKAcRlPMFgh8AJHETIj_Vln0LI3jKDzQbTNHw=.6cb5f902-c43d-4b0f-a6c5-8ecd9bb0a5e1@github.com>
 <ZpZU_qZpCB_ii42Jh9LLGRNA6bxEtzV_tZYik_rpDd0=.a592c547-f7ef-4f55-a1b6-78f20b72e403@github.com>
 <SkMhmGuXXBynj-Xq_QVVaimVZA67JnS4hmctjfryMY0=.926ee31d-9c96-43a4-8d6d-fb1d6a8083a8@github.com>
Message-ID: <iwgMmGHaOUs7bl6XDY_1-zpWnk3LJwGH7Jcy6KwEq4w=.c19023b6-8ef1-4ace-b142-56a897dc7ed7@github.com>

On Thu, 10 Feb 2022 19:33:16 GMT, Brian Burkhalter <bpb at openjdk.org> 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:      * <p> 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: <mw6Ktv3AFUJWnFbbppAmEfqQ36c6_DB8rjHfF8WkvfU=.61c96b36-713b-4bf4-83f0-00ed4b517bce@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: 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: <iwgMmGHaOUs7bl6XDY_1-zpWnk3LJwGH7Jcy6KwEq4w=.c19023b6-8ef1-4ace-b142-56a897dc7ed7@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <SN6JAvfKAcRlPMFgh8AJHETIj_Vln0LI3jKDzQbTNHw=.6cb5f902-c43d-4b0f-a6c5-8ecd9bb0a5e1@github.com>
 <ZpZU_qZpCB_ii42Jh9LLGRNA6bxEtzV_tZYik_rpDd0=.a592c547-f7ef-4f55-a1b6-78f20b72e403@github.com>
 <SkMhmGuXXBynj-Xq_QVVaimVZA67JnS4hmctjfryMY0=.926ee31d-9c96-43a4-8d6d-fb1d6a8083a8@github.com>
 <iwgMmGHaOUs7bl6XDY_1-zpWnk3LJwGH7Jcy6KwEq4w=.c19023b6-8ef1-4ace-b142-56a897dc7ed7@github.com>
Message-ID: <DcDN5NLh2-ZfYmKciuA8Uc6TLtzngiAUNC05fm4A8qY=.1ebde8a8-1c27-4236-82d2-61e7d3f82d42@github.com>

On Thu, 10 Feb 2022 19:59:49 GMT, Alan Bateman <alanb at openjdk.org> 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: <mw6Ktv3AFUJWnFbbppAmEfqQ36c6_DB8rjHfF8WkvfU=.61c96b36-713b-4bf4-83f0-00ed4b517bce@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <mw6Ktv3AFUJWnFbbppAmEfqQ36c6_DB8rjHfF8WkvfU=.61c96b36-713b-4bf4-83f0-00ed4b517bce@github.com>
Message-ID: <YvAAC0oXhjzaQ2u1JtTpEEPDJdXKELiG3Nz9G6l-zTs=.2a3b9f56-5411-4fe1-b99c-1efd6c3234b7@github.com>

On Thu, 10 Feb 2022 21:01:03 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <mw6Ktv3AFUJWnFbbppAmEfqQ36c6_DB8rjHfF8WkvfU=.61c96b36-713b-4bf4-83f0-00ed4b517bce@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <mw6Ktv3AFUJWnFbbppAmEfqQ36c6_DB8rjHfF8WkvfU=.61c96b36-713b-4bf4-83f0-00ed4b517bce@github.com>
Message-ID: <soECq2265OJ20r_K1VTLXgbwttDLAa8sNTZ3G9fyhQE=.c2e0db4f-7b94-4860-9c83-22fe90830ef6@github.com>

On Thu, 10 Feb 2022 21:01:03 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <mw6Ktv3AFUJWnFbbppAmEfqQ36c6_DB8rjHfF8WkvfU=.61c96b36-713b-4bf4-83f0-00ed4b517bce@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <mw6Ktv3AFUJWnFbbppAmEfqQ36c6_DB8rjHfF8WkvfU=.61c96b36-713b-4bf4-83f0-00ed4b517bce@github.com>
Message-ID: <5tfvqvjlSTB9h4Rw_EEYO0gQzsjIxbzzHyIkzxMJsdE=.9d9aae3e-966b-4b2c-9a94-d8f6e13ea949@github.com>

On Thu, 10 Feb 2022 21:01:03 GMT, Brian Burkhalter <bpb at openjdk.org> 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>
 <mw6Ktv3AFUJWnFbbppAmEfqQ36c6_DB8rjHfF8WkvfU=.61c96b36-713b-4bf4-83f0-00ed4b517bce@github.com>
 <5tfvqvjlSTB9h4Rw_EEYO0gQzsjIxbzzHyIkzxMJsdE=.9d9aae3e-966b-4b2c-9a94-d8f6e13ea949@github.com>
Message-ID: <Z499cjXBBez2StTkzZ7ecG5svKGBvsosay2XuE5ngCs=.8c48b9d0-d637-4f86-8c3a-8316f11d3fac@github.com>

On Fri, 11 Feb 2022 10:22:15 GMT, Alan Bateman <alanb at openjdk.org> 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: <Z499cjXBBez2StTkzZ7ecG5svKGBvsosay2XuE5ngCs=.8c48b9d0-d637-4f86-8c3a-8316f11d3fac@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <mw6Ktv3AFUJWnFbbppAmEfqQ36c6_DB8rjHfF8WkvfU=.61c96b36-713b-4bf4-83f0-00ed4b517bce@github.com>
 <5tfvqvjlSTB9h4Rw_EEYO0gQzsjIxbzzHyIkzxMJsdE=.9d9aae3e-966b-4b2c-9a94-d8f6e13ea949@github.com>
 <Z499cjXBBez2StTkzZ7ecG5svKGBvsosay2XuE5ngCs=.8c48b9d0-d637-4f86-8c3a-8316f11d3fac@github.com>
Message-ID: <Nu3atpVPq60JKK7EHVwAT28t2XtRWCwHImt8uBmg2vs=.2bcd75e7-d87a-4284-b79e-e93554c3156a@github.com>

On Fri, 11 Feb 2022 15:24:09 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <QMgW1dfHg08H09kI9GizeYsjLGS6V-Zwdva8D8UkNNk=.9302619e-9a97-4779-b7dd-bf11d51d28ee@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: 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: <Iw80FSNs2MJt89jqPmFQNxH_e-GJk4cobdIu4TwYpuI=.057daff6-fbbc-49c6-9464-920f4a40e8d3@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: 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: <ajG_40t7pMXuYM1ywUjf0p8ZNs8LExL3aFhTDNGohtU=.b40acc4f-0576-47f7-b765-10f5b8963102@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: 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: <OXd_pMr-eW6PviQpZSnYZgts-cZYyAZGr5sb77_041Y=.f32d9b10-ac08-42f2-8195-871ac895d9ff@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <OXd_pMr-eW6PviQpZSnYZgts-cZYyAZGr5sb77_041Y=.f32d9b10-ac08-42f2-8195-871ac895d9ff@github.com>
Message-ID: <nos01hDbKVvQpNM76v7ZwO6aGsuzjXIh63l0TyDabOI=.38c0f149-718d-41a0-bbc2-d7f3353ef8e1@github.com>

On Sat, 25 Dec 2021 16:10:37 GMT, Markus KARG <duke at openjdk.java.net> 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: <VCG1Jak1a8dGYUa0MO3F_uL7HMKHd3x4elJ3SlmO-MQ=.2b563685-efea-4e60-a44a-12697ac6a9f7@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <VCG1Jak1a8dGYUa0MO3F_uL7HMKHd3x4elJ3SlmO-MQ=.2b563685-efea-4e60-a44a-12697ac6a9f7@github.com>
Message-ID: <A3RecDQqbZ4-3LgOk2TosCdWYQFOfoKb9ZWNe_vDJfA=.9eab78fd-b89c-484b-b0e9-9efba77b84d3@github.com>

On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG <duke at openjdk.java.net> 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: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@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.

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

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: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
Message-ID: <cIeRf1IHY5vA-DPDhevfroOIRsXL09mTXdBzxBfwxRQ=.13db3043-2c91-4661-bdd9-59cbb7a39ed6@github.com>

On Mon, 14 Feb 2022 21:21:14 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
Message-ID: <nEIig10Q0Rq474AYQOBEZyy7l9dT_IrNEgL6_J5j2xE=.f50c9020-c40a-48d5-87c6-87f2654eb91f@github.com>

On Mon, 14 Feb 2022 21:21:14 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
Message-ID: <n6qHE_hcVvtK85GfEimhmis3fr1fFM-T-KHNDmdSxJg=.79f1e3b5-89c9-4af6-9f8d-dddcd4052b0e@github.com>

On Mon, 14 Feb 2022 21:21:14 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
Message-ID: <-BhFUVnpM-LZXSr2Z7WbvGTgPvJMXEcTGCvgZ-xn8TA=.49d59463-abbb-4438-a642-ff46489b6eac@github.com>

On Mon, 14 Feb 2022 21:21:14 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
 <-BhFUVnpM-LZXSr2Z7WbvGTgPvJMXEcTGCvgZ-xn8TA=.49d59463-abbb-4438-a642-ff46489b6eac@github.com>
Message-ID: <efGKsx22_OIcb3P7f-O6nEPEYeKuLSFL-l8bVeVh5A8=.4cb42b04-fcb3-4a74-b465-648bf893ee62@github.com>

On Tue, 15 Feb 2022 05:15:44 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <nEIig10Q0Rq474AYQOBEZyy7l9dT_IrNEgL6_J5j2xE=.f50c9020-c40a-48d5-87c6-87f2654eb91f@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
 <nEIig10Q0Rq474AYQOBEZyy7l9dT_IrNEgL6_J5j2xE=.f50c9020-c40a-48d5-87c6-87f2654eb91f@github.com>
Message-ID: <VcwRif8ChKovH64at8kK2cutbtJ7zyF2Tw6k2ByjoxY=.db5b4181-025e-40f9-9a34-e23ea7aafc0d@github.com>

On Tue, 15 Feb 2022 04:25:32 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
Message-ID: <hhXPC3l7XgDToSDv1DxPiKF1GLP0ZNRlyx1ECJ3p3-Y=.02597ad6-d600-4a5c-9966-bc540a5089c5@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: 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: <VcwRif8ChKovH64at8kK2cutbtJ7zyF2Tw6k2ByjoxY=.db5b4181-025e-40f9-9a34-e23ea7aafc0d@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
 <nEIig10Q0Rq474AYQOBEZyy7l9dT_IrNEgL6_J5j2xE=.f50c9020-c40a-48d5-87c6-87f2654eb91f@github.com>
 <VcwRif8ChKovH64at8kK2cutbtJ7zyF2Tw6k2ByjoxY=.db5b4181-025e-40f9-9a34-e23ea7aafc0d@github.com>
Message-ID: <7EEmQ_I1MhtISKpO0ZIzHfw30j8o90MQG9a_v8YktKc=.c14b0630-3661-4840-adf6-b877929c3b6a@github.com>

On Tue, 15 Feb 2022 18:02:26 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <hhXPC3l7XgDToSDv1DxPiKF1GLP0ZNRlyx1ECJ3p3-Y=.02597ad6-d600-4a5c-9966-bc540a5089c5@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
 <hhXPC3l7XgDToSDv1DxPiKF1GLP0ZNRlyx1ECJ3p3-Y=.02597ad6-d600-4a5c-9966-bc540a5089c5@github.com>
Message-ID: <RmKPdD02EwNwRpuHH21QNefxfJO5DImtPK-kaBARTlU=.058c7f1f-aa0a-4d15-9acb-c7f89541e8d2@github.com>

On Wed, 16 Feb 2022 00:44:37 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
 <nEIig10Q0Rq474AYQOBEZyy7l9dT_IrNEgL6_J5j2xE=.f50c9020-c40a-48d5-87c6-87f2654eb91f@github.com>
 <VcwRif8ChKovH64at8kK2cutbtJ7zyF2Tw6k2ByjoxY=.db5b4181-025e-40f9-9a34-e23ea7aafc0d@github.com>
 <7EEmQ_I1MhtISKpO0ZIzHfw30j8o90MQG9a_v8YktKc=.c14b0630-3661-4840-adf6-b877929c3b6a@github.com>
Message-ID: <W9DSAnFIr6tQsItnYym8HaL5RhXLg-H-ULv2alO7BlQ=.50f63d3d-935c-4e86-b065-e37029e5dc58@github.com>

On Wed, 16 Feb 2022 00:53:02 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <hhXPC3l7XgDToSDv1DxPiKF1GLP0ZNRlyx1ECJ3p3-Y=.02597ad6-d600-4a5c-9966-bc540a5089c5@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
 <hhXPC3l7XgDToSDv1DxPiKF1GLP0ZNRlyx1ECJ3p3-Y=.02597ad6-d600-4a5c-9966-bc540a5089c5@github.com>
Message-ID: <NGsGmDOFnX1pU2IG9y10Jouag3BklSKQUXXQb5ghJpQ=.bd42dd14-8a67-432a-ae34-be3cb4ce5d21@github.com>

On Wed, 16 Feb 2022 00:44:37 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <ajG_40t7pMXuYM1ywUjf0p8ZNs8LExL3aFhTDNGohtU=.b40acc4f-0576-47f7-b765-10f5b8963102@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <ajG_40t7pMXuYM1ywUjf0p8ZNs8LExL3aFhTDNGohtU=.b40acc4f-0576-47f7-b765-10f5b8963102@github.com>
Message-ID: <xnkUQOk82qgpjdTJUksnmkLIJ-C3lkoqYxpCmPp2bn0=.f0ac25b7-84a9-4f5d-b76a-3d7e6a001f6b@github.com>

On Fri, 11 Feb 2022 21:25:04 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <xnkUQOk82qgpjdTJUksnmkLIJ-C3lkoqYxpCmPp2bn0=.f0ac25b7-84a9-4f5d-b76a-3d7e6a001f6b@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <ajG_40t7pMXuYM1ywUjf0p8ZNs8LExL3aFhTDNGohtU=.b40acc4f-0576-47f7-b765-10f5b8963102@github.com>
 <xnkUQOk82qgpjdTJUksnmkLIJ-C3lkoqYxpCmPp2bn0=.f0ac25b7-84a9-4f5d-b76a-3d7e6a001f6b@github.com>
Message-ID: <RxOP1s7nWBk8F9dLJH9ZlFqoNzYC_6k5k9C-g1XKN0I=.46b5ef4d-0303-441b-88c9-eabac55ddb2d@github.com>

On Thu, 17 Feb 2022 13:23:37 GMT, Alan Bateman <alanb at openjdk.org> 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: <sO5yKao7nHpy0lHZXintvMPgqpP7A46EI_FuNjrpUxo=.c35028cb-12df-49b5-90a0-2e82d085a290@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: 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: <sO5yKao7nHpy0lHZXintvMPgqpP7A46EI_FuNjrpUxo=.c35028cb-12df-49b5-90a0-2e82d085a290@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <sO5yKao7nHpy0lHZXintvMPgqpP7A46EI_FuNjrpUxo=.c35028cb-12df-49b5-90a0-2e82d085a290@github.com>
Message-ID: <zUryec0TGmObgCjFoqcsuS1lNKeV5nsrPhmppWiGHfg=.d8315f7e-1162-481c-b672-02a0c7330cd7@github.com>

On Thu, 17 Feb 2022 17:14:43 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <RxOP1s7nWBk8F9dLJH9ZlFqoNzYC_6k5k9C-g1XKN0I=.46b5ef4d-0303-441b-88c9-eabac55ddb2d@github.com>
References: <6yRQ208wuBVKpFR8BnDk9lO-jkUtBi14CcB4oYos_10=.73d39203-a171-4b06-9b0f-a0057f5bf0bd@github.com>
 <ajG_40t7pMXuYM1ywUjf0p8ZNs8LExL3aFhTDNGohtU=.b40acc4f-0576-47f7-b765-10f5b8963102@github.com>
 <xnkUQOk82qgpjdTJUksnmkLIJ-C3lkoqYxpCmPp2bn0=.f0ac25b7-84a9-4f5d-b76a-3d7e6a001f6b@github.com>
 <RxOP1s7nWBk8F9dLJH9ZlFqoNzYC_6k5k9C-g1XKN0I=.46b5ef4d-0303-441b-88c9-eabac55ddb2d@github.com>
Message-ID: <AYsHiYRa8nHsRlAmm2lpL9jt138prsFKETGJew3ob3w=.92b55a22-e4e6-44ea-a04d-7182ebcb223c@github.com>

On Thu, 17 Feb 2022 16:49:45 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <hhXPC3l7XgDToSDv1DxPiKF1GLP0ZNRlyx1ECJ3p3-Y=.02597ad6-d600-4a5c-9966-bc540a5089c5@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
 <hhXPC3l7XgDToSDv1DxPiKF1GLP0ZNRlyx1ECJ3p3-Y=.02597ad6-d600-4a5c-9966-bc540a5089c5@github.com>
Message-ID: <-qVVvmja6lX5DfiL90t6FoV6VuyCvz6yGDz8VatccQc=.c487ea8b-3c74-49a5-b650-13504044764d@github.com>

On Wed, 16 Feb 2022 00:44:37 GMT, Brian Burkhalter <bpb at openjdk.org> 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<UnixException, IOException> 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: <hhXPC3l7XgDToSDv1DxPiKF1GLP0ZNRlyx1ECJ3p3-Y=.02597ad6-d600-4a5c-9966-bc540a5089c5@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
 <hhXPC3l7XgDToSDv1DxPiKF1GLP0ZNRlyx1ECJ3p3-Y=.02597ad6-d600-4a5c-9966-bc540a5089c5@github.com>
Message-ID: <WBDsYtay6dAP3gW06CYl0oD9WUdtakRw6pzE35HF6gc=.e4f189c7-f589-436e-bfcb-f63cb503b98d@github.com>

On Wed, 16 Feb 2022 00:44:37 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <WBDsYtay6dAP3gW06CYl0oD9WUdtakRw6pzE35HF6gc=.e4f189c7-f589-436e-bfcb-f63cb503b98d@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
 <hhXPC3l7XgDToSDv1DxPiKF1GLP0ZNRlyx1ECJ3p3-Y=.02597ad6-d600-4a5c-9966-bc540a5089c5@github.com>
 <WBDsYtay6dAP3gW06CYl0oD9WUdtakRw6pzE35HF6gc=.e4f189c7-f589-436e-bfcb-f63cb503b98d@github.com>
Message-ID: <z_-vz-UsxuTvllRnBB90H9257hoRya5AJPLzEBJJom0=.35178838-2922-463e-9593-cb9e6d8f8189@github.com>

On Fri, 18 Feb 2022 17:21:40 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <TuODjY7NujG_VSWg1dWrng-gEqIQcbRcMZjfneQlgCI=.5eec74ea-c199-4ad8-84f0-bd5d17c5bec6@github.com>

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: <TuODjY7NujG_VSWg1dWrng-gEqIQcbRcMZjfneQlgCI=.5eec74ea-c199-4ad8-84f0-bd5d17c5bec6@github.com>
References: <TuODjY7NujG_VSWg1dWrng-gEqIQcbRcMZjfneQlgCI=.5eec74ea-c199-4ad8-84f0-bd5d17c5bec6@github.com>
Message-ID: <eeOQm6i91lT9I2kLwJVil650Pe9DcRDzLefnQGHjcK0=.8e64c442-3007-493f-bc72-4f70077d8af4@github.com>

On Fri, 18 Feb 2022 10:11:42 GMT, Andrey Turbanov <aturbanov at openjdk.org> 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: <HNsW1RMrTmTMMR_txT5BhZSh1ijRtrB0o4DsZLIo6KI=.d1ec1c01-261f-4ec1-8cb3-8ec25a4a32cd@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: 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: <TuODjY7NujG_VSWg1dWrng-gEqIQcbRcMZjfneQlgCI=.5eec74ea-c199-4ad8-84f0-bd5d17c5bec6@github.com>
References: <TuODjY7NujG_VSWg1dWrng-gEqIQcbRcMZjfneQlgCI=.5eec74ea-c199-4ad8-84f0-bd5d17c5bec6@github.com>
Message-ID: <ve15ugxVLqCOTMuGIaCx9zXvyvi-wxLO8jcFkmL4qac=.8fcb6e49-5a4d-46f1-813b-495dd53a952e@github.com>

On Fri, 18 Feb 2022 10:11:42 GMT, Andrey Turbanov <aturbanov at openjdk.org> 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: <TuODjY7NujG_VSWg1dWrng-gEqIQcbRcMZjfneQlgCI=.5eec74ea-c199-4ad8-84f0-bd5d17c5bec6@github.com>
References: <TuODjY7NujG_VSWg1dWrng-gEqIQcbRcMZjfneQlgCI=.5eec74ea-c199-4ad8-84f0-bd5d17c5bec6@github.com>
Message-ID: <XVG2dqZ-_07mCJAYUXr26R_thhTYPgpTZg4pRA3EAoA=.31023f9e-b387-4582-836d-4ee649f92778@github.com>

On Fri, 18 Feb 2022 10:11:42 GMT, Andrey Turbanov <aturbanov at openjdk.org> 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 <aturbanov at openjdk.org>
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: <yWM_TmfJCb-Z2mp09oqA_AVhVoSuaMyyBB7VFQorVI4=.50b67d9d-22f7-47c9-b903-be49909249e0@github.com>

On Thu, 27 Jan 2022 22:12:32 GMT, Brian Burkhalter <bpb at openjdk.org> 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 <bpb at openjdk.org>
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: <tnYS7TVasktzxu3aJcStPe0svkIpk18UrF1BVi0Dfrs=.4abc4d07-ff23-417c-84a0-5984b631a94d@github.com>
References: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
 <tnYS7TVasktzxu3aJcStPe0svkIpk18UrF1BVi0Dfrs=.4abc4d07-ff23-417c-84a0-5984b631a94d@github.com>
Message-ID: <EJxPkemCQd09qhDFEDHnp8hLhSjnOhviHQUTM0wlWKo=.be025d6d-344a-424a-98c0-27014ea06c24@github.com>

On Wed, 2 Feb 2022 12:12:36 GMT, Michael McMahon <michaelm at openjdk.org> 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: <EJxPkemCQd09qhDFEDHnp8hLhSjnOhviHQUTM0wlWKo=.be025d6d-344a-424a-98c0-27014ea06c24@github.com>
References: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
 <tnYS7TVasktzxu3aJcStPe0svkIpk18UrF1BVi0Dfrs=.4abc4d07-ff23-417c-84a0-5984b631a94d@github.com>
 <EJxPkemCQd09qhDFEDHnp8hLhSjnOhviHQUTM0wlWKo=.be025d6d-344a-424a-98c0-27014ea06c24@github.com>
Message-ID: <cSJSZXVNzb1FZw4Gdf4o6suyYlQxZcxCwoAikXvYqhQ=.eeaec33f-500f-40ad-9dfe-87f60dacdeae@github.com>

On Tue, 22 Feb 2022 22:41:10 GMT, ExE Boss <duke at openjdk.java.net> 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: <cSJSZXVNzb1FZw4Gdf4o6suyYlQxZcxCwoAikXvYqhQ=.eeaec33f-500f-40ad-9dfe-87f60dacdeae@github.com>
References: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
 <tnYS7TVasktzxu3aJcStPe0svkIpk18UrF1BVi0Dfrs=.4abc4d07-ff23-417c-84a0-5984b631a94d@github.com>
 <EJxPkemCQd09qhDFEDHnp8hLhSjnOhviHQUTM0wlWKo=.be025d6d-344a-424a-98c0-27014ea06c24@github.com>
 <cSJSZXVNzb1FZw4Gdf4o6suyYlQxZcxCwoAikXvYqhQ=.eeaec33f-500f-40ad-9dfe-87f60dacdeae@github.com>
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: <cSJSZXVNzb1FZw4Gdf4o6suyYlQxZcxCwoAikXvYqhQ=.eeaec33f-500f-40ad-9dfe-87f60dacdeae@github.com>
References: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
 <tnYS7TVasktzxu3aJcStPe0svkIpk18UrF1BVi0Dfrs=.4abc4d07-ff23-417c-84a0-5984b631a94d@github.com>
 <EJxPkemCQd09qhDFEDHnp8hLhSjnOhviHQUTM0wlWKo=.be025d6d-344a-424a-98c0-27014ea06c24@github.com>
 <cSJSZXVNzb1FZw4Gdf4o6suyYlQxZcxCwoAikXvYqhQ=.eeaec33f-500f-40ad-9dfe-87f60dacdeae@github.com>
Message-ID: <DikPABSjiDyjA8oxDvF4CaEiehsN3fP4_w-jlHczXXY=.eeb2ee9b-db04-4cd2-9ebf-8f1640845629@github.com>

On Wed, 23 Feb 2022 10:11:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> 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: <tnYS7TVasktzxu3aJcStPe0svkIpk18UrF1BVi0Dfrs=.4abc4d07-ff23-417c-84a0-5984b631a94d@github.com>
References: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
 <tnYS7TVasktzxu3aJcStPe0svkIpk18UrF1BVi0Dfrs=.4abc4d07-ff23-417c-84a0-5984b631a94d@github.com>
Message-ID: <6_hktCwwM6KbChBb8hItNxtv3UFiBdPyYXmrjKASF2M=.1d7a2522-8344-49aa-9da2-e62f0b3b0eab@github.com>

On Wed, 2 Feb 2022 12:12:36 GMT, Michael McMahon <michaelm at openjdk.org> 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: <tnYS7TVasktzxu3aJcStPe0svkIpk18UrF1BVi0Dfrs=.4abc4d07-ff23-417c-84a0-5984b631a94d@github.com>
References: <lLogLAzTsqku3CNHCsCuVCsb59bFovEfvXZr6zE6xbQ=.dedf44dc-52c7-421d-8fdf-c4a220d1c8c9@github.com>
 <tnYS7TVasktzxu3aJcStPe0svkIpk18UrF1BVi0Dfrs=.4abc4d07-ff23-417c-84a0-5984b631a94d@github.com>
Message-ID: <LXtuRMpHB9m0Gzra-CM7_njE_FEb-oOPkj6zH18Rt7Y=.5fb55954-32bc-4fce-a2ea-9fbf7aba5082@github.com>

On Wed, 2 Feb 2022 12:12:36 GMT, Michael McMahon <michaelm at openjdk.org> 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: <sfVWw9_havqYK2dWsBBSJyXwdX_9aFmlw409M7hvCBY=.d9b0f4a3-e774-4cf3-84d7-2302f401d182@github.com>

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: <sfVWw9_havqYK2dWsBBSJyXwdX_9aFmlw409M7hvCBY=.d9b0f4a3-e774-4cf3-84d7-2302f401d182@github.com>
References: <sfVWw9_havqYK2dWsBBSJyXwdX_9aFmlw409M7hvCBY=.d9b0f4a3-e774-4cf3-84d7-2302f401d182@github.com>
Message-ID: <liMpVXrPTqB6-_eNc9emzKhW9THZkoujJcQ5VYl8DoY=.9a6823bd-517a-4602-b3ad-74dc2c175fb5@github.com>

On Wed, 23 Feb 2022 17:37:08 GMT, Michael McMahon <michaelm at openjdk.org> 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: <sfVWw9_havqYK2dWsBBSJyXwdX_9aFmlw409M7hvCBY=.d9b0f4a3-e774-4cf3-84d7-2302f401d182@github.com>
References: <sfVWw9_havqYK2dWsBBSJyXwdX_9aFmlw409M7hvCBY=.d9b0f4a3-e774-4cf3-84d7-2302f401d182@github.com>
Message-ID: <yVsUkjD2eT3pBKII5Vfj6YkjMX0xF_I4Hr0k3yd6ORs=.86abb3ea-6713-4c8f-8c9d-b515a0e1c066@github.com>

On Wed, 23 Feb 2022 17:37:08 GMT, Michael McMahon <michaelm at openjdk.org> 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: <sfVWw9_havqYK2dWsBBSJyXwdX_9aFmlw409M7hvCBY=.d9b0f4a3-e774-4cf3-84d7-2302f401d182@github.com>
References: <sfVWw9_havqYK2dWsBBSJyXwdX_9aFmlw409M7hvCBY=.d9b0f4a3-e774-4cf3-84d7-2302f401d182@github.com>
Message-ID: <BD4OWyepEwoS3pXHMkaOAagE9e-ZIc-VEipxdp248H8=.85c4eee5-9f65-4f25-8722-2407d1ac2eb8@github.com>

On Wed, 23 Feb 2022 17:37:08 GMT, Michael McMahon <michaelm at openjdk.org> 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: <sfVWw9_havqYK2dWsBBSJyXwdX_9aFmlw409M7hvCBY=.d9b0f4a3-e774-4cf3-84d7-2302f401d182@github.com>
References: <sfVWw9_havqYK2dWsBBSJyXwdX_9aFmlw409M7hvCBY=.d9b0f4a3-e774-4cf3-84d7-2302f401d182@github.com>
Message-ID: <WdeHaXiwRUzJ7xkXqKlPNgQMR1v0ahoTWmo-6SA7MDE=.71bf6c2e-e809-4eee-b0d6-a836a3dd7320@github.com>

On Wed, 23 Feb 2022 17:37:08 GMT, Michael McMahon <michaelm at openjdk.org> 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 <michaelm at openjdk.org>
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: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
Message-ID: <df7JMxhKlPXQAEr09WuZwQ1K8kfsAe3kCt544A9ZjUo=.0b1f0ca4-28bf-4126-bdbf-ac905633fd5f@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: 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: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
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: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
 <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 <bpb at openjdk.org> 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: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
Message-ID: <bv58FHkfGMKJy_n11CjDRhbGRUGCaGmM5XkdMUdlyGo=.1b1a5db6-56a1-403c-b6f0-cfadf48f53fa@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: 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: <bv58FHkfGMKJy_n11CjDRhbGRUGCaGmM5XkdMUdlyGo=.1b1a5db6-56a1-403c-b6f0-cfadf48f53fa@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
 <bv58FHkfGMKJy_n11CjDRhbGRUGCaGmM5XkdMUdlyGo=.1b1a5db6-56a1-403c-b6f0-cfadf48f53fa@github.com>
Message-ID: <wwUHDxk_9kW3tW4R-re8nFzsbdUXS7ttFNMUx2BhhiQ=.41053f2b-7e59-43eb-afac-075e137c4f50@github.com>

On Fri, 25 Feb 2022 17:39:07 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
Message-ID: <ABM14oJgzK2FgmTV2chrTGSCfBAa54XnMIH0_JcwCPA=.affd4200-f249-4580-9d4b-f375ca58ab57@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: 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: <nu7MGFiRvdSKIEUAfsV1BFk0htQw0-1QLs15FrGzgmE=.2312b0f3-f2ab-42bd-9d97-649b41bba252@github.com>

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: <nu7MGFiRvdSKIEUAfsV1BFk0htQw0-1QLs15FrGzgmE=.2312b0f3-f2ab-42bd-9d97-649b41bba252@github.com>
References: <nu7MGFiRvdSKIEUAfsV1BFk0htQw0-1QLs15FrGzgmE=.2312b0f3-f2ab-42bd-9d97-649b41bba252@github.com>
Message-ID: <LQUEmJprQJ5y54rbrVZ3OLcxQqFHd0s7-nv4mrLMEMg=.48e5e40e-0267-4d9f-ba2e-d86425bcd7f5@github.com>

On Fri, 25 Feb 2022 23:31:22 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <ABM14oJgzK2FgmTV2chrTGSCfBAa54XnMIH0_JcwCPA=.affd4200-f249-4580-9d4b-f375ca58ab57@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
 <ABM14oJgzK2FgmTV2chrTGSCfBAa54XnMIH0_JcwCPA=.affd4200-f249-4580-9d4b-f375ca58ab57@github.com>
Message-ID: <9huvL2cyJtQVAdlrnr--UjXLeQy-ITs5bf5e1me_uAw=.03b6e1db-7a8e-4dba-85a7-e6687f44d24f@github.com>

On Fri, 25 Feb 2022 21:26:37 GMT, Brian Burkhalter <bpb at openjdk.org> 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