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

[Aleksey Shipilev]

On Wed, 27 Jan 2021 14:54:24 GMT, Roman Kennke <rkennke 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`
>
> 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?

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

This is nmethod barrier handling part, and on x86_32, Shenandoah is the only user of this code. I can split it out, but it would still be Shenandoah-specific.

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

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