CDV ❯ potential perf issue in ConcurrentHashMap
-
Bug
-
Status: Resolved
-
2 Major
-
Resolution: Won't Fix
-
DSO:L1
-
-
interfaces
-
Reporter: wharley
-
March 05, 2009
-
0
-
Watchers: 2
-
February 12, 2014
-
February 12, 2014
Description
Our implementation of ConcurrentHashMap does some work to ensure that it uses a hash code that will be the same across all nodes. For objects with hash code based on Object.hashCode(), for instance, it shares the object and then creates a hash based on ObjectID.
There are two methods that this logic shows up in, ConcurrentHashMapTC.__tc_hash() and __tc_isDsoHashRequired(). (Note these names may change a bit in the fix for CDV-1160.) The first calculates the DSO-stable hash; the second checks whether an object can possibly be a key to the CHM (for instance, if it would need a DSO hash but it has not been shared, then it must not be a key) in order to shortcut some lookups.
There is duplicated effort between these two methods. For instance, both methods call ManagerUtil.overridesHashCode(), which requires looking up the superclass chain reflectively searching for a method. I suspect the pattern is something like “if (!__tc_isDsoHashRequired()) return null; int hash = __tc_hash(); …” in which case many of these checks are being done twice.
I wonder if there is a way to refactor these two methods so that redundant effort could be avoided? Seems like an opportunity for perf improvement. At the very least we should check that compound boolean expressions are ordered in the most efficient way.
DSO is discontinued