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.)