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

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Feb 11 11:09:46 PST 2014

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


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.

More information about the hotspot-compiler-dev mailing list