RFR: 8374769: PPC: MASM::pop_cont_fastpath() should reset _cont_fastpath if SP == _cont_fastpath

[Martin Doerr]

On Fri, 9 Jan 2026 08:17:53 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This pr changes `MacroAssembler::pop_cont_fastpath()` to reset `JavaThread::_cont_fastpath` also if it is equal to the current sp as it is done on x86 and aarch64.
> 
> Background:
> 
> `JavaThread::_cont_fastpath` is set to the sp of the oldest (highest) known interpreted frame inside the continuation. It prevents fast path freezing if set.
> 
> Setting is lazy, e.g. only in i2c transitions. This is sufficient because freezing is done with a special native wrapper (see `gen_continuation_yield`). So if there is an interpreted frame in the continuation an i2c transition is required to call it.
> 
> There is only one location where a possible fast path freeze might be missed on the slow path for synchronization in a native wrapper:
>  [SharedRuntime::generate_native_wrapper()](https://github.com/openjdk/jdk/blob/78b1ca6cc14e1a92bf25cbcfb687067ac17af92b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp#L2402-L2404)
> ```c++
> 2402	    __ push_cont_fastpath();
> 2403	    __ call_VM_leaf(CAST_FROM_FN_PTR(address, SharedRuntime::complete_monitor_locking_C), r_oop, r_box, R16_thread);
> 2404	    __ pop_cont_fastpath();
> 
> `pop_cont_fastpath()` at L2404 fails to reset `_cont_fastpath` if it was set at L2402. Consequently a fast path freeze can be missed when returning from the native method.

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29133#pullrequestreview-3643576220