2007/7/5, Tim Ellison <[EMAIL PROTECTED]>:
Jimmy,Jing Lv wrote:
> 2007/7/4, Tim Ellison <[EMAIL PROTECTED]>:
>> Sorry for being so dumb, but how can you devise an expression that will
>> produce a better bucket index from a hashcode if you don't know anything
>> about the characteristics of the hashcode?
>>
>
> Ah, I really don't know how to produce a better bucket index from a
> hashcode if I don't know anything about the characteristics of the
> hashcode. So I just take hypothesis that the hashcode should be random
> itself, and in this scenario can we go further to do some tuning.
> All suggestion here is used for HashMap implementation, as we dicussed
> before (maybe also good for hash-related classes ;) )

Ok, just checking ;-)
So how about I commit the proposed changes to make the numBuckets a
power of two, with a hashCode modification that does the simple right
shift to accommodate the existing VM identityHashCode implementations?


Hi Tim,

    I'm not strongly against this commit, but just as I explained in
the first mail, to make the numBuckets a power of two (&(bucketsize -
1)) is always good, but the simple right shift (>>2) may cause some
benchmark improved (properly in these benchmarks hashcode is directly
identityHashCode) while others are reduced (hashcode are
user-defined). A known reduced benchmark is specjbb.
   I don't know when will vm improve their hashcode implementation,
and different vms will re-act to this at different time, so I doubt
the best way for applying simply shift ( >>2 ) is waiting for vm to
improve themselves and do no change to classlib. However this is not a
very urgent issue :)

   int bucket = (hashCode >>> 2) & (numBuckets - 1);

Once the VMs improve their hashcode implementation this will still work
as well, but we can remove the shift too.

Regards,
Tim



--

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

Reply via email to