RFR: 8016538: volatile double access via Unsafe.cpp is not atomic
Yumin Qi
yumin.qi at oracle.com
Tue Jul 9 15:44:52 PDT 2013
Vladimir,
On 7/9/2013 2:16 PM, Vladimir Kozlov wrote:
> Hi Yumin,
>
> load_acquire() could be more expensive with this changes even for
> 64bit VM because you first loading from volatile address into local
> variable. Please, check what code is generated in 64-bit with your
> changes.
>
This is for 64 bits:
without changeset:
0x00007ffff7890d67 <+167>: movsd -0x48(%rbp),%xmm0
0x00007ffff7890d6c <+172>: movsd %xmm0,-0x58(%rbp)
with changeset:
0x00007ffff785ac2b <+75>: movsd -0x48(%rbp),%xmm0
0x00007ffff785ac30 <+80>: movsd %xmm0,-0x58(%rbp)
They are same.
Anyway, I will use macro to guard the code to keep original form in 64
bit. Will send out another version of webrev.
Thanks
Yumin
> Why you did not use release_store_fence() in
> OrderAccess::release_store_fence() and where is cast to jlong* ?
>
> Thanks,
> Vladimir
>
> On 7/9/13 11:32 AM, Yumin Qi wrote:
>> Hi,
>>
>> Can i have your codereview of this change:
>> Unsafe_Get[SET]DoubleVolatile are not atomic on 32bit x86 linux
>> caused test for
>> org.openjdk.concurrent.torture.tests.atomicity.primitives.reflect.DoubleAtomicityTest
>>
>> failed.
>> The fix is using same treatment for jdouble as for jlong. Tests
>> passed on failed test case, vm quick tests. It only happens on linux
>> 32bit platform, on solaris, the inlined code be compiled into code of
>> using fldl/fstpl which are atomic instructions.
>>
>> Contributed by: dholmes
>>
>> URL: http://cr.openjdk.java.net/~minqi/8016538/01
>>
>> Thanks
>> Yumin
More information about the hotspot-runtime-dev
mailing list