On 7/26/13 9:34 AM, Christian Thalinger wrote:
On Jul 25, 2013, at 5:14 PM, 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
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:
Good idea, I'll look at it.
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.
Thank you for the review.
I agree, it is not that ugly as it seemed to be initially. :)
Thanks,
Serguei
-- 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
