JDK-8218402 : suspend in JavaCallWrapper breaks JVMTI PopFrame/ForceEarlyReturn
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 12,13
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2019-02-04
  • Updated: 2020-10-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
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