RFR: 8342040: Further improve entry lookup performance for multi-release JARs [v3]

Claes Redestad redestad at openjdk.org
Fri Oct 18 13:59:33 UTC 2024


On Fri, 18 Oct 2024 12:34:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>>> One is to store the `checkedHash` rather than the full `String`. This gets `openCloseZipFile` down to ~910000 ns/op. (`checkedHash` very hot in profiles). There's still a chance for redundant lookups on hash collisions, but this should be rare.
>> 
>> Seems like a resonable trade-off.  Could you take a look at the latest 771488e and see if that represents your suggestion here?
>
> Yes, 771488e matches my quick experiment (sans some cleanups you've made). I agree this variant makes for a reasonable trade-off.

Maybe there's some benefit in detecting "META-INF/versions/" in the `checkAndAddEntry` method and then calculate the two different hash values back to back. Hash calculations are fast on modern hardware with vector support, but the memory accesses might not be so we might get a general win from re-arranging some of this stuff. I think this is more suitable for a follow-up experiment, though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21489#discussion_r1806512558


More information about the security-dev mailing list