Re: 4.0.0 JNI/reflection invocation 2/4/8 times as slow as in 3.3.3

[Andrew Haley <aph at redhat dot com>]

Ranjit Mathew writes:
 > Ranjit Mathew wrote:
 > > 
 > > Instead of changing over to chaining, the current open
 > > addressing implementation can perhaps be redeemed by
 > > using a compacting remove(), eliminating the need for
 > > tombstones.
 > 
 > Our implementation of the default hash code method
 > is also not good enough - it doesn't "scatter" objects
 > well enough. It's just a remainer of the object's
 > address expressed as a number with (2^31 - 1). (See
 > _Jv_HashCode in libjava/include/jvm.h.)
 > 
 > Since objects, at least initially, tend to get
 > allocated near each other and aligned on word
 > boundaries, we get highly biased results.

Yes, but the hash code isn't supposed to be a stringly random
function, and it doesn't need to be if we're using a prime table size.

 > 142757720
 > 142757712
 > 142757704
 > 142757696
 > 142757688
 > 142757680
 > 142757672
 > 142757664
 > 142757656
 > 142757648
 > ---------------------------- 8< ----------------------------
 > 
 > With Sun's JDK 1.4.2_03 on Linux I get something like:
 > ---------------------------- 8< ----------------------------
 > 7494106
 > 23671010
 > 17332331
 > 18464898
 > 28168925
 > 15655788
 > 17237886
 > 8187137
 > 28050664
 > 7754385
 > ---------------------------- 8< ----------------------------
 > 
 > That said, modulo operations with small odd divisors do
 > seem to give a fairly pseudo-randomised results even with
 > our current implementation, so this might not be *that*
 > big an issue in practice.

Right.  The remainders mod 11 of the hash values above are:

6
9
1
4
7
10
2
5
8
0

Perhaps, though, some application programs might depend on a stronger
hash function.  I what some suitably fast candidates might be.  For
addresses we could do something really simple like a few rotations and
XORs, followed by taking the result mod 2^31.

Andrew.