jdk.internal.misc.Unsafe.weakCompareAndSwapObject

[Andrew Haley]

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.

Andrew.