RFR: 8302780: Add support for vectorized arraycopy GC barriers [v6]

[Erik Österlund]

On Tue, 28 Feb 2023 10:34:17 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Erik Österlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 720:
> 
>> 718:       t4 = r7, t5 = r11, t6 = r12, t7 = r13;
>> 719:     const Register stride = r14;
>> 720:     const Register gct1 = r8, gct2 = r9, gct3 = r10;
> 
> Please don't alias rscratch1 and rscratch2. Many macros use them, and this is a bug waiting to happen.

I view the GC barriers in spirit as being one of said macros, they just happen to be in a different file. We could have them in the macroAssembler file, but choose to not clutter it with GC specifics, and moved it to a different file instead.
The main reason I selected r8 and r9 for the GC temp registers, is that we have run out of C ABI caller saved registers in copy_memory. All other registers in [r0, r17] are already used, and the arraycopy stubs are called with the C ABI, hence expecting any callee saved register to either not be touched or be saved in the callee, making them poor choices for temp registers. While a different selection could be made, using for example a callee saved register such as r20 and r21, I'd have to push the registers in the prologue and pop them in the epilogue of the arraycopy stubs, which seems a bit awkward if it can be avoided. I'm open to doing that, but it doesn't spark joy. So I thought I'd explain the choice here. What do you think?

-------------

PR: https://git.openjdk.org/jdk/pull/12670