RFR: 8373697: AArch64: Remove deoptimization stub code for nmethods with small stack frames

[Ruben]

On Wed, 17 Dec 2025 02:21:04 GMT, Dean Long <dlong at openjdk.org> wrote:

> should we consider alternative solutions

Another idea I've been thinking about, however in an abstract form only so far - it is not validated or thought through: 
- to remove the original PC slot and deoptimization stub codes completely
- to create a linked list of deoptimized frames with the head pointer being in the thread structure

The list would be linked via return address slots: each slot would be split into two fields: the original PC encoded as a 32-bit offset within the code cache, 32-bit offset to the next deoptimized stack frame if any.


The top deoptimized stack frame's return address would be handled in a different way: it would point to the shared deoptimization blob entry point; its original PC will be saved in the thread structure along with the head pointer.

Once deoptimization completes for the top deoptimized frame, the next stack frame in the list is patched to point to shared deoptimization blob.

I'm not sure about a few aspects:
- whether exception handling can result in discarding a deoptimized stack frame without it being processed
- what are requirements in terms of visibility from other threads - whether existing synchronization mechanism is sufficient to support this scheme
- whether original PC slot can be outside the code cache for AOT case

It is an abstract idea at this stage, and I am not meaning to propose it as an alternative for this PR. However, if it seems potentially feasible, I might be able to allocate some time to explore this more in future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28857#issuecomment-3669923204