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
