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