Files.copy does userspace copies but FileChannel uses sendfile

[Brian Burkhalter]

On Oct 12, 2016, at 10:56 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> On Oct 12, 2016, at 9:39 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
>> On 12/10/2016 17:30, Brian Burkhalter wrote:
>> 
>>> It seems as if this is a good candidate for some JMH testing from the Java layer.
>> Yes  although you also have to measure the copy when the source isn't in the file system cache so that means dropping caches between copies.
> 
> That should be feasible given the control available within JMH.

It’s not the best environment for performance testing, but preliminary JMH benchmark runs on an Ubuntu 16.04 64-bit guest VM on an OS X host show approximately a 6-10% improvement of sendfile(2) over read(2) + write(2) for file-to-file copies. This is with an fsync(2) invocation inserted before the return from Java_sun_nio_fs_UnixCopyFile_transfer()

--- a/src/java.base/unix/native/libnio/fs/UnixCopyFile.c
+++ b/src/java.base/unix/native/libnio/fs/UnixCopyFile.c
@@ -82,4 +82,5 @@
             len -= n;
         } while (len > 0);
     }
+    fsync((int)dst);
 }

to ensure that the modified buffer cache pages are flushed to disk. Without the contrived insertion of fsync() the improvement is about 5%. If this seems promising enough I can look into running the benchmark on some other more realistic systems.

As an aside, sendfile(2) on the version of OS X I am running (10.9.5 Mavericks) does not support file-to-file transfers:

     The sendfile() system call sends a regular file specified by descriptor
     fd out a stream socket specified by descriptor s.

On Solaris however file-to-file appears to be supported [2].

Brian

[1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/src/java.base/unix/native/libnio/fs/UnixCopyFile.c
[2] https://docs.oracle.com/cd/E36784_01/html/E36876/sendfile-3ext.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20161018/c7180e0c/attachment.html>