[aarch64-port-dev ] barrier use in JDK11

[Andrew Dinn]

On 14/06/18 20:37, Andrew Haley wrote:
> On 06/14/2018 06:59 PM, Dave Nuechterlein wrote:
>> I suspect the issue is that there are no customizations for
>> xgene3/emag1 in cpu/aarch64/vm_version_aarch64.cpp.>
> It certainly could be that.

I doubt very much that is the problem. The only customization that
affects translation of dmb;ldr;dmb to ldar is the CPU_DMB_ATOMICS
feature which, when set, will to update the default value for command
line option UseBarriersForVolatile to true. This is only set in one case

  if (_cpu == CPU_CAVIUM && (_model == 0xA1)) {
    if (_variant == 0) _features |= CPU_DMB_ATOMICS;
     . . .

So, unless xgene3/emag1 is masquerading as an A1 Cavium variant 0 . . .

I think a more likely cause is the recent GC changes which have buggered
around with the shape of the C2 idela graphs (not for any particularly
good reason). If you are really using the latest JDK11 repo tip for your
build then that is certainly going to affect some volatile stores and
CAS operations. I'm currently working on a patch for these but have not
yet tested the ldar translation. I'll take a look and let you know if
there is an obvious problem with the latter.

>> Are there any guidelines or best practices on how to do an initial
>> vm_version variant?  What test should I run before submitting a
>> patch, etc.
> 
> As long as your processor supports proper lrar/stlr you're good. Test
> it with jcstress.  Make sure that UseBarriersForVolatile is off.

Yes, if you explicitly set -XX:-UseBarriersForVolatile on the command
line the reset in vm_version will be ignored and the translation to ldar
will be attempted. If it fails in that case then it means the graph
shapes for loads have changed.

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