Review CR #6611830: UUID thread-safety and performance improvements
vitalyd at gmail.com
Wed Feb 23 13:36:18 UTC 2011
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?
> 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
>>> 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.
> 617-548-7007 (mobile)
More information about the core-libs-dev