Value types and access atomicity

[Frederic Parain]

> On May 25, 2021, at 12:14 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> 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. 

An atomicity requirement can be added to a primitive class by making it implementing
the java.lang.NonTearable interface (temporary name).

Fred

> 
> 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
>> 
>