On Thu, 6 May 2021 00:03:20 GMT, Jason Zaugg <jza...@openjdk.org> wrote:
>> If the given Path represents a file, use the overload of read defined
>> in FileChannel that accepts an explicit position and avoid serializing
>> reads.
>>
>> Note: The underlying NIO implementation is not required to implement
>> FileChannel.read(ByteBuffer, long) concurrently; Windows still appears
>> to lock, as it returns true for NativeDispatcher.needsPositionLock.
>>
>>
>> On MacOS X, the enclosed benchmark improves from:
>>
>>
>> Benchmark Mode Cnt Score Error Units
>> ZipFileSystemBenchmark.read avgt 10 75.311 ? 3.301 ms/op
>>
>>
>> To:
>>
>>
>> Benchmark Mode Cnt Score Error Units
>> ZipFileSystemBenchmark.read avgt 10 12.520 ? 0.875 ms/op
>
> Jason Zaugg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Remove redundant cast from previous commit.
src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1235:
> 1233: synchronized(ch) {
> 1234: return ch.position(pos).read(bb);
> 1235: }
I think it's okay to include the update to EntryInputStream, that part looks
fine, as does the directly use of the FileChannel positional read.
I'm still mulling over the case where ch is not a FileChannel as I would
expected it to capture the existing position and restore it after the read. I
think this is the degenerative case when the zip file is located in a custom
file system that doesn't support FileChannel. In that case, positional read has
to be implemented on the most basic SeekableByteChannel. It would only be
observed when mixing positional read ops with other ops that depend on the
current position.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3853
