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

[Dean Long]

On Tue, 24 Oct 2023 12:19:04 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> In case of OSR compilations, `map()->peek_monitor_obj()` may return the objects in wrong order. We should use the popped object. I'm not changing the code for `LM_LEGACY`. That may be done separately.
> Note that C1 uses the popped object, too: `case Bytecodes::_monitorexit    : monitorexit (apop(), s.cur_bci());`
> 
> This PR is not complete: A lot of C2 code uses the BoxLock. Ideas to solve that are welcome! I think we should get rid of these nodes in the long term because they are only really needed by `LM_LEGACY`.
> The vmTestbase/nsk/jdi/StepEvent tests are passing stable on x64 and ppc64.

src/hotspot/share/opto/locknode.cpp line 213:

> 211:   // in wrong order. We should use the popped obj.
> 212:   if (LockingMode == LM_LEGACY) {
> 213:     // May potentially be the wrong one in case of OSR, but we need both, box and obj.

This appears to mask the real problem, which, unless I missed it, has not been explained yet.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16345#discussion_r1372486257