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

[Dean Long]

On Tue, 23 Apr 2024 05:54:58 GMT, Axel Boldt-Christmas <aboldtch 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.
>> 
>> 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.
>
> 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.

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

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