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

[Claes Redestad]

On Fri, 18 Oct 2024 12:08:08 GMT, Eirik Bjørsnøs <eirbjo at openjdk.org> wrote:

>> There are a few possible strategies for avoiding that additional parse, since the effect we're getting at here is to have a quick filter to avoid pointless lookups and not necessarily an exact mapping.
>> 
>> 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.
>> 
>> Another is to store a `BitSet` per name length. This gets `ZipFileOpen` down to baseline level (~670000 ns/op), but increases chance of having to do redundant lookups a lot.
>> 
>> Both also improves footprint (not keeping each versioned entry `String` in memory would be nice).
>
>> 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.

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

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