Value types and access atomicity

[Paul Sandoz]

Hi Alexey,

See https://openjdk.java.net/jeps/401#Enforcing-instance-validation

What you observe is the proposed default behavior, with the following to enable atomicity:

- mark the field as volatile (dunno if the implementation currently supports this); and

- a possible feature to add a (to be determined) class modified on the class. 

VHs will require some spec/impl adjustment. Atomic VH access to a plain field of non-atomic primitive class is gonna be problematic (fail? or global lock, yuck!).

I believe the implementation technique at the moment is to not flatten volatile fields. I am not aware of any attempts to optimize for say smaller sizes (e.g. seq locks), or those that fit in 64 bits.

Paul.

> On May 25, 2021, at 8:32 AM, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> 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
>