RFR: 8316746: Top of lock-stack does not match the unlocked object [v3]

[Martin Doerr]

On Thu, 28 Sep 2023 10:38:52 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I think we need to support "Top of lock-stack does not match the unlocked object" and take the slow path. Reason: see JBS issue.
>> Currently only PPC64, x86_64 and aarch64 code. I'd like to get feedback before implementing it for other platforms (needed for all platforms).
>
> Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Pass may_be_unordered information to lightweight_unlock.
>  - Merge remote-tracking branch 'origin' into 8316746_lock_stack
>  - Add x86_64 and aarch64 implementation.
>  - 8316746: Top of lock-stack does not match the unlocked object

I've run more tests with the `Parse::load_interpreter_state` experiment and found one which fails: vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage006/TestDescription.java
Interesting that so few tests are sensitive to unlock ordering issues.

I still wonder if a scenario like this can happen:
- Objects A and B are locked by the interpreter in a method which has balanced monitors.
- A Java debugger does anything which causes the interpreter frame monitor stack slots to get exchanged (I don't know what it could be.) That could be considered legal because the slots have no defined order. It is even allowed to reuse empty slots on demand.
- A later part of the method gets OSR compiled which is not prevented, because the method has balanced monitors. The JIT compiler expects the interpreter frame monitor slots to be in a certain order which is no longer true.

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

PR Comment: https://git.openjdk.org/jdk/pull/15903#issuecomment-1743001654