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