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 ------------- Commit messages: - More refactoring - Copyright - Merge branch 'lworld' into 8375546 - JDK-8375547 Changes: https://git.openjdk.org/valhalla/pull/2014/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2014&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375547 Stats: 8 lines in 1 file changed: 4 ins; 2 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/2014.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2014/head:pull/2014 PR: https://git.openjdk.org/valhalla/pull/2014
