[jmm-dev] bitwise RMW operators, specifically testAndSetBit/BTS
Doug Lea
dl at cs.oswego.edu
Mon Jul 25 13:24:37 UTC 2016
On 07/25/2016 04:54 AM, Andrew Haley wrote:
> On 20/07/16 20:16, Doug Lea wrote:
>> Or, in pseudo-VarHandle style using "getM" (for varying Ms):
>>
>> static VarHandle PX = MethodHandles.lookup().findVarHandle(Point.class, "x",
>> int.class);
>>
>> void f(Point a, Point b) {
>> int r1 = PX.getM(a);
>> int r2 = PX.getM(b);
>> int r3 = PX.getM(a); // *
>> use (r1, r2, r3);
>> }
>>
>> Can you simplify (*) to "r3 = r1" ? It depends on M:
>> * Java-Plain and C++-Plain: yes.
>> * Java Opaque: no.
>> * C++-Relaxed: only if a != b.
>> * (And, for the record, other modes: no)
>>
>> This is one reason "opaque" mode is needed.
>
> But the processor hardware is allowed to simplify (*) to "r3 = r1" even
> if Opaque is used. So, again, why does it matter?
>
The existence of one case where it may not matter doesn't mean
that it is always OK (consider loops), and so the best practical
answer for compilers is "no" here.
(Arguably, it should similarly be "no" for C++-relaxed, depending in
part on whether "coherence" is defined to entail progress properties
by the memory system (as cache memory-system specs normally do)
especially given the C++17 updates about execution progress.)
The issue of merging reads is in many ways symmetric to that of
inserting writes. For example when spilling registers, JVMs
never store transient garbage-values into possibly-visible
home locations of variables, even though there may be cases
where they could.
Coming up with a formal model and spec that clearly delineates legal
transformations hits a lot of "little" issues along these lines.
-Doug
More information about the jmm-dev
mailing list