On 1/13/20 4:44 PM, Tobi Ajila wrote:
> Hi John
>
> Given that inline types can be flattened there is a possibility that
> data races will occur in places where users were not expecting it
> before. So your `__AlwaysAtomic` modifier is a necessary tool as the
> existing spec will only enforce atomicity for 32bit primitives and
> references. I just want to confirm if the intention of the
> __AlwaysAtomic bit on an inline class is only to ensure atomic reads and
> writes of inline types and that there are no happens-before ordering
> expectations as there are with the existing volatile modifier on fields.
>
In which case "__AlwaysOpaque" would be a more accurate term.
-Doug
> For example:
>
> ```
> __AlwaysAtomic inline class Long256 { long v1, v2, v3 ,v4; … }
>
> class Example {
> Long256 bigLong;
> int x;
> int y;
>
> void method() {
> Long256 newLong = new Long256(1, 2, 3, 4);
>
> x = 1;
>
>
> //compiler is still free to re-order write to bigLong with respect
> //to writes to x and y, but the write to bigLong must be done atomically
> bigLong = newLong;
>
> y = 2;
> }
> }
> ```
>
> Does this match your expectations?
>
> The reason I ask is because of the "Protection is “as if” each field
> were volatile" wording in your previous note. Does this only speak to
> the atomicity properties of the volatile modifier? Or do you intend
> further constraints?
>
> Regards,
> --Tobi
>
>
> "valhalla-spec-experts" <valhalla-spec-experts-boun...@openjdk.java.net>
> wrote on 2019/12/18 08:46:42 PM:
>
>> From: John Rose <john.r.r...@oracle.com>
>> To: valhalla-spec-experts <valhalla-spec-experts@openjdk.java.net>
>> Date: 2019/12/18 08:47 PM
>> Subject: [EXTERNAL] atomicity for value types
>> Sent by: "valhalla-spec-experts" <valhalla-spec-experts-
>> boun...@openjdk.java.net>
>>
>> In a nutshell, here’s a proposal for value type atomicity:
>>
>> - Define a contextual keyword “alwaysatomic" (working title
> “__AlwaysAtomic”).
>> - It can only occur with “inline” in class declaration.
>> - All instances of the given inline class are protected against races.
>> - Protection is “as if” each field were volatile, “and the same” for
>> array elements.
>> - In the class file the ACC_VOLATILE bit is used (0x0040) to record
>> the keyword.
>> - This bit does not necessarily disable flattening; if the JVM can
>> get away with flattening it should.
>> - The JVM can get away with flattening such values on stack, in
>> registers, and perhaps in final heap variables.
>> - The JVM can get away with flattening such values if they are
>> “naturally atomic”, meaning they can be wholly loaded or stored in
>> one (atomic) hardware instruction.
>>
>> More details to follow. Here’s a backgrounder I wrote a while ago:
>>
>> INVALID URI REMOVED
>>
> u=http-3A__cr.openjdk.java.net_-7Ejrose_oblog_value-2Dtearing.html&d=DwIFaQ&c=jf_iaSHvJObTbx-
>>
> siA1ZOg&r=erClOruSa3K4FS7XawcTd7k9ZbtVLiryTZ1WIpneMMg&m=9WXy2DpynXX2sj1FbCiuW127ablyOD_EN13-
>> aS4ug04&s=dhRZz0Da6RYg45c_b-x6gFBP0sqXC1VtTWP--BDHMS4&e=
>>
>> — John
>>
>>
>
