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

[Vladimir Kozlov]

C2 code is fine.  I am not familiar with C1. You need review from Igor and Roland for it.

Thanks,
Vladimir

On 2/11/14 9:43 AM, Aleksey Shipilev wrote:
> Thanks Igor!
>
> Please look at the updated webrev here:
>    http://cr.openjdk.java.net/~shade/8033380/webrev.03/
>
> 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? 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.
>
> -Aleksey.
>