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

Brian Goetz brian.goetz at
Wed Feb 23 15:38:22 UTC 2011

Ignore my comment -- I was reading the diffs backwards :(

On 2/22/2011 11:53 PM, Brian Goetz wrote:
> I think you have a potential visibility problem here. You use -1 as the
> initial value, but observing threads might see instead the default value
> if the initializing write is not visible, and mistakenly think that the
> zero default value represents a computed value. (This is different from
> the trick employed by String.hashCode(), which does not use an
> initializer. Can you get the same result using zero instead?)
> The key to making the String.hashCode() trick work is that, while there
> is definitely a data race, it is benign because the field can only ever
> take on one non-default value, and that value is computed
> deterministically from immutable state.
> On 2/22/2011 7:29 PM, Mike Duigou 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:
>> 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