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

[Dean Long]

On Tue, 23 Apr 2024 11:46:08 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> 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_thread->current_pending_monitor() != nullptr` would suffice.

I believe those assumptions will always hold, but per separate discussions, let's go with what you have.

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

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