RFR: 8341597: ZipFileInflaterInputStream input buffer size uses uncompressed size

[Eirik Bjørsnøs]

On Mon, 7 Oct 2024 01:52:59 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipFile.java line 417:
>> 
>>> 415:                     if (size > 65536) {
>>> 416:                         size = 8192;
>>> 417:                     }
>> 
>> Not sure if this clamping makes sense? We clamp the size at 8192, but only when size is larger than 65536?
>> 
>> Wondering if we should simply clamp to 8192 instead:
>> 
>> 
>> Suggestion:
>> 
>>                    int size = Math.clamp(CENSIZ(zsrc.cen, pos), 2, 8192);
>
> I'm curious if it would be beneficial to increase the max clamp size to 16384 bytes similar to https://bugs.openjdk.org/browse/JDK-8299336 / https://github.com/openjdk/jdk/pull/11783
> 
> Suggestion:
> 
>                     int size = Math.clamp(CENSIZ(zsrc.can, pos), 2, 16384);

Yes, there may be benefits in increasing this max buffer size for larger entries, but I think that requires a more extensive analysis and discussion than what want to do in this PR.

99 percent of classes in guava.jar have a compressed size less than ~6700 bytes. The average compressed size is ~1300 bytes.

So this does not seem to matter for class loading, which is probably what ZipFile is most optimized for.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21379#discussion_r1789692897