RFR: 8372634: C2: Materialize type information from instanceof checks
Quan Anh Mai
qamai at openjdk.org
Thu Nov 27 14:10:55 UTC 2025
On Thu, 27 Nov 2025 00:53:54 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:
> Even though `instanceof` check (and reflective `Class.isInstance` call) narrows operand's type, sharpened type information is not explicitly materialized in the IR.
>
> There's a `SubTypeCheck` node present, but it is not a substitute for a `CheckCastPP` node with a proper type.
>
> The difference can be illustrated with the following simple cases:
>
> class A { void m() {} }
> class B extends A { void m() {} }
>
> void testInstanceOf(A obj) {
> if (obj instanceof B) {
> obj.m();
> }
> }
>
> InstanceOf::testInstanceOf (12 bytes)
> @ 8 InstanceOf$A::m (0 bytes) failed to inline: virtual call
>
> vs
>
> void testInstanceOfCast(A obj) {
> if (obj instanceof B) {
> B b = (B)obj;
> b.m();
> }
> }
>
> InstanceOf::testInstanceOfCast (17 bytes)
> @ 13 InstanceOf$B::m (1 bytes) inline (hot)
>
>
> Proposed fix annotates operands of subtype checks with proper type information which reflects the effects of subtype check. Not-yet-canonicalized IR shape poses some challenges, but I decided to match it early so information is available right away, rather than waiting for IGVN pass and delay inlining to post-parse phase.
>
> FTR it is not a complete fix. It works for trivial cases, but for more complex conditions the IR shape becomes too complex during parsing (as illustrated by some test cases). I experimented with annotating subtype checks after initial parsing pass is over, but the crucial simplification step happens as part of split-if transformation which happens when no more inlining is possible. So, the only possible benefit (without forcing split-if optimization earlier) is virtual-to-direct call strength reduction. I plan to explore it separately.
>
> Testing: hs-tier1 - hs-tier5
src/hotspot/share/opto/parse2.cpp line 1739:
> 1737: }
> 1738:
> 1739: // Match an instanceof check.
We seem to require that the input of `SubTypeCheck` is not `null`. What do you think about allowing `SubTypeCheck` to accept `null` and return `false`?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28517#discussion_r2568870697
More information about the hotspot-compiler-dev
mailing list