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/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.par...@oracle.com
