Dismal performance of String.intern()

[Steven Schlansker]

On Jun 10, 2013, at 3:55 PM, Andrew Haley <aph at redhat.com> wrote:

> On 06/10/2013 07:06 PM, Steven Schlansker wrote:
>> 
>> I discovered that replacing String.intern() with a ConcurrentHashMap
>> improved performance by almost an order of magnitude.
>> 
>> I'm not the only person that discovered this and was surprised:
>> http://stackoverflow.com/questions/10624232/performance-penalty-of-string-intern
>> 
>> I've been excited about starting to contribute to OpenJDK, so I am
>> thinking that this might be a fun project for me to take on and then
>> contribute back.  But I figured I should check in on the list before
>> spending a lot of time tracking this down.  I have a couple of
>> preparatory questions:
>> 
>> * Has this bottleneck been examined thoroughly before?  Am I wishing
>> too hard for performance here?
>> 
>> * String.intern() is a native method currently.  My understanding is
>> that there is a nontrivial penalty to invoking native methods (at
>> least via JNI, not sure if this is also true for "built ins"?). 
> 
> That's not really true.  For simple JNI methods I've measured the
> overhead in nanoseconds.
> 
>> I assume the reason that this is native is so the Java intern is the
>> same as C++-invoked interns from within the JVM itself.  Is this an
>> actual requirement, or could String.intern be replaced with Java
>> code?
> 
> I don't think that replacing intern() with Java code is a great place
> to begin.  Surely your first plan should be to improve the performance
> of the C++ version.  Maybe the only problem is that it needs a better
> hash table.  Rather than get into complex re-engineering of VM
> startup, this might be an easy fix.

OK, sounds reasonable.  I only mentioned moving it to Java because that's what I know and I already have shown it to be fast enough.  I'll see if I can hack the C++ code into faster shape preferentially.