Hi, The reason for the failure is that, we separately compute the instance type `type`, which is used in the assert, and the klass type `klass_type`, which is used for the check cast, so there is a chance during the computation of `type`, the class has only 1 single concrete subclass, and before the computation of `klass_type`, another subtype is loaded, leading to `klass_type` being the supertype of `type`, which triggers the assert. Computing these 2 in the opposite order likely does not work, either, because we can have concurrent class unloading.
As a result, in this PR, I reworked `check_interpreter_type` to receive a `ciType`, this also helps simplify the implementation, as previously, we needed to obtain the null restriction and larval-ness of the value indirectly, while they are readily available in the `ciType` obtained from `ciTypeFlow`. Trying to keep the assert for every case is cumbersome, and verifying the type right after the check cast seems unnecessary, so I relaxed the assert to only verify the correct kind of value. Testing: - [ ] tier1-4,valhalla-comp-stress Please take a look and leave your review, thanks a lot. --------- - [x] I confirm that I make this contribution in accordance with the [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). ------------- Commit messages: - Racing class loading may cause assertion Changes: https://git.openjdk.org/valhalla/pull/2333/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2333&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374475 Stats: 71 lines in 2 files changed: 17 ins; 25 del; 29 mod Patch: https://git.openjdk.org/valhalla/pull/2333.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2333/head:pull/2333 PR: https://git.openjdk.org/valhalla/pull/2333
