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

[Vitaly Davidovich]

resending as I just realized I replied only to Brian.

On Wed, Feb 23, 2011 at 12:19 AM, Vitaly Davidovich <vitalyd at gmail.com>wrote:

> Hi David/Brian,
>
> Yes, I meant whether the "entire" string.hashcode technique can be used,
> including the default zero values.  I agree on the initial -1 assignment
> possibly not being visible across cores, leading to incorrect results.
>
> David, I did not see the actual bug report -- is there a link to it?
>
> Cheers,
> Vitaly
>
> On Tue, Feb 22, 2011 at 11:53 PM, Brian Goetz <brian.goetz at oracle.com>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:
>>>
>>> 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
>>>
>>
>
>
> --
> Vitaly
> 617-548-7007 (mobile)
>



-- 
Vitaly
617-548-7007 (mobile)