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

Coleen Phillimore coleen.phillimore at oracle.com
Fri Mar 25 13:47:19 UTC 2016


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



More information about the hotspot-runtime-dev mailing list