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

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

Thanks Vladimir!

-Aleksey.

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