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

Vitaly Davidovich vitalyd at
Wed Feb 23 01:46:12 UTC 2011

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.

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

More information about the core-libs-dev mailing list