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

[Zhongwei Yao]

Hi, All,

Thanks for your quick response and explanation!


On 3 March 2018 at 01:21, Andrew Dinn <adinn at redhat.com> wrote:
> 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
Is it in library_call.cpp file? Because I do not find libray_kit.cpp
in current repo.

> 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



-- 
Best regards,
Zhongwei