JDK-8277602 : Deopt code does not extend the stack enough if the caller is an optimize entry blob
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 18,repo-panama
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2021-11-22
  • Updated: 2024-07-10
  • Resolved: 2021-11-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.
JDK 18
18 b26Fixed
Related Reports
Relates :  
Description
In the case of a deopt due to an uncommon trap, the uncommon trap blob ad-hoc extends the frame of caller of the deoptee so that it has enough space for local variables after converting it to an interpreter frame.

For compiled callers this means we also need to make room for the arguments, which would normally be done by a c2i adapter.

However, the current deopt code only checks if the caller is a compiled frame with frame::is_compiled_frame, and therefore doesn't extend the stack for arguments if the caller is an optimized entry blob, which also does a compiled call. This can lead to memory corruption because some of the locals of the youngest reconstituted interpreter frame overwrite parts of the optimized entry frame.
Comments
Changeset: 98a9f037 Author: Jorn Vernee <jvernee@openjdk.org> Date: 2021-11-30 14:34:00 +0000 URL: https://git.openjdk.java.net/jdk/commit/98a9f037397d437d2c3221e8522ed8ab397a457a
30-11-2021

I guess it's mostly just an established practice that nobody felt the need to change so far. I also vaguely remember that when I tried in the past to put a bug under the proper components it caused some friction (with someone changing the components around, and re-assigning the bug to someone else).
24-11-2021

Okay, thanks. Yes, mainline bugs should go into a component to be properly handled by the triaging teams. Just out of curiosity, why don't you put the panama bugs into proper (sub)components? We do that for Valhalla as well.
24-11-2021

ILW = H (memory corruption/crash) L (infrequent, only in specific deopt cases) H (no workaround) = P2
23-11-2021

[~thartmann] that's what we go under for panama bugs. Since the PR is targeted at jdk 18 though, I can change the components to hotspot/compiler as well.
23-11-2021

Why is this in tools/jextract?
23-11-2021