jdk.internal.misc.Unsafe.weakCompareAndSwapObject

[Andrew Dinn]

On 24/02/16 18:05, Andrew Haley wrote:
> On 02/24/2016 06:04 PM, Andrew Dinn wrote:
>> On 24/02/16 17:33, Andrew Haley wrote:
>>> On 02/24/2016 05:29 PM, Andrew Haley wrote:
>>>> What are the semantics of Unsafe.weakCompareAndSwapObject?
>>>> These methods seem to be undocumented.
>>>>
>>>> Here's my guess:
>>>>
>>>> compareAndSwapObject : acquire, release
>>>> weakCompareAndSwapObject: nothing
>>>> weakCompareAndSwapObjectAcquire: acquire
>>>> weakCompareAndSwapObjectRelease: release
>>>
>>> ...but not all of these seem to have C2 graph nodes.  I can only see
>>> WeakCompareAndSwapX and CompareAndExchangeX.
>>>
>>> I'm guessing that WeakCompareAndSwapX corresponds to no acquire
>>> and no release; CompareAndExchangeX is an acquire and a release.
>>
>> Are you making this change for AArch64? If so then the important
>> question here is whether these are generated in graph shapes which
>> include a MemBarAcquire or MemBarRelease. The AArch64 predicates which
>> elide the barriers for these nodes are tuned only to the presence of
>> CompareAndSwapX and expect to see a MemBarAcquire or MemBarRelease
>> wrapped around it. They will not currently match subgraphs which contain
>> these other nodes or which omit the membars.
> 
> We've now got WeakCompareAndSwapX and compareAndExchangeX.
> 
> The weak variants shouldn't affect the barrier removal code because
> there won't be any barriers to remove.  However, the strong variants
> have new names.  I'm guessing that we'll need to change this:
> 
>   bool is_CAS(int opcode)
>   {
>     return (opcode == Op_CompareAndSwapI ||
> 	    opcode == Op_CompareAndSwapL ||
> 	    opcode == Op_CompareAndSwapN ||
> 	    opcode == Op_CompareAndSwapP);
>   }
> 
> to add in the strong (but not the weak) variants of CAS.

Yes, agreed that to handle CompareAndExchangeX all that needs changing
is to add the associated opcodes to this method -- that's assuming that
the subgraph containing a CompareAndExchangeX node still contains the
leading MemBarRelease and trailing MemBarAcquire that we also see
generated for CompareAndSwapX. If so then the remaining predicates
should recognise CompareAndExchangeX as a CAS needing acquire+release
semantics and should inhibit translation of the MemBarRelease and
MemBarAcquire to a dmb.

However, I am not sure about WeakCompareAndSwapX.

I was under the impression from Aleksey's earlier comments and the patch
proposed for JDK-8148146 that the plan was for translation of
weakCompareAndSwapObjectRelease and weakCompareAndSwapObjectAcquire to
generate a subgraph which wraps a WeakCompareAndSwapX node within a
leading and trailing MemBarCPUOrder that also contains, respectively,
only the leading MemBarRelease or only the trailing MemBarAcquire.

If that plan is adopted then the rule predicates will need a small tweak
to recognise this new, slightly different configuration:

  - translation of a WeakCompareAndSwapX node would change according to
which of these membar nodes is present (neither ==> cas or ldxr+stxr,
leading  MemBarRelease only ==> casl or ldxr+stlxr, trailing
MemBarAcquire ==> casa or ldaxr+stlr, both ==> error!)

  - translation of the MemBarAcquire or MemBarRelease to a dmb will need
to be inhibited in all cases where a WeakCompareAndSwapX is found in the
graph.

I think it's relatively straightforward to modify the predicates to
identify these extra cases/make the encoding plant the relevant cas or
ldxr/stxr flavour based on graph shape.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul
Argiry (US)