RFR: 8265175: (fs) Files.copy(Path, Path, CopyOption...) should use zero-copy on Linux
Brian Burkhalter
bpb at openjdk.java.net
Wed Apr 14 15:41:37 UTC 2021
On Wed, 14 Apr 2021 10:22:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:
> Have you measured the user vs. kernel time when testing?
No.
> I'm also interested to see if you've tried using a buffer size that is a LCM of the source and destination block sizes.
No, the buffer size was 8192 and both block sizes 4096, which seems to be the largest that my Linux version can handle.
> For large files, can you can what byte_sent returns? I'm wondering if the cancellable mechanism is effective with this implementation.
For all files that I observed, bytes_sent was equal to the file size. Therefore I am also skeptical of the possibility of cancellation. From the man page:
Note that a successful call to sendfile()
may write fewer bytes than requested; the caller should be
prepared to retry the call if there were unsent bytes.
> The call already has the file size so the call to fstat is not needed.
OK.
> I think I'd prefer to continue to read to EOF as that it is a bit friendly to files that are changing when being copied. I assume the current patch is problematic on 32-bit (use sendfile64 and off64_t to be consistent with FileChannelImpl). It will also need to handle the EINTR case.
I will revise it to address these three points.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3476
More information about the nio-dev
mailing list