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.dui...@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
