This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


  Math.abs(System.identityHashCode(key) % (table.length >> 1)) << 1;

I just saw that the hash function does not do what I had in mind
yesterday.  And it should not be necessary to grow the table in
y-direction when we can make sure that each cluster gets filled up to
75%.

The reason why the old code worked and the new doesn't is that, with the
given hash function, the old code built clusters of 8 elements while the
new code distributes the keys all over the hash table leaving no room
for an additional key if a key or tombstone has occupied its place.

So I think we should document that we rely on System.identityHashCode to
return locations at 8, 16, ..  When we use an initial size of e.g. 24 we
can double the size of the hash table without worrying that the hash
structure gets destroyed; if one cluster overflows, the additional
keys/tombstones will be stored in the following clusters, eventually the
hash grows and the keys are distributed and the tombstones thrown out.

Should I provide a patch/bug report?


Jost


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]