RFR (S): 8033380: Experimental VM flag to enforce access atomicity

[Igor Veresov]

On Feb 12, 2014, at 12:20 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> On 02/12/2014 12:13 AM, Igor Veresov wrote:
>> On Feb 11, 2014, at 9:43 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
>>> Please look at the updated webrev here:
>>> http://cr.openjdk.java.net/~shade/8033380/webrev.03/
> 
> Thanks for the review!
> This patch passes full JPRT cycle.
> 
>> Well, it is correct, but do you really need to deopt on 64bit?
>> May be put the check of the field type in LP64_ONLY() ? 
> 
> I think experimental-wise, it is safer to go through the nuisance of
> deopt on 64bit with -XX:+AAA, because it will make changes: a) safer,
> since it follows the route of volatile accesses, and makes final machine
> code correct by construction; b) coherent, since 32/64 bit builds will
> go through the same sequence of deoptimizations.

With volatile it must deopt because it may need to emit much more loads that otherwise were possibly eliminated (because it optimistically assumed the unknown field is not volatile). I’d a least put a comment that deopting on 64bit is unnecessary, and that long stores on 32bit need to be handled specially when this becomes a product feature.

igor


> 
> -Aleksey.