On 30/07/2013 10:34 AM, serguei.spit...@oracle.com wrote:
Christian and David,
Thank you for the quick review and comments!
This is a new version of webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.2
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
not exist:
__ 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.
David
-----
Thanks,
Serguei
On 7/28/13 9:11 PM, David Holmes wrote:
Hi Serguei,
On 26/07/2013 10:14 AM, serguei.spit...@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:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1
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 //
???
David
-----
Summary:
Restore the appendix argument of a polymorphic intrinsic call
needed for a invokestatic re-execution after JVMTI PopFrame().
Description
When JVMTI's PopFrame removes a frame that was called via a call site
that
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.
Testing:
UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist,
nsk.jdi.testlist
Thanks,
Serguei
