Hi Keith, > 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).
Actually that's fixed already, in 6962931 and a couple of related fixes later. - Kris On Fri, Feb 24, 2012 at 6:23 AM, Keith McGuigan <keith.mcgui...@oracle.com>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<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/<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 >>> >>>
