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

[Richard Reingruber]

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.

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

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/29133/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29133&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374769
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/29133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29133/head:pull/29133

PR: https://git.openjdk.org/jdk/pull/29133