[aarch64-port-dev ] RFR: JDK-8214527 AArch64: ZGC for Aarch64

[Stuart Monteith]

(taking off hotspot-gc-dev from the discussion)

>From my experiments, as soon as I have something other than:
   for(i=0; i < n; i++) {
      a[i] = b[i] + c[i];
   }

It reverts to scalar code, such as when I add a volatile counter,

On Thu, 13 Jun 2019 at 14:16, Andrew Dinn <adinn at redhat.com> wrote:
>
> On 13/06/2019 13:59, Andrew Haley wrote:
> > On 6/13/19 1:56 PM, Andrew Dinn wrote:
> >> On 13/06/2019 13:24, Stuart Monteith wrote:
> >>> Yes, let's leave the renaming until JDK14 - I was aiming for the patch
> >>> to make JDK13, but we'll see.
> >>>
> >>> The registers are being defined here in order for the LoadBarrier for
> >>> ZGC in z_aarch64.ad to spill them while it does the barrier
> >>> correction. I had thought the vector registers would need to have
> >>> their full 128 bits spilled, if they happened to be live - this is the
> >>> same as what is done for z_x86_64.ad .
> >>
> >> Well, as far as I understand it: if the registers happened to be live
> >> with 128 bit data loaded by C2 generated code then they should get
> >> spilled as 128 bits values when an instruction is generated that KILLs
> >> the bottom 64 bits.
> >>
> >> Of course, there is also the question of what C2 ought to do to preserve
> >> incoming values in callee-save float registers. I am not sure of this
> >> but I thought callers could only expect 64 bit float register data to be
> >> saved by the callee. Is that right? Or did I make that last bit up?
> >
> > There are no callee-save float registers in the Java calling convention.
> > Phew. ;-)
> Ok, I must have eaten too much cheese one evening and dreamed it.
> Actually, I think I was misled by this ad file declaration:
>
> alloc_class chunk1(
>
>     // no save
>     V16, V16_H, V16_J, V16_K,
>     . . .
>     V31, V31_H, V31_J, V31_K,
>
>     // arg registers
>     V0, V0_H, V0_J, V0_K,
>     . . .
>     V7, V7_H, V7_J, V7_K,
>
>     // non-volatiles
>     V8, V8_H, V8_J, V8_K,
>     . . .
>     V15, V15_H, V15_J, V15_K,
> );
>
> I'm not sure if I wrote that or someone else did (my money is on Ed
> Nevill ;-)
>
> Also, thinking about it a bit more, if C2 is ever going to have 128 bits
> live in a register then that's probably ever only going to be i) in a
> self-contained intrinsic or ii) in superword code.
>
> It is only in the latter case that the question of a GC spill ought to
> arise and I am not sure the way the superword transformation is applied
> could actually mean that we would hit such a case. What do you think,
> Andrew?
>
> 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