[concurrency-interest] Does JDK 9 String.hashCode() have a bug?

Aleksey Shipilev shade at redhat.com
Wed Sep 28 07:37:25 EDT 2016


On 09/28/2016 01:28 PM, Jonas Konrad wrote:
> On 09/28/2016 12:38 PM, Aleksey Shipilev wrote:
>> P.S. Your explanation is similar to a more detailed of mine here:
>>
>> https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-benign-is-resilient
> 
> Wouldn't, according to that section in your blog, the old hashcode (and
> the suggested fix) also be unsafe? 

Why unsafe? JDK 8 String.hashCode is a classic example of the benign
data race. It's benignity comes, as with other benign data races, from
two conditions:

 a) The object being published is safely constructed. In this particular
case, we publish the primitive value, and it is safe by definition.

 b) We read the field only once, which is exactly what JDK 8
String.hashCode does, but JDK 9 String.hashCode lacks.

JDK 8:

  public int hashCode() {
    int h = hash;  // <--- read once
    if (h == 0) {  // <--- not 0? proceed to return
      for (char v : value) {
        h = 31 * h + v;
      }
      if (h != 0) {
        hash = h;
      }
    }
    return h;  // <--- return the verified value, DO NOT racy read again
  }

> From what I can tell the hashcode in Java 8 already assumed (which it
> can because it's JDK code) that the VM inserts a memory barrier in
> the String constructor because of the final value field.

Note this is *within* the String instance already, no "final value field
init in String" applies here.

Thanks,
-Aleksey




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160928/192e19ab/attachment.sig>


More information about the Concurrency-interest mailing list