RFR: 8372591: assert(!current->cont_fastpath() || freeze.check_valid_fast_path()) failed
Patricio Chilano Mateo
pchilanomate at openjdk.org
Thu Dec 18 20:40:54 UTC 2025
On Thu, 18 Dec 2025 19:05:08 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?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28830#issuecomment-3672131775
More information about the hotspot-dev
mailing list