RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation

[Dmitrij Pochepko]

Hi Andrew,

Overall looks good, but I have few minor comments regarding these tests:

1. Most tests which spawn other precesses for testing purposes are 
launched as "@run driver ..." for optimization reasons.

2. Do we really need to ignore external vm options set in jtreg via 
option: -javaoptions:"<additional options>"? In case these tests 
shouldn't ignore external options, there is 
ProcessTools.createJavaProcessBuilder(boolean addTestVMAndJavaOptions, 
String... command) for that.

3. This test will fail if jdk will be built without all GCs or without 
C2. It probably a good idea to split it in few tests with separate GC 
configurations

4. In case external options are not ignored, you'll need to filter out 
several vm options, like skipping execution for c1 or interpreter 
testruns. Something like this can be added: @requires vm.compMode != 
"Xint" & vm.flavor == "server" & (vm.opt.TieredStopAtLevel == null | 
vm.opt.TieredStopAtLevel==4)

Thanks,
Dmitrij


On 26.06.2018 19:55, Andrew Dinn wrote:
> Reviews are welcome for the following webrev
>
>    webrev: http://cr.openjdk.java.net/~adinn/8205694/webrev.00/
>    JIRA: https://bugs.openjdk.java.net/browse/JDK-8205694
>
> The patch:
> ----------
>
> This AArch64-only patch adds tests to ensure that volatile load, store
> and CAS operations are either:
>
>    translated to correctly replace memory barriers with combinations of
> acquiring loads and releasing
>
>    left untransformed with all necessary memory barriers in place
>
> The test requires a debug, aarch64 vm and is disabled if graal is being
> used (debug is necessary because it relies on -XX:+PrintOptoAssembly to
> provide evidence of what is in the compiler output).
>
> The main driver test program creates subordinate JVMs to execute
> subordinate programs which perform:
>
>     normal and unsafe volatile loads,
>     normal and unsafe volatile stores
>     unsafe volatile CASes
>
> in each of 5 GC configurations:
>
>    G1
>    CMS+CondCardMark
>    CMS-CondCardMark
>    Parallel
>    Serial
>
> Arguments -XXCompileCommand,compileonly and XX:+PrintOptoAssembly are
> used to generate Assembly listings and the driver test program parses
> these to ensure the correct sequences of instructions are generated
> (including omitted memory barriers which are flagged in the output).
>
> A few changes were made to the aarch64.ad file to ensure that the
> PrintOptoAssembly output accurately represented the generated code.
> These were necessary to ensure that the test could be sure that the
> generated code sequences really were what was intended.
>
> Also, some of the comments in aarch64.ad describing the code
> transformation were updated following feedback from Zhongwei Yao that
> arrived too late to get checked in with the fix for JDK-8204331.
>
> Testing:
> --------
>
> The test itself passes when run on an AArch64 debug vm. It is ignored
> when run on an AArch64 product vm.
>
> No other testing is needed. Nothing significant in the aarch64.ad file
> has been modified (only comments of format sequences which have been
> exercised running the new test).
>
> 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