[jmm-dev] bitwise RMW operators, specifically testAndSetBit/BTS

[Andrew Haley]

On 19/07/16 09:39, Paul Sandoz wrote:
> 
>> On 19 Jul 2016, at 09:59, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 18/07/16 20:31, Doug Lea wrote:
>>>> On 07/18/2016 02:27 PM, Andrew Haley wrote:
>>>>> On 18/07/16 12:43, Paul Sandoz wrote:
>>>>>> - for the read or write method, plain is the default.
>>>>>>
>>>>>> - for read-modify-write methods volatile is the default volatile
>>>>>>   - rename weakCompareAndSet to weakCompareAndSetPlain
>>>>>
>>>>> Why "plain"?  Is this the same as C++ "relaxed"?
>>>
>>> In this case, yes. But Java-plain is not necessarily always the
>>> same as C++ relaxed, so we've been cautious with namings.
>>
>> Mmmm, but it's baffling for me, and I've been involved for a long
>> time.  We have "Opaque" and now "Plain".  What is the difference
>> between them?  I haven't seen these terms anywhere else.  Is this new
>> terminology?
> 
> Plain behaves like non-volatile/non-final field access e.g. like
> get/putfield byte codes.
> 
> Both plain and opaque have “no assurance of memory ordering effects
> with respect to other threads” but opaque is stronger in the sense
> that the compiler is restricted in what optimisations it may
> perform, in a sense the access is “opaque” to the compiler e.g. it
> cannot elide the access or fold it into a more recent access etc.

OK, but if the processor can reorder accesses (and satisfy them from
local caches) in the absence of fences, why is this a distinction that
is worth bothering about?  And how on Earth would you make such a
distinction in the context of a high-level language specification?

> A good example is presented in Aleksey’s VarHandles slides #55
> 
>   http://shipilev.net/talks/jpoint-April2016-varhandles.pdf

Thanks.

> I am still holding off updating the specifications to clarify, as
> Doug may have cooking some foundational tweaks from which we can
> build upon.

I look forward to seeing that.

Andrew.