The ObjectMonitor::_owner check in MacroAssembler::compiler_fast_unlock_object() [1] is redundant and should be removed because java code with unbalanced locking is never compiled to nmethods[2].

ObjectMonitor::_owner can be a stack address with LM_LEGACY [3]. In that case the result of the check is wrong. Execution will take unnecessarily the slow path.

[1] Redundant check: https://github.com/openjdk/jdk/blob/20f36c666c30e50c446d09cca4ea52395317a7eb/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp#L2700-L2705

[2] ciMethod::has_balanced_monitors() https://github.com/openjdk/jdk/blob/7a1e832ea997f9984eb5fc18474a8f1650ddb1bf/src/hotspot/share/ci/ciMethod.cpp#L290

[3] _owner can be a stack address: https://github.com/openjdk/jdk/blob/a601cd2e100958e3f37ae65e32e4b3cac246c079/src/hotspot/share/runtime/synchronizer.cpp#L1530

Background Info

Also on x86 there used to be a diagnostic locking mode that checked `_owner` field before unlocking to defend against unbalanced locking done using JNI:
https://github.com/openjdk/jdk/blob/84cf73f2a5d39240263bdb500fc98a6ec6590cf0/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L2184
JDK-8210381 removed it in jdk12: https://github.com/openjdk/jdk/commit/0f68e5221f4d3cf262f09170c5182f34c6b9cc30
Even jdk24 has stale comments refering to it: https://github.com/openjdk/jdk/blob/940aa7c4cf1bf770690660c8bb21fb3ddc5186e4/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp#L415

On ppc64 the owner check didn't depend on a special EmitSync diagnostic mode so JDK-8210381 didn't remove it. It is unclear why there the check was always done.