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

[Axel Boldt-Christmas]

On Mon, 22 Apr 2024 21:39:09 GMT, Dean Long <dlong at openjdk.org> wrote:

>> 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.
>
> Other debug checks in deoptimization compute oop maps, which have to iterate all the bytecodes, so doing it here also wouldn't be so bad.  Or how about not checking bytecodes and instead checking a flag on JavaThread that says we are in monitor enter native code?

> 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.

Alright I will give that a go then, unless we think the second option is more appropriate. 

> Or how about not checking bytecodes and instead checking a flag on JavaThread that says we are in monitor enter native code?

What state would that be? Any current state we setup is after transitioning to VM which seems to late. I guess it would be possible to instrument `SharedRuntime::monitor_enter_helper` with some thread local state we can check. But the interpreter has its own entry point. But I guess we would never reach this point for the interpreter, as there is no such thing as deoptimizing or unpacking interpreted frames. 


What is the feeling here? What would be more appropriate? Adding some thread local debug state that we set before transitioning to VM in `SharedRuntime::monitor_enter_helper`  seems like the most precise solution, but we need to be sure that there are no earlier safepoint polls before this point within the execution of the monitorenter bytecode.

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

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