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

[Peter Jones]

This change seems good all around.  In addition to fixing the noted
race, it removes a substantial amount of redundant instance footprint
from a class whose instances are not infrequently collected in
significant numbers-- fields most of which just served methods that
are essentially never used in critical code anyway.  Of course
hashCode is used, but it's not computationally like String.hashCode.

Agree with Alan that the code for variant() requires an extra stare to
make sense of, so more comment might be helpful-- otherwise looks good
to me.

-- Peter


On Tue, Feb 22, 2011 at 7:29 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