compacting _Jv_Utf8Const

Thu May 6 00:08:00 GMT 2004

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/