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

[Keith McGuigan]

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