On Tue, 3 Feb 2026 13:50:45 GMT, Tobias Hartmann <[email protected]> wrote:
>> When detecting a mismatch in the calling convention, we call >> `super_method->set_mismatch()` out of the scope of the `Compile_lock`. When >> class loading/linking happens in parallel, other dependencies might be >> invalidated and nmethods will be marked for deoptimization. Verification >> code will then check that all nmethods that have violated dependencies have >> been marked. The verification will fail once it finds a nmethod that now has >> a violated dependency not due to the class loading but due to the mismatch >> that we just set. >> >> Similar to how the [runtime handles similar >> situations](https://github.com/openjdk/valhalla/blob/2ad3ce1646bb5c717239f683686dd1034a9340c1/src/hotspot/share/oops/instanceKlass.cpp#L1230-L1235), >> `set_mismatch` needs to be performed while holding the lock. We then keep >> the lock until we marked all methods. >> >> When looking at the code, I noticed that more instructions can be moved out >> of the scope of the lock, so I did that as well. >> >> I quickly looked into creating a regression test for this but it's >> non-trivial. Also, our internal testing triggers this reliably, so I decided >> to go without a regression test for now. >> >> Thanks, >> Tobias > > Tobias Hartmann has updated the pull request incrementally with one > additional commit since the last revision: > > Nice comments Thanks for the review Marc. I added a comment. ------------- PR Review: https://git.openjdk.org/valhalla/pull/2014#pullrequestreview-3745389015
