On Jun 10, 2013, at 3:55 PM, Andrew Haley <a...@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.
