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

[Patricio Chilano Mateo]

On Fri, 19 Dec 2025 14:29:22 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>>> > > @reinrich @TheRealMDoerr Could you verify if this fix is correct for ppc too? Thanks.
>>> > 
>>> > 
>>> > The fix looks correct. Strangely the reproducer didn't work on ppc. Not even with 3x the locals in the osr method. I'll look a little more into it...
>>> 
>>> On ppc we reach `OSR_migration_begin` with `_cont_fastpath` that's higher than `sender.sp()` so `push_cont_fastpath(sender.sp())` has no effect. I'm not sure why this is. It might be due to the trimming with i2i calls where the sender is trimmed to a `parent frame` (the top frame always has room for max_stack). The sender is a lambda. Maybe it has done an i2c call as `top frame` (i.e. untrimmed) which set `_cont_fastpath`?
>>> 
>> Maybe, but I don't see which compiled method it could be, since methods before `foo` should be interpreted.
>> 
>>> 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?
>
>> > 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?
> 
> *EDIT:*
> 
> Yes it is. And I get it now: the OSR frame is built starting from the sender's `unextended_sp`. It doesn't matter if it is below sender's sp. It will surely be within the valid stack (above the sp of the OSR frame).
> 
> *OLD Comment:*
> 
> 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.

Thanks for checking @reinrich and @RealFYang.

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

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