> 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 ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/2014/files - new: https://git.openjdk.org/valhalla/pull/2014/files/66552db9..79be6198 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=2014&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=2014&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 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
