Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8243469

Lazily encode name in ZipFile.getEntryPos

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 15
    • Component/s: core-libs

      Description

      Current implementation of ZipFile.getEntryPos takes the encoded byte[] of the String we're looking up. Which means when looking up entries across multiple jar files, we allocate the byte[] over and over for each jar file searched.

      By refactoring the ZipFile hash table to save a String-normalized hash value rather than a hash of the encoded value, we can avoid this allocation most of the time when the entry is not found in the jar/zip, while also getting the benefit of the caching of String.hashCode.

      For jar files or any zip using UTF-8 encoding, calculating such hashes during open (initCEN) is easy to get as fast for ASCII entries. We could make the cost negligible for non-ASCII.

      Experimental patch: http://cr.openjdk.java.net/~redestad/scratch/zipfile_string_hash.01

      Instrumenting cost of ZipFile.getEntry shows a ~120ms improvement on Spring PetClinic, roughly 2.5-3% of total.

        Attachments

          Activity

            People

            • Assignee:
              redestad Claes Redestad
              Reporter:
              redestad Claes Redestad
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: