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

[Erik Österlund]

On Fri, 24 Feb 2023 15:24:53 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:

>> Erik Österlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move bs declaration up
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 1223:
> 
>> 1221:     UnsafeCopyMemoryMark ucmm(this, !aligned, false, ucme_exit_pc);
>> 1222:     // Copy in multi-bytes chunks
>> 1223:     copy_bytes_forward(end_from, end_to, qword_count, rax, r10, L_copy_bytes, L_copy_8_bytes, decorators, T_BYTE);
> 
> Why is `setup_arg_regs_using_thread()` not needed to free `r10` as a temporary register in `generate_[conjoint|disjoint]_[byte|short]_copy()`? From the following comment, it sounds like it would be needed:
> 
> https://github.com/openjdk/jdk/blob/7d8b8ba9c46475ededcae7db6c841b25fa83d167/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L1193-L1195

We used to only have setup_arg_regs which saved windows callee saved registers in r10, which turned out to be horribly fragile (cf. https://bugs.openjdk.org/browse/JDK-8203466). The setup_arg_regs_using_thread() function was introduced specifically so that the windows callee save registers are *not* stored in r10, because it is a register you really don't want to rely on not getting scratched, when it is chosen as the rscratch1 register. Instead, callee save registers are saved in the thread memory area, which is much less fragile. That's why I can use r10.

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

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