JDK-8218402 : suspend in JavaCallWrapper breaks JVMTI PopFrame/ForceEarlyReturn
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 12,13
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • Submitted: 2019-02-04
  • Updated: 2025-10-10
  • Resolved: 2025-10-10
Related Reports
Blocks :  
JDK-8218885 - Restore pop_frame and force_early_return functionality for Graal
Relates :  
JDK-8255384 - Remove special_runtime_exit_condition() check from SS::block()
Relates :  
JDK-8219403 - JVMCIRuntime::adjust_comp_level should be replaced
Description
Doing a suspend in a call setup transition breaks JVMTI PopFrame/ForceEarlyReturn because we report the top frame as the caller, but then proceed to the callee before processing the requested  PopFrame/ForceEarlyReturn.

If JavaCallWrapper is the only place this happens, we should be able to find a localized fix.  If there are more places where this can happen, we may want to change the rule that all safepoints are suspend points.  Instead, instead of asking to reach a safepoint, we could ask to reach a "suspend safepoint".
Comments
Now that JDK-8219403 is fixed and we no longer call adjustCompilationLevel(), this is much less likely to occur. Lowering priority.
14-05-2019
This shows up with Graal because of the call to HotSpotJVMCIRuntime::adjustCompilationLevel(), but it could also happen in other places.
04-02-2019