RFR (XM) 8076579: Popping a stack frame after exception breakpoint sets last method param to exception

[serguei.spitsyn at oracle.com]

On 4/29/15 9:42 AM, Christian Thalinger wrote:
>> On Apr 29, 2015, at 7:25 AM, serguei.spitsyn at oracle.com wrote:
>>
>> Coleen,
>>
>> Thank you a lot for review!
>>
>>
>> On 4/29/15 6:01 AM, Coleen Phillimore wrote:
>>> Serguei,
>>>
>>> The bug says JSR292 and PopFrame!  I think we are all scared of it.
>> That is true. I know about it. :)
>>
>>> The fix looks good.  Nit: I would have coded it in an 'else' statement instead.
>> Selected this way of fix to make it a one-liner to be easier for reviewers! :)
>> I really do not have any personal preference.
> The fix looks good and I also would like to see an else.

I was going to satisfy this advice from Coleen.
With an else it looks more clean and consistent with other fragments.

Thanks a lot, Christian!
Serguei

>
>>> I did check that this is the only interpreter runtime function without all paths setting vm_result.
>> I admit, this was my mistake in the first place.
>>
>>> You are going to have to get someone from the compiler team who knows JSR292 to also review it.
>> Sure.
>> My plan was to ask Christian T. to take a brief look.
>>
>> Thanks,
>> Serguei
>>
>>> thanks,
>>> Coleen
>>>
>>> On 4/29/15, 5:48 AM, serguei.spitsyn at oracle.com wrote:
>>>> Ping...
>>>> Just wanted to tell that it is a very safe and simple one-liner so that
>>>> I assumed it to be reviewed in a couple of days, not weeks! :)
>>>>
>>>> Thanks!
>>>> Serguei
>>>>
>>>> On 4/27/15 2:12 PM, serguei.spitsyn at oracle.com wrote:
>>>>> Please, review the jdk 9 fix for:
>>>>>   https://bugs.openjdk.java.net/browse/JDK-8076579
>>>>>
>>>>>
>>>>> 9 hotspot webrev:
>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8076579-JVMTI-pop.1
>>>>>
>>>>>
>>>>> Summary:
>>>>>
>>>>>   This bug is a regression that was introduced but the fix of:
>>>>>     https://bugs.openjdk.java.net/browse/JDK-7187554
>>>>>
>>>>>   The bug is in the InterpreterRuntime::member_name_arg_or_null() function that
>>>>>   does not return NULL if there is no invokestatic appendix argument (MemberName).
>>>>>   It is why the _remove_activation_preserving_args is trying to to restore unexisting
>>>>>   appendix argument when a pop instruction is executed by a debugger in the debuggee VM.
>>>>>   The fix is to correctly set NULL in the thread vm_result when it is necessary:
>>>>>     thread->set_vm_result(NULL);
>>>>>
>>>>>
>>>>> Testing in progress:
>>>>>   In progress: nsk.jvmti.testlist and nsk.jdi.testlist PopFrame tests, JTREG com/sun/jdi tests,
>>>>>                ad-hog ExceptionBug.java test from the bug report
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Serguei