Files.copy does userspace copies but FileChannel uses sendfile

[Brian Burkhalter]

Hi Max,

I don’t know the historical context for this design, but after looking over the code a bit it seems that you have a point, at least for the case where Files.copy() is a non-interruptible file copy. For a non-interruptible file copy I do not see why sendfile() or its equivalent on the Unix platform in question could not be used. Whether a file copy is interruptible is set by an ExtendedOption in the CopyOption passed to [1].

If the foregoing is correct, the refactoring might better be done by moving the native transferTo0() functionality to UnixNativeDispatcher and having FileChannelImpl.transferToDirectlyInternal() and the non-interruptible case of Files.copy() call it.

Thanks,

Brian

[1] http://download.java.net/java/jdk9/docs/api/java/nio/file/Files.html#copy-java.nio.file.Path-java.nio.file.Path-java.nio.file.CopyOption...-

On Oct 11, 2016, at 4:30 PM, Max Kanat-Alexander <mkanat at google.com> wrote:

> java.nio.file.Files.copy uses this code, ultimately, to copy files:
> 
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/src/java.base/unix/native/libnio/fs/UnixCopyFile.c
> 
> I was surprised that that didn't use sendfile when it's available. I was even more surprised that there is already another copying implementation in the JDK that _does_ use sendfile:
> 
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/b909daf8fdbc/src/java.base/unix/native/libnio/ch/FileChannelImpl.c#l164
> 
> Should these be merged? Or should the Java-side implementation of Files.copy be changed to use FileChannel underneath?
> 
> -Max

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20161011/d1fea885/attachment-0001.html>