RFR: 8348411: C2: Remove the control input of LoadKlassNode and LoadNKlassNode [v3]

Quan Anh Mai qamai at openjdk.org
Thu Jan 30 07:56:29 UTC 2025


On Tue, 28 Jan 2025 20:52:52 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Thanks for noticing, IIUC the issue with JDK-8057622 is that we see that the bottom type of the array is `java.lang.Object`, we then try to find the element type of `java.lang.Object` which is an invalid operation. The fix for the issue seems to do 2 things. It avoids the optimistic check if the bottom type is `java.lang.Object`, then it loads the element type from the constant only if the type check succeeds. The second part seems unnecessary, if the bottom type is not `java.lang.Object`, then it must be an array type, so the load must succeed. I added `is_aryklassptr` there to ensure that we are not having a bogus constant klass pointer.
>
> Indeed, control does look redundant here. Once `array_klass` becomes a constant, the corresponding `LoadKlass` node should constant fold into a constant as well and the original control is gone anyway. 
> 
> (It's worth adding an assert here that `a_e_klass` is a constant when `array_klass` is a constant (and `StressReflectiveCode == false`).

I assume that asserting `StressReflectiveCode || array_klass->is_Con() == a_e_klass->is_Con()` is correct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23274#discussion_r1935155414


More information about the hotspot-compiler-dev mailing list