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

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


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/view_bug.do?bug_id=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 jdk_lang and jdk_management
>>> 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