RFR(S): 8087143: Reduce Symbol::_identity_hash to 2 bytes
Aleksey Shipilev
aleksey.shipilev at oracle.com
Wed Jun 24 09:55:51 UTC 2015
Hi Ioi,
On 06/23/2015 10:28 PM, Ioi Lam wrote:
> I assume by "address" you mean
>
> ((unsigned)((this) >> (LogMinObjAlignmentInBytes + 3)));
Yes.
> I think for performance reasons we are storing a random number in the
> Symbol instead of computing the hashcode base on the string value.
> The intention of this RFE not to change that, but just use fewer
> random bits to accomplish the same goal. Yes, we are assuming a
> particular hashtable implementation, but I don't think we are going
> to change that any time soon.
...
> And if we ever change the hash function
> to heavily depend on the top 16 bits of the hash code, we can
> certainly revert back to a 32-bit random number.
This sounds awfully similar to introducing the technical debt.
Succumbing to this practice means you will have to make an avalanche
modification once you need to do a little change in hash table
implementation, given somebody actually remembers to change the hash
function. I'm not keen of introducing these dependencies without a
*very* good reason to.
In this example, if there is a hash function that returns a 32-bit
value, please make sure the value is random in all 32 bits. If that
proves hard, then the memory footprint savings (what, 1K out of 3626K,
if I read the data right?) does not worth the hassle of complicating the
hash function beyond reasonable, and introducing undocumented
dependencies that will eventually backfire.
Thanks,
-Aleksey
More information about the hotspot-runtime-dev
mailing list