RFR (S) 8144940: Broken hash in string table entry in closed/runtime/7158800/BadUtf8.java

Tobias Hartmann tobias.hartmann at oracle.com
Tue Mar 22 16:21:19 UTC 2016


Hi Coleen,

On 22.03.2016 13:40, Coleen Phillimore wrote:
> On 3/22/16 4:04 AM, Tobias Hartmann wrote:
>> Hi Coleen,
>>
>> On 21.03.2016 22:11, Coleen Phillimore wrote:
>>> Summary: Fix code broken with compact Strings.
>>>
>>> One of the failure modes of an intermittent bug (but this failure is not intermittent).
>>>
>>> Tested with the failing test cases that exercise this code. Also, testing in order to find linked bugs.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144940.01/webrev
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144940
>> I wonder why the result is different if you first convert the latin1 String to Unicode and then use the jchar hash_string() version compared to just using the jbyte hash_string() version? Is it because the jbyte version of AltHashing::murmur3_32() is used?
> 
> Yes, I believe it is.

Okay, thanks for checking.

>> Now we don't need the StringTable::hash_string<jbyte> version anymore, right?
> 
> This one is used by Symbol* which are jbyte.

I only see jchar uses of StringTable::hash_string() (after your fix). Are you confusing it with java_lang_String::hash_code() which also has a jbyte and jchar version? This one is indeed used by the SymbolTable.

>> Just noticed that there is an unused "latin1_hash_code" in javaClasses.hpp which can be removed as well.
> 
> Thank you, I'll remove it.

Thanks!

Best regards,
Tobias

>>
>> Thanks for fixing this!
> 
> Thanks for reviewing it!
> Coleen
>>
>> Best regards,
>> Tobias
>>
>>> Thanks,
>>> Coleen
> 


More information about the hotspot-runtime-dev mailing list