Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments
david.holmes at oracle.com
Mon Jul 29 20:22:36 PDT 2013
On 30/07/2013 10:34 AM, serguei.spitsyn at oracle.com wrote:
> Christian and David,
> Thank you for the quick review and comments!
> This is a new version of webrev:
Sorry. You need that guard after all - at least you do if you continue
to use it in interpreterRuntime - otherwise member_name_arg_or_null will
__ call_VM(rax, CAST_FROM_FN_PTR(address,
InterpreterRuntime::member_name_arg_or_null), rax, rdx, rsi);
I'm a little surprised that the assembly code does not have that whole
section guarded with INCLUDE_JVMTI - perhaps it should?
Run this through a JPRT test build for productEmb to check that the
minimal VM builds ok.
> On 7/28/13 9:11 PM, David Holmes wrote:
>> Hi Serguei,
>> On 26/07/2013 10:14 AM, serguei.spitsyn at oracle.com wrote:
>>> Please, review the fix for:
>>> bug: http://bugs.sun.com/view_bug.do?bug_id=7187554
>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554
>>> Open webrev:
>> In the templateInterpreter code why did you put this guard on your new
>> code (from x86_32 version):
>> 1923 #if INCLUDE_JVMTI
>> when the whole chunk of code this is situated in is specifically for
>> JVMTI support
>> 1824 //
>> 1825 // JVMTI PopFrame support
>> 1826 //
>>> Restore the appendix argument of a polymorphic intrinsic call
>>> needed for a invokestatic re-execution after JVMTI PopFrame().
>>> When JVMTI's PopFrame removes a frame that was called via a call site
>>> takes an appendix and that call site is reexecuted the appendix is
>>> not on
>>> the stack anymore because it got removed by the adapter.
>>> This fix is to detect such a case and push the appendix on the stack
>>> again before reexecution.
>>> UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist,
More information about the hotspot-dev