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

[Dmitrij Pochepko]

On 27.06.2018 16:05, Andrew Dinn wrote:
> On 27/06/18 13:29, Dmitrij Pochepko wrote:
>> On 27.06.2018 13:54, Andrew Dinn wrote:
>>> Hi Dmitrij,
>>>
>>> On 26/06/18 19:33, Dmitrij Pochepko wrote:
>>>> Overall looks good, but I have few minor comments regarding these tests:
>>> Thanks for reviewing the patch.> I'm not an official reviewed though
> That's ok. You don't need to be an official reviewer to offer review
> comments :-)
>
>>>> 1. Most tests which spawn other precesses for testing purposes are
>>>> launched as "@run driver ..." for optimization reasons.
>>> I'm using the Process API so I can retrieve and analyze the output
>>> written to the spawned JVM's stdout. Is it possible to do that using
>>> "@run driver"?
>> yes
> Well, that's good to know ;-) but still could you explain how or point
> at an example?
it's the same as for @run main. External vm options are stored by jtreg 
in several vm properties: test.vm.opts and test.java.opts (for 
-vmoptions and -javaoptions respectively), so, process tools use it in 
case you call createJavaProcessBuilder with first parameter == true. 
Here is an example how this could be done: 
gc/arguments/TestUseNUMAInterleaving.java
>
>>> However, I don't understand how splitting the tests up is going to help
>>> deal with the either of the two config omissions you are concerned
>>> about.
>> It is a test granularity question. Splitting tests will reduce time for
>> failure diagnostic. When looking at test report it makes a difference at
>> first glance to see: TestVolatiles.java failed or TestVolatilesG1.java
>> failed, or all TestVolatiles*.java failed. If you think this granularity
>> is fine, then let it be.
> Ok, I take your point about granularity of failure. I'll address this in
> the next webrev.
>
>>> If I have misunderstood how the @requires config works and how splitting
>>> the tests up would improve clarity of test outcomes then I'd be happy to
>>> be corrected here.
>> It's not like that. vm.flavor doesn't check flags. It parse vm property
>> "java.vm.name".
>> vm.gc.* are also not that simple. You can check how additional
>> "requires" properties are constructed in
>> test/jtreg-ext/requires/VMProps.java
> Ah, ok, thanks for pointing me at that. All I had been able to decipher
> up to now was what the jtreg code was doing. I didn't know that there
> was an extension package in the JVM test tree that allowed JVM
> capabilities to be identified. I'll use that to extend the requires
> predicate for the tests.
>
> 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