Hi Andrew, we are at top frame, but temps and extra_args are 0 #0 AbstractInterpreter::size_activation (max_stack=3, temps=0, extra_args=0, monitors=1, callee_params=0, callee_locals=0, is_top_frame=true) at /media/psf/Home/projects/zulu8-arm64-dev/hotspot/src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp:1635 #1 0x0000007fb78c6b10 in vframeArrayElement::on_stack_size (this=0x7f840014b8, callee_parameters=0, callee_locals=0, is_top_frame=true, popframe_extra_stack_expression_els=0) at /media/psf/Home/projects/zulu8-arm64-dev/hotspot/src/share/vm/runtime/vframeArray.cpp:442 Sergey Nazarkin
On 13 Jun 2017, at 17:54, Andrew Haley <aph@redhat.com> wrote:
On 13/06/17 14:24, Sergey Nazarkin wrote:
Hi!
Please review the fix [1] for the crash happens when compiled method is forced to return early. We found this issue when running vm/jvmti/ForceEarlyReturnObject/fero001/fero00103/fero00103.html JCK test on CPU with 47 cores.
The crash happens at the time when test code tries to check returned value and gets invalid oop. Despite correct object was acquired by load_earlyret_value(), it is accidentally substituted on the stack when remove_activation() is executed (see TemplateInterpreterGenerator::generate_earlyret_entry_for). Substitution, in turns, happens due to overlapping of expression and native stacks. Particularly esp equals to sp because frame with no expression is restored (that is correct).
After that execution of following code sequence replaces TOS with some irrelevant value.
push(tos) // -> puts value on expression stack unlock_object() // -> calls call_VM() and save registers on native stack, in fact, at the same place as esp pop(tos) // -> restores invalid value
The fix restores expression stack to max possible for deoptimized method size. Please consider if this fix covers the case workarounded by [2] (I was not able to trace back and find the reason for this changeset).
[1] http://cr.openjdk.java.net/~snazarki/earlyret_crash/ [2] http://hg.openjdk.java.net/aarch64-port/jdk8u60/hotspot/file/83f5fdfd56ec/sr... I don't quite understand this. If we are the top frame, then we must allow space for max_stack, but in that case temps + extra_args is equal to max_stack anyway, so we don't need to add max_stack to extra_args. If we aren't the top frame, we peel back the native SP at the point of call.
Can you tell me a bit more about this?
Andrew.
-- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671