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