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.
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:
>
> https://urldefense.proofpoint.com/v2/url?
>
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
>
>
