JDK-8218885 : Restore pop_frame and force_early_return functionality for Graal
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 12
  • Priority: P5
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2019-02-13
  • Updated: 2024-01-29
  • Resolved: 2022-11-17
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.
JDK 20
20 b25Fixed
Related Reports
Blocks :  
JDK-8217941 - com/sun/jdi tests fail with "Error while cleaning up threads after test"
Blocks :  
JDK-8218402 - suspend in JavaCallWrapper breaks JVMTI PopFrame/ForceEarlyReturn
Blocks :  
JDK-8218403 - Deoptimizing top frame not always sufficient to reach interpreter-only mode
Blocks :  
JDK-8217758 - [Graal] Graal should retain local variables if jvmti can_pop_frame/can_access_local_variables capability is set
Relates :  
JDK-8218025 - disable pop_frame and force_early_return caps for Graal
Relates :  
JDK-8218594 - Release Note: can_pop_frame and can_force_early_return Capabilities are Disabled if JVMCI Compiler is Used
Description
pop_frame and force_early_return caps were disabled if JVMCI compiler is used (by JDK-8218025)
Need to re-enable them after fixing corresponding bugs.
Comments
Changeset: d61720a4 Author: Tom Rodriguez <never@openjdk.org> Date: 2022-11-17 05:18:49 +0000 URL: https://git.openjdk.org/jdk/commit/d61720a4dc1b3a9c6f7c5e6a2b68fa2b7735d545
17-11-2022
There is a comment in JDK-8218403: Dean Long added a comment - 2019-02-04 18:56 Here's a patch to popframe009 to demonstrate the problem with C1/C2 and -Xcomp: http://cr.openjdk.java.net/~dlong/popframe009/webrev/
20-09-2021
[~never] I'm trying to refresh my memory. My last comment in 8195635 says the "The problem with -Xcomp (JDK-8218403) still exists. The original problem with adjust_comp_level() is gone now". Then rereading 8218403, the only example it gives is adjustCompilationLevel(), so perhaps there is still a theoretical problem but no practical way to reproduce it anymore. So I'd say it's probably safe to undo this change now. I vaguely remember that wait_for_jvmci_completion() might have been involved in some scenarios (one way JVMCI is still different from other compilers), but I can't remember the details and that code has changed.
20-09-2021
This has just popped up for us an issue as people are using graal on JDK 17. I believe the original problem was caused by Graal's use of the adjustCompilationLevel callback which has since been removed by JDK-8219403. We'd like to undo this change since we should be have the same as C1/C2 in this regard now. Is there any way to test or confirm this now that Graal has been removed? I guess if I could mach5 test a pre graal removal and post adjustCompilationLevel removal version hotspot that would confirm it. I'm not really sure that it's really necessary anymore since we're not really different than the other compilers now. cc [~dlong]
18-09-2021