On Mon, 2 Feb 2026 15:44:21 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 This pull request has now been integrated. Changeset: 750a2f99 Author: Tobias Hartmann <[email protected]> URL: https://git.openjdk.org/valhalla/commit/750a2f997b42cb96205d82ccfb7a81a20a2cf014 Stats: 10 lines in 1 file changed: 6 ins; 2 del; 2 mod 8375547: [lworld] Dependency verification fails with assert "Should have been marked for deoptimization" Reviewed-by: mchevalier ------------- PR: https://git.openjdk.org/valhalla/pull/2014
