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

[Vitaly Davidovich]

Hi Mike,

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.

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