Review CR #6611830: UUID thread-safety and performance improvements

[Brian Goetz]

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