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

[Erik Österlund]

On Wed, 1 Mar 2023 09:25:58 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> 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?

Note also that the arraycopy stubs were already using r8 and r9 as temp registers. I just moved their use to GC barriers, so only they need to deal with their inherent scratchyness, while the temp registers used in the client code can use registers that are not scratchy, which was not the case before.

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

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