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

[Roman Kennke]

On Wed, 11 Nov 2020 19:00:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> $ CONF=linux-x86-server-fastdebug make images run-test TEST=compiler/c1/Test6855215.java TEST_VM_OPTS="-XX:+UseShenandoahGC"
> 
> # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3047), pid=1427307, tid=1427311
> # Error: assert(VM_Version::supports_sse2()) failed
> 
> V [libjvm.so+0x53f9e8] Assembler::movsd(Address, XMMRegisterImpl*)+0x168
> V [libjvm.so+0x14647bd] save_xmm_registers(MacroAssembler*)+0x9d
> V [libjvm.so+0x1465d8f] ShenandoahBarrierSetAssembler::load_reference_barrier(MacroAssembler*, RegisterImpl*, Address, ShenandoahBarrierSet::AccessKind)+0x91f
> 
> This only affects x86_32, as x86_64 uses at least UseSSE >= 2 at all times.
> 
> Additional testing:
>  - [ ] `tier1`, Linux x86_64 `-XX:+UseShenandoahGC`
>  - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC`
>  - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=0`
>  - [ ] `tier1`, Linux x86_32 `-XX:+UseShenandoahGC -XX:UseSSE=1`

Looks good, but I have questions.

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).

src/hotspot/cpu/x86/stubGenerator_x86_32.cpp line 3683:

> 3681:       __ movflt(Address(rsp, xmm_size * 1), xmm1);
> 3682:       __ movflt(Address(rsp, xmm_size * 0), xmm0);
> 3683:     }

I am not sure that we should sneak in this shared-code change with what is otherwise a Shenandoah-change.

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

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