_Jv_HashCode

[Bryce McKinlay]

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 ]