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

[Ranjit Mathew <rmathew at gmail dot com>]

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.

A simple program illustrates this:
---------------------------- 8< ----------------------------
public class HashTest
{
  public static void main(String[] args)
  {
    for( int i=0; i < 10; i++)
    {
      System.out.println( System.identityHashCode( new Object()));
    }
  }
}
---------------------------- 8< ----------------------------

The output with current mainline on Linux is something like:
---------------------------- 8< ----------------------------
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.

Ranjit.

-- 
Ranjit Mathew      Email: rmathew AT gmail DOT com

Bangalore, INDIA.    Web: http://ranjitmathew.hostingzero.com/