HashMap collision speed (regression 7->8)

[Peter Levart]

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