_Jv_HashCode

Wed May 10 15:20:00 GMT 2000

Tom Tromey wrote:
> 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.

Don't the HashTable and HashSet classes depend on a fairly good
distribution of hashCode() values? I think performance for these classes
is suffering when Objects that don't override hashCode() are used as
keys.
To accomodate copying collectors, we may eventually want to use the
current sync_info field to store a hashcode and perhaps other GC
bookkeeping information. However, doing a right shift of the object
address seems like a good solution for now.
regards
 [ bryce ]