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