RFR (XS) 8152380 - Shared symbol/string tables should never use alternate hashcode

[Jiangli Zhou]

+1

Thanks,
Jiangli

> On Mar 25, 2016, at 6:47 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> 
> Ioi,
> This looks good.  Thank you for fixing this.
> 
> http://cr.openjdk.java.net/~iklam/jdk9/8152380_shared_table_rehashing.v02/src/share/vm/classfile/symbolTable.cpp.udiff.html
> 
> Can you add a 1 line comment at line 209, something like
> // hash_code parameter may use alternate hashing algorithm but the shared table always uses the same original hash code
> (ie. why you have this if statement).
> 
> thanks,
> Coleen
> 
> On 3/25/16 12:01 AM, Ioi Lam wrote:
>> Please review a very small fix:
>> 
>> http://cr.openjdk.java.net/~iklam/jdk9/8152380_shared_table_rehashing.v02/ 
>>    https://bugs.openjdk.java.net/browse/JDK-8152380
>> 
>> Summary of fix:
>> 
>> I added a new function, SymbolTable::hash_shared_symbol(), that does not
>>    use the alternate hashing algorithm.
>> 
>>    To validate the fix, I added new test cases that force alternate hashing
>>    while CDS is enabled (thus we have a shared symbol/string tables).
>>    Unfortunately the tests are in closed repos.
>> 
>>    Testing showed that the problem existed only for the shared symbol table.
>>    The shared string table already did not use the alternate hashing algorithm.
>> 
>> Tests:
>> 
>>    JPRT
>>    RBT with hotspot tests
>> 
>> Thanks
>> - Ioi
>