RFR: 8265448: (zipfs): Reduce read contention in ZipFileSystem [v4]

[Alan Bateman]

On Thu, 6 May 2021 00:03:20 GMT, Jason Zaugg <jzaugg at 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