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