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