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