RFR: 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code

[Roman Kennke]

On Wed, 27 Jan 2021 14:59:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 159:
>> 
>>> 157:       __ jcc(Assembler::zero, done);
>>> 158: 
>>> 159:       save_machine_state(masm, /* handle_gpr = */ true, /* handle_fp = */ true);
>> 
>> IIRC, it is ensured in arraycopy prologue and epilogue that no FPU state is active (I can probably research why), and it may affect performance of tiny arraycopies (which are more frequent than I'd like).
>
> OK, I was going for the overkill of over-saving registers for interpreter code. But you are right, this might be problematic. We could do `/* handle_fp = */ false` here, so it would save only the generic registers?

Ah yes, Look in stubGenerator_x86_64, copy_bytes_forward() and copy_bytes_backward(), those generate fast copy routines that use FP registers. If those registers were live in the arraycopy code paths, those routines would trash it.

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

PR: https://git.openjdk.java.net/jdk/pull/1172