Currently, saving and restoring registers when calling into the VM from C1/Interpreter (G1) barrier stubs with x86(_64) is quite ad-hoc, adding only code as they are thought to be actually needed.
This is wasteful on the one hand as typically all (GP) registers are pushed/popped instead of just the volatile ones, and on the other hand a bit dangerous because the code does not necessarily save what is volatile for C-called methods (particularly FP/XMM registers). Further if new callers new features are added, there is risk of crashes.
There is also the risk that this ad-hoc code does not align the stack properly (i.e. it does not for at least 32 x86 bit code).
Also it makes changes cumbersome.
This could also add opportunity to remove existing, per-collector stack management code for this purpose (i.e. ZGC and Shenandoah implement their own related methods already).
Aarch64 added a register set abstraction which looks good. Try to see if it makes sense for x86.
This is wasteful on the one hand as typically all (GP) registers are pushed/popped instead of just the volatile ones, and on the other hand a bit dangerous because the code does not necessarily save what is volatile for C-called methods (particularly FP/XMM registers). Further if new callers new features are added, there is risk of crashes.
There is also the risk that this ad-hoc code does not align the stack properly (i.e. it does not for at least 32 x86 bit code).
Also it makes changes cumbersome.
This could also add opportunity to remove existing, per-collector stack management code for this purpose (i.e. ZGC and Shenandoah implement their own related methods already).
Aarch64 added a register set abstraction which looks good. Try to see if it makes sense for x86.
- relates to
-
JDK-8283494 Factor out calculation of actual number of XMM registers
-
- Resolved
-
-
JDK-8343452 Incorrect WINDOWS build variable is used in macroAssembler_x86.cpp
-
- Resolved
-