Ignore my comment -- I was reading the diffs backwards :(
On 2/22/2011 11:53 PM, Brian Goetz 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
