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

[Dean Long]

On Thu, 18 Apr 2024 19:16:32 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> 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.
>
> I thought the original check was fine. Could you elaborate on these 2 cases, I didn't really get them.

Deoptimization is already expensive, and this edge case is rare, so I think it would be better to compute the actual previous bytecode here, and not use bci - 1.

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

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