Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments

Christian Thalinger christian.thalinger at oracle.com
Fri Jul 26 09:34:34 PDT 2013


On Jul 25, 2013, at 5:14 PM, 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:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1

src/share/vm/classfile/javaClasses.hpp:

+ public:
+  // Accessors
+  static oop            member(oop mh);
+  static void       set_member(oop mh, oop member);

Where is the implementation for these methods?  Because if we had them you could use it here:

src/share/vm/interpreter/interpreterRuntime.cpp:

+    oop member_name = (dmh_oop)->obj_field(java_lang_invoke_DirectMethodHandle::member_offset_in_bytes());

Otherwise this change looks really good and clean.  It's not so bad after all.

-- Chris

> 
> 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



More information about the serviceability-dev mailing list