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

Dean Long dlong at openjdk.org
Fri Sep 29 01:19:16 UTC 2023


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

> The lock order cannot be guaranteed for OSR compilation (see JBS discussion).

There won't be an nmethod with an OSR entry point if the locks aren't nested correctly, so I still don't understand what is going wrong and why this change is necessary.  The C2 assembly code output in the hs_err file looks correct.  How could the locks in the interpreter frame get out of order?

Allowing C2 to unlock locks out of order seems like the wrong solution.  I think it could have unintended consequences because this is a basic invariant for the compilers.  If this problem can somehow to caused by JVMTI, then whatever unsafe operation JVMTI is doing should probably invalidate OSR entry points for the method.

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

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


More information about the hotspot-dev mailing list