RFR: Move save/restore vector registers into ShenandoahBarrierSetAssembler

Roman Kennke rkennke at redhat.com
Thu Nov 15 18:54:28 UTC 2018


I took at look at our additions of
MacroAssembler::save_vector_registers() and
MacroAssembler::restore_vector_registers(). I turns out that we have (at
least) two other similar implementations of this: one in
sharedRuntime_x86_64.cpp and one in c1_Runtime1_x86.cpp. After a day of
experimentation, I come to the conclusion that ours is different enough
from the other two (and the other two different enough from each other)
that it is far from trivial to consolidate them. At the same time, it
seems like a hard sell to upstream to add one more implementation of
basically the same thing without consolidating the other two as well.
Let's not open this can of worms now, and move both new methods under
ShenandoahBarrierSetAssembler for now. We can sort it out later.

(Side notes: I tried to use push/pop_FPU_state() and it seemed to work,
but I suspect I was only lucky because, I believe, push_FPU_state() only
pushes the lower parts of xmm0..xmm15, and not the rest of it. I am not
sure if FPU spilling would be restricted to those. Also, there seems to
be a rather easy way out of this in the form of xsave/xrstore, which can
save, e.g., only a subset of registers, including xmm0..xmm31, etc, but
I found it hard to figure out how to configure that).

http://cr.openjdk.java.net/~rkennke/saverestorevectors/webrev.00/

Testing: tier3_gc_shenandoah

Ok?

Roman



More information about the shenandoah-dev mailing list