RFR (S) 8223472: volatile long field corruption on x86_32

[coleen.phillimore at oracle.com]

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