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

StringTable::intern is slow

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Fixed
    • Icon: P4 P4
    • 24
    • None
    • hotspot
    • b25

      When we intern a string object, as part of the lookup strategy, we create a resource mark, and then copy the string contents byte by byte to a temporary native string. Then we compute the hash code (which not uncommonly was already precomputed in the original string object), doing a bunch of math byte by byte. Once this is done and we have looked up in the CDS table and the main table without finding an existing string, we find that we need to create a new string object (which again we already had in the first place). But... this seemingly redundant allocation can lead to GC safepoints, so we put in a HandleMark and litter Handles everywhere to deal with allocating this string object (that we already had). Then we copy the bytes back from the temporary native string into the new Java string object.

      This seems way less efficient than it needs to be. We should be able to just do the lookup with the original passed in string, using the pre-computed hash code when available, and insert that original string if no string is in the string table yet.

            cnorrbin Casper Norrbin
            eosterlund Erik Ă–sterlund
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: