RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles

Andrew Dinn adinn at redhat.com
Tue Jul 5 09:47:52 UTC 2016


On 05/07/16 10:17, Andrew Haley wrote:
> On 05/07/16 08:55, Andrew Dinn wrote:
> . . .
>> So, we then added optimising rules which spot this pattern and improve
>> the generated code. They inhibit the translation of the
>> MembarRelease/Acquire and plant a ldarx stlrx pair
>>
>>
>>   ...
>>   ldarx
>>   ...
>>   stlrx
>>   ..
>>
>> which does all we need. If you are not seeing an stlrx then we have a
>> problem. Is that the case?
> 
> Yes, because the rewrite rules don't know about the new CAS nodes
> which I'm defining.  Besides that, the AArch64 back end is supposed to
> work correctly even when using +UseBarriersForVolatile.

The intention was always to update the rewrite predicates so that they
do recognise these new configurations. I think we ought to do that so we
can profit form the weaker memory model semantics. Whatever we do the
current predicates ought at least to be corrected so that they
consistently omit barriers and plant ldaxr+stlxr or plant barriers and
rely on ldxr+stlxr. If the current predicates implement some half-way
house for the new nodes that has the wrong semantics then they are borked.

I don't see why the +UseBarriersForVolatile option presents a problem.

  If the Release barrier is omitted then that means we don't generate a
Release before the cmpxchg because the caller is supposed to have taken
care of that. However, we still use stlxr in the exchange to ensure that
the swap is ordered wrt later writes.

  Ditto, if the Acquire barrier is omitted that's also because the
caller is supposed to take care of that. So, our use of ldxr when we
have +UseBarriersForVolatile ought to be fine.

What are you seeing with +UseBarriersForVolatile that is problematic?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander


More information about the hotspot-dev mailing list