Hi,
Loosely related to this topic, there is some local variable caching of
comparableClassFor() result already being performed inside
iterative/recursive methods of TreeNode, but this caching is just
positive caching, meaning that null return is not cached. For keys that
happen to implement Comparable, but are not simple-self-comparable
(their class is not of the form: class C implements Comparable<C>),
reflection is invoked each time comparison of the search key with Node
key is attempted. This can be improved:
http://cr.openjdk.java.net/~plevart/jdk9-dev/HM.comparableClassFor/InCallNegativeCache/webrev.01/
Using modified version of Bernd's benchmark (adding 3rd variant of keys
- FalseComp):
http://cr.openjdk.java.net/~plevart/jdk9-dev/HM.comparableClassFor/InCallNegativeCache/HashMapCollision.java
...and and only running for badHash shows almost 25% improvement for
FalseComp keys (skipping reflection invocations) and barely measurable
improvement for NoComp keys (skipping instanceof checks), while Comp
keys are not affected.
Original JDK9 HashMap:
Benchmark (initialSize) Mode Samples
Score Error Units
j.t.HashMapCollision.badDistFalseComp 16 ss 20
4221.438 +- 250.774 ms
j.t.HashMapCollision.badDistNoComp 16 ss 20
2868.605 +- 40.754 ms
j.t.HashMapCollision.badDistWithComp 16 ss 20
3030.780 +- 111.315 ms
Patched:
Benchmark (initialSize) Mode Samples
Score Error Units
j.t.HashMapCollision.badDistFalseComp 16 ss 20
3237.953 +- 143.608 ms
j.t.HashMapCollision.badDistNoComp 16 ss 20
2643.024 +- 137.067 ms
j.t.HashMapCollision.badDistWithComp 16 ss 20
3087.902 +- 122.041 ms
Regards, Peter
