RFR (XM) 8076579: Popping a stack frame after exception breakpoint sets last method param to exception
coleen.phillimore at oracle.com
Wed Apr 29 13:01:19 UTC 2015
The bug says JSR292 and PopFrame! I think we are all scared of it.
The fix looks good. Nit: I would have coded it in an 'else' statement
instead. I did check that this is the only interpreter runtime function
without all paths setting vm_result.
You are going to have to get someone from the compiler team who knows
JSR292 to also review it.
On 4/29/15, 5:48 AM, serguei.spitsyn at oracle.com wrote:
> 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! :)
> On 4/27/15 2:12 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review the jdk 9 fix for:
>> 9 hotspot webrev:
>> This bug is a regression that was introduced but the fix of:
>> The bug is in the InterpreterRuntime::member_name_arg_or_null()
>> function that
>> does not return NULL if there is no invokestatic appendix argument
>> 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
>> 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
More information about the hotspot-dev