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

[Andrew Dinn]

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