Issue: the code generated with MASM::pop_cont_fastpath() does not reset _cont_fastpath of the current JavaThread to null if _cont_fastpath == SP
This is a difference to x86 and aarch64 that should be eliminated.

There is code like

2066 push_cont_fastpath();
2067 call_VM(noreg /* oop_result */, entry_point, false /*check_exceptions*/, &resume_pc /* last_java_pc */);
2068 pop_cont_fastpath();

(at https://github.com/openjdk/jdk/blob/a71326a0e2660158fdb85282da4b59ce61c66ee3/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp#L2066-L2068)

pop_cont_fastpath() in L2068 fails to clear _cont_fastpath even if it was set in L2066.
We don't miss a fast path when freezing in this case. There's an interpreter frame on stack anyway and if it is removed then another pop_cont_fastpath() will be executed in InterpreterMacroAssembler::remove_activation() after the frame was removed.

The only problematic location is in SharedRuntime::generate_native_wrapper()
(at https://github.com/openjdk/jdk/blob/78b1ca6cc14e1a92bf25cbcfb687067ac17af92b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp#L2402-L2404)
There we can miss a fast path when returning from the native method with _cont_fastpath != null but it only happens on the synchronization slow path.