RFR: 8265175: (fs) Files.copy(Path, Path, CopyOption...) should use zero-copy on Linux

[Alan Bateman]

On Tue, 13 Apr 2021 21:40:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this request to change the underlying native implementation of `java.nio.file.Files.copy(Path,Path,CopyOption...)` on Linux only to perform zero-copy via `sendfile(2)`. The `sendfile()` system call is already used in `java.nio.channels.FIleChannel.transferTo​(long,long,WritableByteChannel)`. It is intentionally _not_ proposed to use `sendfile()` in the native macOS implementation as on macOS the function requires that the destination file descriptor is for a socket.
> 
> This change showed some performance improvement as measured by JMH.
> 
> **Before: user-space buffers (read() + write())**
> 
> Benchmark           (size)   Mode  Cnt      Score     Error  Units
> FilesCopy.copy       10240  thrpt    5  39167.400 ± 683.887  ops/s
> FilesCopy.copy       51200  thrpt    5  20782.622 ± 558.031  ops/s
> FilesCopy.copy      102400  thrpt    5  13260.709 ± 176.673  ops/s
> FilesCopy.copy      512000  thrpt    5   3171.837 ± 175.803  ops/s
> FilesCopy.copy     1048568  thrpt    5   1654.253 ±  39.419  ops/s
> FilesCopy.copy    10485760  thrpt    5    145.328 ±   7.192  ops/s
> FilesCopy.copy   104857600  thrpt    5     12.440 ±   2.275  ops/s
> FilesCopy.copy  1073741824  thrpt    5      1.073 ±   0.081  ops/s
> 
> **After: zero-copy (sendfile())**
> 
> Benchmark           (size)   Mode  Cnt      Score     Error  Units
> FilesCopy.copy       10240  thrpt    5  40571.516 ± 548.977  ops/s
> FilesCopy.copy       51200  thrpt    5  23993.334 ± 506.817  ops/s
> FilesCopy.copy      102400  thrpt    5  15927.485 ± 309.081  ops/s
> FilesCopy.copy      512000  thrpt    5   4207.129 ±  95.454  ops/s
> FilesCopy.copy     1048568  thrpt    5   2147.046 ±  33.446  ops/s
> FilesCopy.copy    10485760  thrpt    5    148.798 ±   1.329  ops/s
> FilesCopy.copy   104857600  thrpt    5     14.541 ±   0.675  ops/s
> FilesCopy.copy  1073741824  thrpt    5      1.270 ±   0.029  ops/s

I agree it's worth exploring using sendfile64 as file-to-file was not available when this code was written.

Have you measured the user vs. kernel time when testing? 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.

For large files, can you can what byte_sent returns? I'm wondering if the cancellable mechanism is effective with this implementation.

The call already has the file size so the call to fstat is not needed. 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.

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

Changes requested by alanb (Reviewer).

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