Re: compacting _Jv_Utf8Const

[Per Bothner <per at bothner dot com>]

Chris Gray wrote:

> With an 8-bit hashcode you will get so many collisions that you might as well 
> not have one (so your hashtable degenerates into a list or tree).

There are two uses for the hashCode:

(1) hash table for loaded / initialized classes, such as are used in
natClass.cc.  These need a real hash code, which should be more
than 8 bits.  (Since it's only for classes, which aren't that numerous,
an 8-bit hash may actually not be too bad, assuming it's not invoked
too often.)  A solution is to re-hashing the class name.  For example
Class.forName ends up converting the java String to a _Jv_Utf8Const.
There is no reaason we can't generate the hash code as a 32-bit hash,
and using that instead.  Even better would be to not generate the
temporary _Jv_Utf8Const in the first place.

(2) to search a list of names for matches/duplicates.  Here we just
want to speed up _Jv_equalUtf8Const, and if there are a few more
cases with matching 8-bit hash than 16-bit hash it doesn't matter,
as we'll find a mismatch in the following bytes, which will probably
be in the processor cache.  It's not clear that storing a hash value
is very useful at all, but if it's only 8-bits it's probably worth it.

One disadvantage of my suggestion I didn't mention: As _Jv_Utf8Consts
are currently 16-bit alined, we can easily compre 16 bits at a time
(see _Jv_equalUtf8Consts).  I don't think this matters much on
modern processors, where cache misses are what matters.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/