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

[Erik Österlund]

On Thu, 2 Mar 2023 09:51:03 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> 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.
>
>> 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.
> 
> The use of scratch registers in the AArch64 GC barriers was _already_ buggy and error prone, which resulted in serious and hard-to-find bugs. If you need to use the scratch registers in stubs, please, please don't alias them. Call them `rscratch1` and `rscratch2`.
> 
> Using scratch registers is safe as long as the code follows a couple of rules. Don't alias them, and if an inner macro is called from another macro, it's often safer to pass scratch registers to the inner macro explicitly. I know we're not consistent about this.

I see. Yeah I'd love to go more and more towards the more explicit approach. I removed the aliasing so we pass in rscratch1 and rscratch2 instead of r8 and r9.

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

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