RFR: 8130115: REDO - Reduce Symbol::_identity_hash to 2 bytes

[Coleen Phillimore]

This looks fine.   I'm not expert at knowing how the bitwise operators 
and shifts produce a random number so I'd like someone to verify that.

Does anyone know why the serviceability agent has to duplicate the 
Symbol identity hash and if this is used by anything?  This code change 
is fine for the duplicated SA code, but it would be nice to file an RFE 
to delete it.

Your testing looks good.

Thanks,
Coleen

On 7/15/15 1:37 PM, Yumin Qi wrote:
> Hi,
>
>   This is redo for bug 8087143, in that push, it caused failure on 
> Serviceability Agent failed to get type for "_identity_hash": 
> mistakenly used JShortField for it, but in fact it still is 
> CIntegerField. In this change, besides of the original change in 
> hotspot/src, I add code to calculate identity_hash in hotspot/agent 
> based on the changed in hotspot.
>
> Old webrev for 8087143:
> bug: https://bugs.openjdk.java.net/browse/JDK-8087143
> webrev: http://cr.openjdk.java.net/~minqi/8087143/webrev03/
>
> Summary: _identity_hash is an integer in Symbol (SymbolBase), it is 
> used to compute hash bucket index by modulus division of table size. 
> Currently in hotspot, no table size is more than 65535 so we can use 
> short instead.  For case with table size over 65535 we can use the 
> first two bytes of symbol data to be as the upper 16 bits for the 
> calculation but rare cases.
>
> New webrev for 8130115:
> bug: https://bugs.openjdk.java.net/browse/JDK-8130115
> webrev: http://cr.openjdk.java.net/~minqi/8130115/webrev01/
>
>
> Tests: JPRT, SA manual tests, -atk quick, jtreg hotspot/runtime
> Also internal large application used for hashtable data analysis --- 
> the No. of loaded classes is big(over 19K), and tested with different 
> bucket sizes including over 65535 to see the new algorithm for 
> identity_hash calculation, result shows the consistency before and 
> after the fix.
>
> Thanks
> Yumin