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

[Richard Reingruber]

On Thu, 18 Dec 2025 20:37:59 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> > If max_stack of the sender is very large then, due to trimming, unextended_sp < sp is possible and the assertion could also fail.
> > Maybe the maximum of unextended_sp and sp could be used?
> 
> On x64 and AArch64 we build the OSR frame starting from the sender's `unextended_sp` (modulo aligment). Is that not the case for ppc?

It is. The difference to x86 is, that the `unextended_sp` can be (much lower) than the `sp` because `unextended_sp` has room for the maximal size of the expression stack. [This diagram](https://github.com/openjdk/jdk/blob/b5ac8f83682ddb9623a1b43bd62f309b2961a504/src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp#L656) shows this.

Actually aarch64 seems to be similar. I think @dean-long told me once that there an interpreter frame also has room for the maximal expression stack (see [generate_fixed_frame](https://github.com/openjdk/jdk/blob/b5ac8f83682ddb9623a1b43bd62f309b2961a504/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp#L920-L929)) and that it get's trimmed by an interpreted callee. What's done [just before calling `generate_fixed_frame`](https://github.com/openjdk/jdk/blob/b5ac8f83682ddb9623a1b43bd62f309b2961a504/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp#L1690-L1712) looks like trimming of the caller frame.

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

PR Comment: https://git.openjdk.org/jdk/pull/28830#issuecomment-3675281628