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

Igor Veresov igor.veresov at oracle.com
Tue Feb 11 12:13:26 PST 2014

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.

More information about the hotspot-compiler-dev mailing list