On Wed, 1 Jul 2026 10:27:21 GMT, Christian Hagedorn <[email protected]> wrote:
>> The provided test cases fail when inlining the `Array.copyOf/copyOfRange()` >> intrinsics where the source array is flat and from an abstract value class. >> >> The current code checks whether the source array or the destination array >> klass contain oops by assuming that a flat value class array is always >> concrete and thus an `InlineKlass` (i.e. can call `inline_klass()`). >> However, we could also have abstract value class arrays that are known to be >> flat (see test cases). This leads to a cast assertion failure because >> abstract value classes are represented by an `InstanceKlass` and not an >> `InlineKlass`. >> >> To fix this, I added a simple bailout when detecting an abstract flat value >> class array. This is a conservative correctness fix and should be revisited >> again post-Valhalla-integration. We have >> [JDK-8251971](https://bugs.openjdk.org/browse/JDK-8251971) in place for that >> which should also tackle other issues around the arraycopy intrinsics and >> also address performance problems. >> >> Thanks, >> Christian >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Christian Hagedorn has updated the pull request with a new target base due to > a merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains 11 additional > commits since the last revision: > > - Add test for void.class as well > - Improve comments > - Merge branch 'lworld' into JDK-8382226 > - Update > - Merge branch 'lworld' into JDK-8382226 > - Fix endless deopts with -XX:-UseArrayFlattening > - Update > - improve checks and further refactor exclude_flat to make it easier to read > - fix tklass > - Review Quan-Anh > - ... and 1 more: > https://git.openjdk.org/valhalla/compare/e8c02db9...20cd9217 src/hotspot/share/opto/library_call.cpp line 5188: > 5186: // passing in primitive class mirrors like int.class which do not > have corresponding Klass* pointers. > 5187: // In these cases, klass_node will be top. Emit a trap to throw > in the interpreter in this case. > 5188: bail_out_from_array_copyOf(bailout); What if the `j.l.Class` is not a constant, but the runtime value is `int.class`, it will return `null`, right? Which explains the null check below. In that case, is it an inconsistency? Can it be an issue if a `j.l.Class` is narrowed to the constant `int.class` during IGVN, then the node will become `top` and the whole graph is incorrectly killed. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2569#discussion_r3505474419
