RFR (S) 8223472: volatile long field corruption on x86_32
Erik Osterlund
erik.osterlund at oracle.com
Mon May 13 17:40:20 UTC 2019
Still good.
/Erik
> On 13 May 2019, at 15:57, Boris Ulasevich <boris.ulasevich at bell-sw.com> wrote:
>
> Ok. Here is the updated patch with MO_RELAXED access decorator for T_DOUBLE load/store:
> http://cr.openjdk.java.net/~bulasevich/8223472/webrev.02
>
> thanks,
> Boris
>
>> On 13.05.2019 11:34, David Holmes wrote:
>>> On 13/05/2019 6:30 pm, Boris Ulasevich wrote:
>>> Hi Coleen,
>>>
>>> I added short comment, thanks! And yes, from first look it seems that double load/store needs to be marked MO_RELAXED as well, but on x86 fstp/fld is atomic, so no extra flag is actually need.
>> It may not actually be needed because of the underlying implementation but the requirement should still be captured with MO_RELAXED IMHO.
>> Cheers,
>> David
>>> thank you,
>>> Boris
>>>
>>>> On 08.05.2019 16:56, coleen.phillimore at oracle.com wrote:
>>>>
>>>> I just had a look at this and it looks unsettlingly random without a short comment why MO_RELAXED is needed for long and not the others. Is it because on 32 bits, double is two words that have to be atomically stored? Would a volatile double have the same problem? I see getfield_or_static has the MO_RELAXED and a comment, so that's good. I don't need to see a new version if you add a *short* comment like this.
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>>
>>>>> On 5/8/19 4:17 AM, Boris Ulasevich wrote:
>>>>> Hi all,
>>>>>
>>>>> Please review a simple change to fix long field store atomicity for 32-bit x86 interpreter.
>>>>>
>>>>> http://bugs.openjdk.java.net/browse/JDK-8223472
>>>>> http://cr.openjdk.java.net/~bulasevich/8223472/webrev.00
>>>>>
>>>>> thanks,
>>>>> Boris
>>>>
More information about the hotspot-dev
mailing list