RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale (original) (raw)
David Schlosnagle schlosna at gmail.com
Thu Feb 23 18:46:25 UTC 2012
- Previous message: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale
- Next message: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, Feb 23, 2012 at 12:01 PM, Frederic Parain <frederic.parain at oracle.com> wrote:
No particular reason. But after thinking more about it, equals() should be a better choice, clearer code, and the length check in equals() implementation is likely to help performance of ObjectName's comparisons as ObjectNames are often long with a common section at the beginning.
I've updated the webrev: http://cr.openjdk.java.net/~fparain/6988220/webrev.01/ Thanks, Fred
Was the main bottleneck the contention on the interned string pool that prevented concurrent addition of ObjectNames? Are there other places within the JDK where use of intern() should be analyzed for similar scalability bottlenecks? I'm also curious what the heap implications are of no longer using interned strings.
A minor nit is that the equals method could be simplified slightly, making it more clear that the canonical names must match for equality:
@Override public boolean equals(Object object) { // same object case if (this == object) return true;
// object is not an object name case
if (!(object instanceof ObjectName)) return false;
ObjectName on = (ObjectName) object;
return _canonicalName.equals(on._canonicalName);
}
Thanks, Dave
- Previous message: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale
- Next message: RFR: 6988220: java.lang.ObjectName use of String.intern() causes major performance issues at scale
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]