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

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Fri Jul 26 09:54:10 PDT 2013


On 7/26/13 9:34 AM, Christian Thalinger wrote:
> 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:

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



More information about the serviceability-dev mailing list