RFR: 8341594: Use Unsafe to coalesce reads in java.util.zip.ZipUtils [v2]

[Claes Redestad]

On Sun, 6 Oct 2024 15:53:55 GMT, Eirik Bjørsnøs <eirbjo at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright
>
> src/java.base/share/classes/java/util/zip/ZipUtils.java line 195:
> 
>> 193:      * The bytes are assumed to be in Intel (little-endian) byte order.
>> 194:      */
>> 195:     public static final long get64(byte[] b, int off) {
> 
> This method returns a signed 64 bit value, which I think is not what some of its call sites expect. It should in any case be renamed to `get64S` to align with `get32S`. A new method `get64` should be introduced and any call site expecting unsigned numbers (most?) should use that instead.
> 
> If you don't want to deal with this in this PR, I could file an issue and suggest a PR for this. Let me know.

As it's a pre-existing issue I'd prefer to keep this one focused on the switch-over. How would you model unsigned long values here, though? Sure we could read into a `BigInteger` or accept negative values, but to really support such overflows we might have to rework a lot of things. 

FWIW we already cap some values even lower in practice:

                            end.centot = (int)centot64; // assume total < 2g

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789215898