RFR (S): 8033380: Experimental VM flag to enforce access atomicity
Aleksey Shipilev
aleksey.shipilev at oracle.com
Tue Feb 11 09:43:53 PST 2014
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