[aarch64-port-dev ] jcstress varhandles.DekkerTest fails on aarch64

Andrew Dinn adinn at redhat.com
Fri Mar 2 17:21:04 UTC 2018


Hi Zhongwei,

On 02/03/18 11:24, Andrew Dinn wrote:
> On 02/03/18 11:06, Zhongwei Yao wrote:
>> I find this failure on aarch64 and but have not found the root cause
>> yet. Because it may have an impact on nearby jdk10 release, I raised a
>> bug first: https://bugs.openjdk.java.net/browse/JDK-8198950
> . . . 
> I'll take a look to see if I can find what is going on.
I looked into this and it relates to a change made some while back by
Roland:

JDK-8181211: C2: Use profiling data to optimize on/off heap unsafe accesses

The relevant change is in library_kit.cpp when creating a LoadNode. It
modifies the case where the load is from a heap address 1) for an object
type 2) that is known to be non-null and 3 employing an offset that is
known to lie within the object. In that case the control for the load is
set to NULL, allowing the read to float upwards. This invalidates the
expectation built into the AArch64 back end that a volatile load will be
dominated by a CPUOrder membar which projects both control and memory to
the LoadNode. As a result the back end foes not transform the ldar; dmb
sequence into an ldar instruction.

Rolands change is not invalid -- a volatile LoadNode will still be
dominated by the CPUOrder membar's memory input so cannot actually
float. However, it is arguably inapropriate -- the CPUOrder membar is
quite arguably a dominator for any control feed to the load.

There are two possible fixes:

  change the AArch64 back end to only look for a dominating memory feed

  use the membar as the control feed if this is a volatile operation.

I will push a patch inplementing the former change which I have already
verified is a fix your dekker test (I still need to check it doesanot
cause any other regressions). I chose this solution for two reasons.
Firstly, I believe it is a more 'correct' graph i.e it reprsents the
right control flow. Secondly, it only needs a one-line change to revert
to the original graph layout whereas rewriting the AArch64 back end
would require changes in several places to ensure it detects the
modified layout. An RFR will follow soon.

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 aarch64-port-dev mailing list