RFR(M) 8155980: ARM InterpreterMacroAssembler::get_method_counters() should not be saving callee saved registers
Chris Plummer
chris.plummer at oracle.com
Fri Jan 6 23:14:41 UTC 2017
Hello,
Please review the following arm changes. They will be pushed to JDK 10
only (when it opens).
https://bugs.openjdk.java.net/browse/JDK-8155980
http://cr.openjdk.java.net/~cjplummer/8155980/webrev.02/webrev.hotspot
JDK-8012544 added a bunch of callee register saving to
InterpreterMacroAssembler::get_method_counters() around the call_VM()
call. The reason is because there are a couple of callers of
get_method_counters() that need to have r0 and r3 preserved.
get_method_counters() should not be responsible for having to save
callee saved registers. It does not know which ones are in use when it
is called, so it can't do this efficiently. In fact 2 of the 4 callers
of get_method_counters() do not need any registers saved. For this
reason the callee of get_method_counters() should be responsible for
saving callee registers.
This solution would have been been pretty straight forward, except that
AARCH64 does not allow SP to go above extended_sp, so when setting up
extended_sp I needed to make sure there will be room for the 2 registers
that need to be pushed. extended_sp is mainly based on max_stack() for
the method, plus an extra slot for jsr292 and exception handling (but
not both at the same time). So the fix here is mostly about making sure
there are always at least 2 extra slots for pushing the 2 registers.
Here are the changes:
interp_masm_arm.cpp
-No longer save/restore registers in get_method_counters():
templateTable_arm.cpp:
-Save/restore Rdisp and R3_bytecode to stack around calls to
get_method_counters.
abstractinterpreter__arm.cpp::
-Properly account for extra 2 slots needed on AARCH64 when creating a
frame
in layout_activation()
-Note I switched to using method->constMethod()->max_stack() because
method->max_stack() includes Method::extra_stack_entries(), and I
want to
account for Method::extra_stack_entries() separately.
templateInterpreterGenerator_arm.cpp:
-Properly account for extra 2 slots needed on AARCH64 when creating a
frame
in generate_normal_entry().
I've tested the following with -Xcomp and with -Xmixed on arm32 and arm64:
Kitchensink
vm.mlvm
:jdk_svc
:hotspot_runtime
:hotspot_serviceability
:hotspot_compiler
:jdk_lang
:jdk_util
I also tested the test case from JDK-8012544.
thanks,
Chris
More information about the hotspot-runtime-dev
mailing list