On Tue, 8 Oct 2024 01:14:32 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/util/zip/ZipUtils.java line 173:
>>
>>> 171: * The bytes are assumed to be in Intel (little-endian) byte order.
>>> 172: */
>>> 173: public static final int get16(byte[] b, int off) {
>>
>> Can
On Tue, 8 Oct 2024 01:05:14 GMT, Shaojin Wen wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Rename get64 -> get64S
>
> src/java.base/share/classes/java/util/zip/ZipUtils.java line 173:
>
>> 171: * The byte
On Sun, 6 Oct 2024 21:45:08 GMT, Claes Redestad wrote:
>> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
>> improve performance in zip-related microbenchmarks, but doing so would
>> increase startup overheads. Progress was stalled as we backed out some
>> related e
On Sun, 6 Oct 2024 21:45:08 GMT, Claes Redestad wrote:
>> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
>> improve performance in zip-related microbenchmarks, but doing so would
>> increase startup overheads. Progress was stalled as we backed out some
>> related e
On Sun, 6 Oct 2024 21:49:08 GMT, Claes Redestad wrote:
>>> How would you model unsigned long values here, though?
>>
>> I don't think we should. `9223372036854775807 ` should be enough for
>> everyone :-)
>>
>> It may be worth renaming the method to `get64S` and add a `get64` variant
>> which
On Sun, 6 Oct 2024 19:33:49 GMT, Eirik Bjørsnøs wrote:
>> 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
> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
> improve performance in zip-related microbenchmarks, but doing so would
> increase startup overheads. Progress was stalled as we backed out some
> related early use of `ByteArray(LittleEndian)` and started exploring m
On Sun, 6 Oct 2024 19:19:15 GMT, Claes Redestad wrote:
> How would you model unsigned long values here, though?
I don't think we should. `9223372036854775807 ` should be enough for everyone
:-)
It may be worth renaming the method to `get64S` and add a `get64` variant which
either clamps at `L
On Sun, 6 Oct 2024 15:48:57 GMT, Eirik Bjørsnøs wrote:
>> Sure, I think the JIT is pretty good at eliminating the (intrinsic)
>> `checkIndex` calls when they are redundant though. Performance with and
>> without these `checkIndex`es are the same in my testing, so we can eat and
>> have the cak
On Sun, 6 Oct 2024 15:53:55 GMT, Eirik Bjørsnøs 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 assu
On Sun, 6 Oct 2024 16:27:52 GMT, Chen Liang wrote:
>> test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java line 110:
>>
>>> 108: zf2.close();
>>> 109: }
>>> 110:
>>
>> A short comment stating the purpose of the main method would not hurt.
>
> https://github.com/openjdk/jdk/p
> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
> improve performance in zip-related microbenchmarks, but doing so would
> increase startup overheads. Progress was stalled as we backed out some
> related early use of `ByteArray(LittleEndian)` and started exploring m
On Sun, 6 Oct 2024 15:27:07 GMT, Eirik Bjørsnøs wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> copyright
>
> test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java line 110:
>
>> 108: zf2.close();
On Sun, 6 Oct 2024 14:56:27 GMT, Eirik Bjørsnøs 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/ZipFile.java line 1644:
>
>> 1642: // Now s
On Sun, 6 Oct 2024 15:48:57 GMT, Eirik Bjørsnøs wrote:
>> Sure, I think the JIT is pretty good at eliminating the (intrinsic)
>> `checkIndex` calls when they are redundant though. Performance with and
>> without these `checkIndex`es are the same in my testing, so we can eat and
>> have the cak
On Sun, 6 Oct 2024 15:14:05 GMT, Claes Redestad wrote:
>> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
>> improve performance in zip-related microbenchmarks, but doing so would
>> increase startup overheads. Progress was stalled as we backed out some
>> related e
On Sun, 6 Oct 2024 15:35:44 GMT, Claes Redestad wrote:
>> Actually if we trust the input index to be nonnegative, we can just check
>> our end index for out of bounds too.
>
> Sure, I think the JIT is pretty good at eliminating the (intrinsic)
> `checkIndex` calls when they are redundant though
On Sun, 6 Oct 2024 15:29:13 GMT, Eirik Bjørsnøs 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 258:
>
>> 256: static final long CEN
On Sun, 6 Oct 2024 15:14:05 GMT, Claes Redestad wrote:
>> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
>> improve performance in zip-related microbenchmarks, but doing so would
>> increase startup overheads. Progress was stalled as we backed out some
>> related e
On Sun, 6 Oct 2024 15:14:05 GMT, Claes Redestad wrote:
>> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
>> improve performance in zip-related microbenchmarks, but doing so would
>> increase startup overheads. Progress was stalled as we backed out some
>> related e
On Sun, 6 Oct 2024 15:11:19 GMT, Chen Liang wrote:
>> It's actually not less overhead in my tests, since `checkIndex` is intrinsic
>> and mostly disappears, while with `checkFromIndexSize` performance gets
>> significantly worse (on par with baseline). It's on my todo to investigate
>> this in
On Sun, 6 Oct 2024 15:07:02 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/util/zip/ZipUtils.java line 175:
>>
>>> 173: public static final int get16(byte[] b, int off) {
>>> 174: Preconditions.checkIndex(off, b.length,
>>> Preconditions.AIOOBE_FORMATTER);
>>> 175:
> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
> improve performance in zip-related microbenchmarks, but doing so would
> increase startup overheads. Progress was stalled as we backed out some
> related early use of `ByteArray(LittleEndian)` and started exploring m
On Sun, 6 Oct 2024 14:40:37 GMT, Chen Liang 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 175:
>
>> 173: public static final int g
On Sun, 6 Oct 2024 14:16:44 GMT, Claes Redestad wrote:
> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
> improve performance in zip-related microbenchmarks, but doing so would
> increase startup overheads. Progress was stalled as we backed out some
> related early
On Sun, 6 Oct 2024 14:16:44 GMT, Claes Redestad wrote:
> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
> improve performance in zip-related microbenchmarks, but doing so would
> increase startup overheads. Progress was stalled as we backed out some
> related early
#14632 showed that coalescing loads in the `ZipUtils` utility methods could
improve performance in zip-related microbenchmarks, but doing so would increase
startup overheads. Progress was stalled as we backed out some related early use
of `ByteArray(LittleEndian)` and started exploring merge sto
27 matches
Mail list logo
