RFR: 8330253: Skip verify_consistent_lock_order when deoptimizing from monitorenter bytecode. [v6]

[Axel Boldt-Christmas]

On Tue, 23 Apr 2024 08:07:40 GMT, Dean Long <dlong at openjdk.org> wrote:

>> I see there is `_pending_monitorenter` but this would only handle synchronized method entry.
>
> I like the idea of a flag better, because it is foolproof.  Why can't we set it in ObjectSynchronizer::enter?  I don't think it matters if there is a safepoint check before that, because the lock stack is still consistent at that point.

(Currently) the lock stack is always consistent at safepoints w.r.t. what is actually locked. However the lock stack may not be consistent with the most recent lock returned by the leaf `compiledVFrame::monitors()`. 

But you are correct that it can probably be moved to `ObjectSynchronizer::enter` there are no safepoint polls between `SharedRuntime::monitor_enter_helper` and that point. Similarly there are no safepoints polls in the runtime until after `set_current_pending_monitor` is called. 

So with these following assumptions.
1. LockStack is consistent at safepoints w.r.t. locked monitors
2. No safepoint polls exist from the point that compiledVFrame::monitors() starts returning the monitorinfo for the currently executing monitorenter until either it calls into the runtime or finishes locking.

I do not believe 1. is likely to ever change. But I have limited understanding of the validity of 2. nor if it something that can change.

If both these assumptions are correct than simply skipping the verification when `deoptee->current_pending_monitor() != nullptr` would suffice.

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

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