RFR: 8278268 - (ch) InputStream returned by Channels.newInputStream should have fast path for FileChannel targets [v7]
Markus KARG
duke at openjdk.java.net
Mon Dec 13 17:26:44 UTC 2021
On Mon, 13 Dec 2021 16:50:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - Simplified using checked function
>>
>> Signed-off-by: Markus Karg <markus at headcrashing.eu>
>> - Common implementation for all 2 GB tests
>>
>> Signed-off-by: Markus Karg <markus at headcrashing.eu>
>
> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 301:
>
>> 299: }
>> 300: bb.clear();
>> 301: pos += bytesRead;
>
> I've been busy so only getting to this PR now.
>
> Since we are guaranteed that src is configured blocking then the only remaining reason for transferFrom to return 0 is when EOF is reached. Can we drop the temporary buffer and just replace the buffer in the block with:
>
> long n;
> while ((n = dst.transferFrom(src, pos, Long.MAX_VALUE)) > 0) {
> pos += n;
> }
I would say "yes, for the channels being part of the JRE", and have adopted your proposal in https://github.com/openjdk/jdk/pull/6711/commits/3c1d8af58e65b6aa5d373c69f7e29e1f10010dc1. The only risk I see (and hence I wrote that originally complex code) is that *in theory* anybody is technically able to implement a **custom** `ReadableByteChannel` (as it is a public interface) which does return zero *intermittently* while the end of stream is not reached. `transferFrom` in that case will also return zero. Hence the loop would terminate *(possibly long) before* EOF is reached.
So do we ignore this hypothetical case?
-------------
PR: https://git.openjdk.java.net/jdk/pull/6711
More information about the nio-dev
mailing list