RFR: 8271308: (fc) FileChannel.transferTo() transfers no more than Integer.MAX_VALUE bytes in one call [v2]

[Alan Bateman]

On Mon, 2 Aug 2021 21:54:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 705:
>> 
>>> 703:                 break;
>>> 704:             position += n;
>>> 705:             bytesTransferred += n;
>> 
>> I think this patch is problematic for the cases where the second (or subsequent) call to transferTo fails. transferToArbitraryChannel has to deal with this by returning the number of bytes transferred before the error.
>> 
>> I think it might be better to just continue with having transferTo map to one syscall where possible. In this case I'd prefer not introduce a loop but instead just use the OS "max transfer size" to cap the number of bytes transferred in one call to this method.
>
> In the updated code, the direct transfer case no longer loops and just maps to one syscall. The previously introduced private `transferTo()` method is removed. `transferToArbitraryChannel()` is modified to have a `long`-valued count. `transferToTrustedChannel()` works out of the box as-is and is not changed.

The update mostly looks okay, just wondering if could case maxDirectTransferSize to avoid the JNI call every time.

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

PR: https://git.openjdk.java.net/jdk/pull/4940