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

[David Holmes]

Hi Vitaly,

Vitaly Davidovich said the following on 02/23/11 11:46:
> Unless i missed something, seems like the race can be fixed via same
> mechanics as String.hashcode; ie since all of the cached values are based on
> least and most significant bits which are final and the long members are
> volatile, using lazy evaluation with use of temps should yield the same
> results even to racing threads, making the race benign.

Are you able to see the actual bug report for this? The key point is 
that the -1 "uninitialized" values of the fields are not guaranteed to 
be seen, so if zero is seen instead the wrong calculation will be done 
for the variant and hashcode. The conclusion is that the simplest fix is 
to not bother with lazy evaluation and caching for any of these fields.

David Holmes

> Vitaly
> On Feb 22, 2011 7:30 PM, "Mike Duigou" <mike.duigou at oracle.com> 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