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

Fri Jan 28 08:18:00 GMT 2005

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/