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

SymbolTable and StringTable bucket arrays are probably too small

    Details

    • Type: Enhancement
    • Status: Closed
    • Priority: P4
    • Resolution: Duplicate
    • Affects Version/s: 7
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • CPU:
      generic
    • OS:
      generic

      Description

      James Gosling asked me how String.intern worked, so I pointed him at the code. While I was in there I worried about the sizes of the bucket arrays for the SymbolTable (20011) and the StringTable (1009). Those sizes might have been appropriate in 1997 when they were checked in, but the world has grown up around them. Running HelloWorld with -XX:+PrintSymbolTableSizeHistogram shows

          Symbol Table:
           Total 182619
           Maximum 1316
           Average 9.13
          ....
           Number chains longer than 100: 83

      which isn't going to lead to the best performance during class loading (when symbolOops get added to the table). There isn't a similar flag for printing out the statistics for the StringTable, but one can imagine applications that intern 10's of 1000's of Strings, leading to the same kind of crush on the StringTable bucket chains, and the same kinds of performance problems for String.intern().

      I was also disappointed to find that symbol_table_size and string_table_size can't be changed, e.g., via develop flags. That makes them hard to experiment with. We might want to add product flags to size them, to offer a workaround for users for whom, e.g., String.intern() is a performance bottleneck, or who load orders of magnitude more classes than we were planning for.

      (The fact that the printing code is only willing to count elements in int's, rather than size_t's should be addressed too.)

        Attachments

        1. 6610955.zip
          2.13 MB
        2. hotspot.patch
          87 kB
        3. webrev.zip
          2.12 MB

          Issue Links

            Activity

              People

              • Assignee:
                gziemski Gerard Ziemski
                Reporter:
                pbk Peter Kessler (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: