[aarch64-port-dev ] RFR(M): 8209835: Aarch64: elide barriers on all volatile operations

[Stuart Monteith]

Hi,
    I'd like to do the same. I've came up with this:

         java -XX:+PrintAssembly  -XX:+LogVMOutput
-XX:LogFile="test-%p.log" -XX:+DebugNonSafepoints -XX:-DisplayVMOutput
-version

Of course, if the test relies on the logging being set certain
different way, there'll be more problems.

BR,
    Stuart

On Fri, 12 Oct 2018 at 19:41, Andrew Haley <aph at redhat.com> wrote:
>
> On 10/05/2018 10:10 AM, Roland Westrelin wrote:
> >
> >>> http://cr.openjdk.java.net/~roland/8209835/webrev.00/
> >>>
> >>> This adds barrier elision support for all volatile operations that were
> >>> not supported so far and extends the tests to cover all of them. I ran
> >>> full jcstress successfully with this.
> >> Yes, that looks good.
> >
> > Thanks for the review.
> >
> >> Did you also eyeball the generated code? I know jcstress ought to find
> >> any bugs but it would be good to be doubly sure :-)
> >
> > I didn't eyeball the code (there's a lot to check!). I extended tests to
> > cover all combination of atomic operations/argument types. So at least,
> > tests should guarantee that the right variant in the ad file is
> > picked. Then, of course, all variants must be correctly implemented. For
> > that, I checked a couple times that the right boolean flag was passed.
>
> I want to eyeball the code, but I just spent the last hour and a half
> trying to figure out how to get real assembly code (not OptoAssembly)
> out of jtreg. It seems incredibly difficult: everything is conspiring
> to stop it from happening. If I edit the tests so that PrintAssembly
> is passed, the tests fail.
>
> In desperation I am about to edit HotSpot so that the assembly output
> goes to a named pipe, but i can't help feeling that it really should
> be easier than this.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671