Dismal performance of String.intern()

Steven Schlansker stevenschlansker at gmail.com
Mon Jun 10 23:01:28 UTC 2013

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.

Sorry to double-reply, but I thought it worthwhile to note that the time to intern strings via ConcurrentHashMap is measured in the low double-digit nanoseconds on my machine, so this may indeed end up being nontrivial.  But I will consider it trivial unless I can measure it to be large.

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

More information about the core-libs-dev mailing list