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

[Igor Veresov]

On Feb 11, 2014, at 9:43 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> Thanks Igor!
> 
> Please look at the updated webrev here:
>  http://cr.openjdk.java.net/~shade/8033380/webrev.03/

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() ? 

> 
> More comments below:
> 
> On 02/11/2014 04:10 PM, Igor Veresov wrote:
>> But anyway, you’re going to deopt on all long accesses to unknown
>> long fields in C1. If you want to go full speed, then you would need
>> to generate special patchable accesses for longs on 32bit.
> 
> I have hard time understanding why do we need this. I think I miss
> something from the patching logic. Patched volatile long field access
> causes deoptimization, and presumably it compiles to proper volatile
> store the next time around? The same should be happening with plain long
> accesses with -XX:+AlwaysAtomicAccesses: second compilation should turn
> the accesses really atomic.
> 
> What's that "full speed" you are concerned about? Time-to-performance
> degradation caused by potentially more de-optimizations?

Exactly.

> If so, I think that's a fair price for the experimental running mode. If/when we switch
> to real atomic accesses should the spec mandate us to, we can optimize
> this more thoroughly.

Fair enough.

igor


> 
> -Aleksey.