RFR: JDK-8273038: ChannelInputStream.transferTo() uses FileChannel.transferTo(FileChannel) [v6]

[Markus KARG]

On Sun, 29 Aug 2021 11:44:55 GMT, Markus KARG <github.com+1701815+mkarg at openjdk.org> wrote:

>> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. This PR is a spin-off from https://github.com/openjdk/jdk/pull/4263 and https://github.com/openjdk/jdk/pull/5179 and deliberately concentrates **only** on the case where both, source **and** target, are actually `FileChannel`s. Other types of channels will be discussed in future PRs.
>> 
>> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
>> 
>> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. A rather similar approach in different use casse was recently implemented by https://github.com/openjdk/jdk/pull/5097 which was reported by even provide 5x performance (https://github.com/openjdk/jdk/pull/5097#issuecomment-897271997).
>
> Markus KARG has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

> I'll try to get time to look at what you have in the next few days but just to say that the suggestion for exercising files > 2GB is because it's beyond the limit of the underlying sendfile. You should be able to check this quickly by printing the iteration count in ChannelInputStream.transferTo, it is always 1?

I understand your concerns and can dispel them. I added a counter that prints the number of iterations and yes, just as you expected, due to the `Long.MAX_VALUE` there is only a single iteration. But then I simply reduced `Long.MAX_VALUE` to `1024` and the counter reported thousands of iterations -- just as expected. Even better, the test confirmed that still the number of reported bytes is still correct just as the file contents are.

Hence in case sendfile *limits* the number of transferred bytes in production use, this quick check has proven that the code *is correct* and everything *actually* works fine.

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

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