RFR: 8372591: assert(!current->cont_fastpath() || freeze.check_valid_fast_path()) failed

[Fei Yang]

On Mon, 15 Dec 2025 16:53:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> When a frame is OSR and the caller is interpreted we call `push_cont_fastpath` to possible set `_cont_fastpath` to the `sp` of the sender. This is needed in order to keep track of interpreted frames in the stack, so that in case of unmounting we don't incorrectly execute the freeze fast path, which is only allowed when all frames are compiled.
> 
> The problem is that the OSR frame is created starting from the `unextended_sp` of the sender, not the `sp`, i.e we pop the interpreted frame like in `remove_activation`. This means that we could set a value to `_cont_fastpath` that will point outside the valid stack (below the `sp` of the OSR frame). If the gap between these stack addresses is big enough, `_cont_fastpath` could be later cleared while we still have the interpreter sender in the stack, leading to the reported crash. The simplest case where this will happen is if in a later call to yield all the extra frames leading to `Continuation.doYield` fit within this space [[1]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b14b85ab7841d7b1b51/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L232). It could also be cleared before that if for example at some point we returned from an interpreted callee and the sender sp it's not below `_cont_fastpath`[[2]](https://github.com/openjdk/jdk/blob/ad29642d8f4e8e0fb1223b
 14b85ab7841d7b1b51/src/hotspot/cpu/x86/interp_masm_x86.cpp#L1060).
> 
> The fix is to change `OSR_migration_begin` to set `_cont_fastpath` with the sender's `unextended_sp` instead. 
> 
> The patch includes new test `OSRWithManyLocals.java` which reliably reproduces the crash. I thought about adding it to the existing `OSRTest.java` but that was created to exercise a different issue. A better name for that test would be `OSRWithManyArgs.java`, so I could rename it in this patch if preferred (I also realized that test could be simplified and made easier to read but that's for another PR).
> 
> I tested the current patch with the new test and also run it through mach5 tiers1-7.
> 
> Thanks,
> Patricio

LGTM. I see the issue is there on linux-riscv64 as well when running the reproducer and this fix works.

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

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28830#pullrequestreview-3602407270