[aarch64-port-dev ] openjdk atomics

[Andrew Haley]

On 02/11/2014 05:58 PM, Andrew Dinn wrote:
> On 11/02/14 17:42, Andrew Haley wrote:
>> On 02/11/2014 04:23 PM, Andrew Dinn wrote:
>>> On 11/02/14 16:06, Andrew Haley wrote:
>>>> . . .
>>>> It may be that this doesn't matter, but I would surely prefer to have a
>>>> CAS that didn't have this property, and I'm sure we're in no position
>>>> to audit all of C2 to make sure that it doesn't matter.
>>>
>>> Well, it's not that difficult to determine.
>>
>> Well, yes it is.  You'd have to determine how the Store{LI}Conditional
>> and CompareAndSwap{ILNP} are used in order to determine whether the
>> barriers are needed.
> 
> What I meant was it's not too difficult to determine the obvious cases
> where we can avoid the dmb i.e the fastlock/fastunlock operations. Which
> appears to be something you are happy to do.
>
> Actually, the other instructions which employ cmpxchg are not that
> difficult to identify the scope of. Store{LI}Conditional nodes are used
> very sparingly -- they are introduced in macro.cpp, in one place to
> update the heap top when not using TLAB allocation and in another two
> places in the biased locking code. Each CompareAndSwapX gets introduced
> in library_call.cpp to implement the various corresponding intrinsic
> methods in class Unsafe. So, the audit required is really quite small.

The former is the eden_allocate case, and I think it doesn't need any
barriers.  MonitorExit wants a full barrier, not just a store release:
that's guaranteed by the MM spec.

I think that Unsafe is going to need either C2 to be made much smarter
or we'll have to use both full barriers.

Andrew.