RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale (original) (raw)

Frederic Parain frederic.parain at oracle.com
Fri Feb 24 09:06:05 UTC 2012

Making String.intern() more scalable doesn't seem to be a solution for short (or medium?) time frame. Even if the computation cost of ObjectName.equals() is increased by this fix, there's no performance measurement in favor or against this change. I've looked for benchmarks stressing the ObjectName class, but I haven't found one yet.

Using java.util "Set" or "Map" introduces new issues, like the memory footprint and new synchronizations to protect consistency of the collection.

The Ops-Center team is stuck with this scalability issue for two years now. They have identified the problem in JDK6 and we're not able to provide them with a solution for JDK7 or JDK8.

David, I agree that I have no data about the impact on other use-cases, but I know that the use of String.intern() cannot be easily workaround. We can remove the use of String.intern() and if the performance of the new ObjectName.equals() method really becomes a performance bottleneck for other use-cases, them we can re-work this method to improve its performance. But I'd prefer not starting complex optimizations on a method without having real indication that it causes real performance issues.

Fred

On 2/23/12 11:23 PM, Keith McGuigan wrote: >> Making String.intern() more scalable has been on our list of > things-to-do for a long, long time. But, it's not trivial. Simply > increasing the size of the hashtable is no good because we'd be upping > our footprint unconditionally, so really we want a growing hashtable > which is a bit more effort (though not impossible, of course, it just > hasn't bubbled up to the top of the priority list). >> Another problem with using 'intern()' is that when you intern a string > you're placing it into the permgen, and space there is at a premium. (no > perm gen project will hopefully fix this soon). >> If you really want to use == instead of "equals()", you can use a > java.util "set" or "map" data structure and stash all of your strings in > there. Then you'll have canonicalized references that == will work upon, > and you won't run into the intern() scalability (or concurrency) issues. >> -- > - Keith >>> On 2/23/2012 4:53 PM, David Holmes wrote: >> Hi Fred, >>>> java.lang.ObjectName? :) Need to fix that. >>>> So often we intern strings precisely so that equals() can use == to >> improve performance. >>>> It seems to me that this is a case of "fixing" something for one >> use-case without knowing what the impact will be on other use-cases! >>>> Is there perhaps a solution that makes String.intern more scalable? >>>> David >> ----- >>>> On 24/02/2012 1:36 AM, Frederic Parain wrote: >>> This a simple fix to solve CR 6988220: >>> http://bugs.sun.com/bugdatabase/viewbug.do?bugid=6988220 >>>>>> The use of String.intern() in the ObjectName class prevents >>> the class the scale well when more than 20K ObjectNames are >>> managed. The fix simply removes the use of String.intern(), >>> and uses regular String instead. The Object.equals() method >>> is modified too to make a regular String comparison. The >>> complexity of this method now depends on the length of >>> the ObjectName's canonical name, and is not impacted any >>> more by the number of ObjectName instances being handled. >>>>>> The Webrev: >>> http://cr.openjdk.java.net/~fparain/6988220/webrev.00/ >>>>>> I've tested this fix with the jdklang and jdkmanagement >>> test suites. >>>>>> Thanks, >>>>>> Fred >>>

Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com

More information about the core-libs-dev mailing list