[aarch64-port-dev ] Aarch64 port for ZGC, so far

[Andrew Dinn]

On 23/11/2018 11:46, Stuart Monteith wrote:
> This is due to a combination of the graph generated in
> ZBarrierSetC2::make_cas_loadbarrier and apparently the memory barrier
> handling in aarch64.ad that Roland recently changed in "8209420: Track
> membars for volatile accesses so they can be properly optimized". This
> is easily triggered in the C2Example.java file I've linked to above,
> where calls to Unsafe.compareAndSwapObject provoke the issue.
I can see why this is going wrong when UseBarriersForVolatile is false.
Roland's patch ensures that the Release and Acquire membars which
bracket a CompareAndSwap node are cross-linked and that the CAS feeds
the Acquire. This is needed to allow the membars to be translated to
empty instruction sequence iff the CompareAndSwap node translates to
ldaxr/stlxr or to hw cas. The alternative sequence is dmb ldaxr stxr dmb.

ZGC is breaking this because it's way of adding a barrier around the
CompareAndSwap node involves planting a secondary CAS. It tries the CAS
once and, if it fails, massages the compared pointer and executes the
second CAS on the assumption that the compare might include stale
pointer bits. With the current implementation only one of these CASes
can be tracked between the point where the leading and trailing barriers
are planted. The result is that the secondary CompareAndSwap node is
linked to the trailing membar but the primary CAS is left dangling with
no such link. Hence the assert.

I'm not sure why this fails when UseBarriersForVolatile is true.
However, it may be that the linking of the Acquire as a direct feed of
the secondary CAS is a problem. That CAS is only executed conditionally
on the first CAS failing. If the memory flow is not ordered correctly
then this might risk allowing the first CAS to complete and bypass the
necessary trailing dmb. I could struggle through this code but it is
probably best to ask Roland to look at it.

regards,


Andrew Dinn
-----------