_Jv_HashCode

Wed May 10 08:37:00 GMT 2000

Tom Tromey wrote:
>> Per> If you change _Jv_Hash so that System.identityHashCode(OBJ) is
> Per> no longer equals to (jint)(OBJ) then the gdb output syntax
> Per> probably no longer makes sense.
>> I'm not too concerned about that. Does anybody rely on the fact that
> these two are equivalent? Maybe I'm unusual in that it never occurs
> to me to exploit, or even remember, that information.

Sun's javadoc says they are equivalent:
public static native int identityHashCode(Object x)
Returns the same hashcode for the given object as would be returned by
the default
method hashCode(), whether or not the given object's class overrides
hashCode(). 
The hashcode for the null reference is zero. 
> Per> But the interned string hash table isn't using _Jv_Hash I trust?
> Per> It is presumably hashing on the *contents* of the string, not its
> Per> location.
>> Oops, you're right. But it will come up in another situation, if I
> add a hash table to keep synchronization objects. I guess I can
> always make a hash table which isn't a power of 2.

Hashing on an object's address doesn't strike me as terribly useful in
any case. I make a habit of always overriding hashCode/equals in any
class whose instances may ever be part of a collection.
It seems to me that synchronization objects could provide their own hash
algorithm as well.
-- 
Jeff Sturm
jeff.sturm@appnet.com