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

Aleksey Shipilev aleksey.shipilev at oracle.com
Tue Feb 11 23:39:56 PST 2014

Thanks Vladimir!


On 02/11/2014 11:09 PM, Vladimir Kozlov wrote:
> 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.

More information about the hotspot-compiler-dev mailing list