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