RFR: 8166842: String.hashCode() has a non-benign data race

[Vitaly Davidovich]

On Wednesday, September 28, 2016, David Holmes <david.holmes at oracle.com>
wrote:

> On 28/09/2016 10:44 PM, Peter Levart wrote:
>
>> Hi,
>>
>> According to discussion here:
>>
>> http://cs.oswego.edu/pipermail/concurrency-interest/2016-
>> September/015414.html
>>
>>
>> it seems compact strings introduced (at least theoretical) non-benign
>> data race into String.hasCode() method.
>>
>> Here is a proposed patch:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8166842_String.
>> hashCode/webrev.01/
>>
>
> I'm far from convinced that the bug exists - theoretical or otherwise -
> but the "fix" is harmless.
>
> When we were working on JSR-133 one of the conceptual models is that every
> write to a variable goes into the set of values that a read may potentially
> return (so no out-of-thin-air for example). happens-before establishes
> constraints on which value can legally be returned - the most recent. An
> additional property was that once a value was returned, a later read could
> not return an earlier value - in essence once a read returns a given value,
> all earlier written values are removed from the set of potential values
> that can be read.
>
> Your bug requires that the code act as-if written:
>
> int temp = hash;
> if (temp == 0) {
>    hash = ...
> }
> return temp;

It's the other way I think:

int temp = hash; // read 0
if (hash == 0) // reread a non 0
     hash = temp = ...
 return temp // return 0

It's unlikely but what prohibits that?

>
> and I do not believe that is allowed.
>
> David
>
>
>> For the bug:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8166842
>>
>>
>>
>> JDK 8 did not have this problem, so no back-porting necessary.
>>
>> Regards, Peter
>>
>>

-- 
Sent from my phone