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
