RFR JDK-8195639: [Graal] nsk/jvmti/PopFrame/popframe009 fail with Graal in -Xcomp

[dean.long at oracle.com]

How does this solve the problem of 
HotSpotJVMCIRuntime.adjustCompilationLevel being called?

I don't think this fix is the right approach.  Doesn't 
is_interp_only_mode() only apply to the current thread?  I don't think 
it's safe to assume no compiles will happen in other threads, or that a 
method call target is not already compiled, because as far as I can 
tell, JVMTI only deoptimizes the active frames.  The bug report 
describes a case where the caller has been deoptimized while resolving a 
call.  I don't see how this fix prevents the target from being a 
previously compiled method.  But we do need to make sure not to call 
into compiled code, so I think the fix needs to be in code like 
SharedRuntime::resolve_static_call_C(), where it returns get_c2i_entry() 
if is_interp_only_mode() is true.  However, there is still another 
problem.  By allowing JVMTI to suspend the thread during call setup, but 
reporting the frame as still in the caller instead of the callee, we 
confuse JVMTI into thinking that execution will resume in the caller 
instead of the callee.  We may want to restrict where we offer JVMTI 
suspend points, and not offer a JVMTI suspend point in 
SharedRuntime::resolve_static_call_C and friends at all.

dl


On 11/26/18 11:14 AM, Alex Menkov wrote:
> Hi all,
>
> Please review the fix for
> https://bugs.openjdk.java.net/browse/JDK-8195639
> webrev:
> http://cr.openjdk.java.net/~amenkov/popframe009/webrev.01/
>
> Description:
> The test suspends a thread, turns on single stepping and then calls 
> PopFrame. SingleStep event is expected as soon as the thread is 
> resumed and PopFrame is processed (so we have call stack with the 
> depth 1 less than it was before PopFrame). Instead SingleStep event is 
> received with much deeper call stack (and PopFrame processes wrong 
> frame).
> Research shown that this is caused by missed deoptimization of the 
> current frame.
> As far as I understand CompilationPolicy::event should handle the case 
> when the thread has is_interp_only_mode() set, but 
> TieredThresholdPolicy::event checks this only then CompLevel is 
> CompLevel_none.
> CompilerRuntime always calls policy()->event with CompLevel == 
> CompLevel_aot.
>
> The fix looks quite simple, but I'd appreciate feedback from runtime 
> and compiler teams as I'm not sure I completely understand all the 
> details of the "PopFrame dance".
>
> --alex