Value types and access atomicity

Aleksey Shipilev shade at redhat.com
Tue May 25 15:32:19 UTC 2021


Hi there,

I am updating the jcstress examples about access atomicity, and wonder what is the accepted state of 
value type atomicity? For example, see this test:

     @JCStressTest
     @Outcome(id = "0, 0",  expect = Expect.ACCEPTABLE, desc = "Seeing the default value: writer had 
not acted yet.")
     @Outcome(id = "1, 1", expect = Expect.ACCEPTABLE, desc = "Seeing the full value.")
     @Outcome(expect = Expect.ACCEPTABLE_INTERESTING, desc = "Other cases are allowed, because 
reads/writes are not atomic.")
     @State
     public static class ValueTypes {
         static primitive class Value {
             long x;
             long y;
             public Value(long x, long y) {
                 this.x = x;
                 this.y = y;
             }
         }

         Value v = Value.default;

         @Actor
         public void writer() {
             v = new Value(1, 1);
         }

         @Actor
         public void reader(JJ_Result r) {
             Value tv = v;
             r.r1 = tv.x;
             r.r2 = tv.y;
         }
     }

On x86_64, this yields:

RESULT     SAMPLES    FREQ       EXPECT  DESCRIPTION
   0, 0   1,244,897    2.4%   Acceptable  Seeing the default value: writer had not acted yet.
   0, 1           4   <0.1%  Interesting  Other cases are allowed, because reads/writes are not at...
   1, 0      51,540    0.1%  Interesting  Other cases are allowed, because reads/writes are not at...
   1, 1  49,608,697   97.5%   Acceptable  Seeing the full value.

That is understandable behavior, as the atomic read of 128-bit-wide Value is not guaranteed to be 
supported on underlying hardware. Is this the accepted behavior? Are there any plans to change it? 
(If not, I should probably work on eliminating the experimental AlwaysAtomicAccesses option we did 
for JMM 9, as it would be rendered moot...)

-- 
Thanks,
-Aleksey



More information about the valhalla-dev mailing list