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

[Coleen Phillimore]

Here's another webrev with the changes pointed out by Tobias and 
verified with -XX:+VerifyStringTableAtExit.

open webrev at http://cr.openjdk.java.net/~coleenp/8144940.02/webrev

Thanks!
Coleen

On 3/22/16 12:21 PM, Tobias Hartmann wrote:
> 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