RFR: 8330253: Skip verify_consistent_lock_order when deoptimizing from monitorenter bytecode.

[Dean Long]

On Mon, 15 Apr 2024 09:15:44 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The verification added in [JDK-8329757](https://bugs.openjdk.org/browse/JDK-8329757) will not work then deoptimization occurs on a monitorenter bytecode. The locking may be in a transitional state. This patch will skip the verification when this occurs.
> 
> Currently have only seen this reproduce with JVMTI when deoptimization occurs while a java thread is waiting on a contended monitor. However this could potentially be triggered from a VM entry slow path, so simply checking `current_pending_monitor` could be flaky as well. So instead simply avoid verification.
> 
> Running JVMTI reproducer. Starting full testing soon.

src/hotspot/share/runtime/deoptimization.cpp line 451:

> 449:     if (!is_syncronized_entry && bc != Bytecodes::Code::_monitorenter) {
> 450:       deoptee_thread->lock_stack().verify_consistent_lock_order(lock_order, exec_mode != Deoptimization::Unpack_none);
> 451:     }

The above checks would also hit the follow false positives:
1. deopt in counter overflow in prologue, not in monitorenter
2. monitorenter at bci 0 when raw_bci is -1 (assuming it got past the verifier)
but seems mostly harmless to skip checks in those cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18782#discussion_r1566649663