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

[Igor Veresov]

For C1 you also have to consider the “patching” case.

For correctness you need to at least do something like:
diff --git a/src/share/vm/c1/c1_Runtime1.cpp b/src/share/vm/c1/c1_Runtime1.cpp
--- a/src/share/vm/c1/c1_Runtime1.cpp
+++ b/src/share/vm/c1/c1_Runtime1.cpp
@@ -839,11 +839,9 @@
     // is the path for patching field offsets.  load_klass is only
     // used for patching references to oops which don't need special
     // handling in the volatile case.
-    deoptimize_for_volatile = result.access_flags().is_volatile();
+    patch_field_type = result.field_type();
+    deoptimize_for_volatile = result.access_flags().is_volatile() || (AlwaysAtomicAccesses && is_access_not_atomic(patch_field_type));

-#ifndef PRODUCT
-    patch_field_type = result.field_type();
-#endif
   } else if (load_klass_or_mirror_patch_id) {
     Klass* k = NULL;
     switch (code) {

Where is_access_not_atomic(type) will have to be defined for each architecture to check if a regular store of a given type is atomic. I guess it’s only T_LONG on 32bit?

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. 

igor
 

On Feb 11, 2014, at 3:02 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> Hi,
> 
> I understand we are still closed for integration?
> 
> Please review this small feature meanwhile:
>  https://bugs.openjdk.java.net/browse/JDK-8033380
>  http://cr.openjdk.java.net/~shade/8033380/webrev.02/
> 
> TL;DR: JMM 9 may need to extend the access atomicity over longs and
> doubles. Luckily, our logic in emitting the relevant access-atomic
> instructions is decoupled from memory barriers logic, and so we can
> "just" unconditionally go through needs_atomic_access where appropriate.
> 
> Testing:
> - full cycle JPRT
> - targeted microbenchmarks on x86/ARM/PPC
> 
> Thanks,
> -Aleksey