resending as I just realized I replied only to Brian. On Wed, Feb 23, 2011 at 12:19 AM, Vitaly Davidovich <vitalyd@gmail.com>wrote:

Hi David/Brian,

Yes, I meant whether the "entire" string.hashcode technique can be used, including the default zero values. I agree on the initial -1 assignment possibly not being visible across cores, leading to incorrect results.

David, I did not see the actual bug report -- is there a link to it?

Cheers, Vitaly

On Tue, Feb 22, 2011 at 11:53 PM, Brian Goetz <brian.goetz@oracle.com>wrote:

...

I think you have a potential visibility problem here. You use -1 as the initial value, but observing threads might see instead the default value if the initializing write is not visible, and mistakenly think that the zero default value represents a computed value. (This is different from the trick employed by String.hashCode(), which does not use an initializer. Can you get the same result using zero instead?)

The key to making the String.hashCode() trick work is that, while there is definitely a data race, it is benign because the field can only ever take on one non-default value, and that value is computed deterministically from immutable state.

On 2/22/2011 7:29 PM, Mike Duigou wrote:

...

Daniel Aioanei reported via Josh Bloch a data race issue with the UUID accessor and hashCode() methods. I've prepared a webrev with the suggested changes:

http://cr.openjdk.java.net/~mduigou/6611830/webrev.0/webrev/

I've tested the change against the standard UUID tests and did a microbenchmark test of one method, variant(), to see what impact not caching had on performance. Since there was only negligible change in performance vs. the existing UUID implementation I am comfortable with eliminating the cache values. It would appear that a field access plus a shift is not a significant cost over a field access.

Mike

-- Vitaly 617-548-7007 (mobile)

-- Vitaly 617-548-7007 (mobile)