Dismal performance of String.intern()

Andrew Haley aph at redhat.com
Mon Jun 10 22:55:42 UTC 2013

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.


More information about the core-libs-dev mailing list