<div dir="ltr">Hi all! Recently, I was looking into a severe performance regression in a library.<br>The regression was introduced when some methods were hoisted from final classes to their common abstract base class,<br>so that hoisted methods continue calling some abstract methods defined only in subclasses.<br>I was able to reproduce the issue with JDK 21, as well as with the JDK built from the main branch recently.<br><br>Turns out, if there is a bimorphic virtual call site that was monomorphic at the time a method was compiled by the C1 at 3rd tier <div>and the C1 was capable of resolving a virtual call and inline it, then when the call site became bimorphic, </div><div>C2 won't be able to perform bimorphic inlining at that call site. </div><div>If the C1 can't inline a virtual call at the initially monomorphic call site or the call site is bimorphic right from the beginning, </div><div>C2 successfully performs biomorphic inlining.<br><br>I added a small benchmark to reproduce the issue [1]. The benchmark starts with a monomorphic call site and<br>after a while, it makes it bimorphic by loading a second class and starts calling a target method on instances<br>of two sibling classes.<div>There are two benchmark methods: staticallyResolvableTarget and staticallyUnresolvableTarget.<br>The first one uses a class hierarchy such that the C1 is capable of inlining a virtual call as long as<br>the call site is monomorphic, and in the second case - the C1 can't (a target method is package-private).<br>The first case's performance is worse as the C2 can't apply bimorphic inlining at the end:</div><div><br></div><div>> Benchmark                                                (alwaysBimorphic)  Mode  Cnt  Score   Error  Units<br>> BimorphicInliningBenchmark.staticallyResolvableTarget                false  avgt   25  3.447 ± 0.009  ns/op<br>> BimorphicInliningBenchmark.staticallyUnresolvableTarget              false  avgt   25  3.152 ± 0.005  ns/op<br></div><div><br>For the slow case (staticallyResolvableTarget), the compilation and inlining sequence looks as follows:<br><br>> 568 3 org.example.BimorphicInliningBenchmark::staticallyResolvableTarget (19 bytes)(code size: 688)<br>>     @ 15 org.example.ClassHierarchyA::callSiteHolder succeed: inline (end time: 0.2520)<br>>       @ 1 org.example.ClassHierarchyA$SubclassA::inlinee succeed: inline (end time: 0.2520)<br>><br>> 572 4 org.example.BimorphicInliningBenchmark::staticallyResolvableTarget (19 bytes)(code size: 488)<br>>     @ 15 org.example.ClassHierarchyA::callSiteHolder succeed: inline (hot) (end time: 0.2520)<br>>       @ 1 org.example.ClassHierarchyA$SubclassA::inlinee succeed: inline (hot) (end time: 0.2520)<br>><br>> 572 make_not_entrant // the second class was loaded<br>><br>> 616 4 org.example.BimorphicInliningBenchmark::staticallyResolvableTarget (19 bytes)(code size: 488)<br>>     @ 15 org.example.ClassHierarchyA::callSiteHolder succeed: inline (hot) (end time: 4.2740)<br>>       @ 1 org.example.ClassHierarchyA::inlinee fail: virtual call (end time: 0.0000)<br>>         type profile org.example.ClassHierarchyA -> org.example.ClassHierarchyA$SubclassA (19%)<br><br>Call site's profiling data looks as follows:</div><div><br>>   1 invokevirtual 3 <org/example/ClassHierarchyA.inlinee()I><br>> 0 bci: 1 VirtualCallData count(25760) nonprofiled_count(0) entries(2)<br>>                                       'org/example/ClassHierarchyA$SubclassA'(9033 0.21)<br>>                                       'org/example/ClassHierarchyA$SubclassB'(8613 0.20)<br><br>Per-type counters were collected by the interpreter, and the regular counter ("count(25760)")<br>was incremented by the C1-compiled code. It seems like such a combination of counter-values stops the C2<br>from treating the call site as bimorphic [2][3] and the inlining doesn't happen (which is fair, </div><div>as counters look the same in the case of a megamorphic call site).</div><div><br>However, if the C1 can't inline a virtual call at the initially monomorphic call site,<br>counters will look slightly different, and the C2 will end up doing inlining:<br><br>> 0 bci: 1 VirtualCallData trap/ org.example.BimorphicInliningBenchmark::staticallyUnresolvableTarget(class_check recompiled) count(0) nonprofiled_count(0) entries(2)<br>>                                       'org/example/ClassHierarchyB$SubclassA'(34797 0.78)<br>>                                       'org/example/ClassHierarchyB$SubclassB'(9843 0.22)<br><br>> 619 4 org.example.BimorphicInliningBenchmark::staticallyUnresolvableTarget (19 bytes)(code size: 512)<br>>     @ 15 org.example.ClassHierarchyB::callSiteHolder succeed: inline (hot) (end time: 4.1750)<br>>       @ 1 org.example.ClassHierarchyB::inlinee (0 bytes) (end time: 0.0000)<br>>         type profile org.example.ClassHierarchyB -> org.example.ClassHierarchyB$SubclassA (95%)<br>>       @ 1 org.example.ClassHierarchyB$SubclassA::inlinee succeed: inline (hot) (end time: 4.1750)<br>>       @ 1 org.example.ClassHierarchyB$SubclassB::inlinee succeed: inline (hot) (end time: 4.1750)</div><div><br></div><div>You can find both benchmarking results and compilation logs in the repo along with the benchmark [4].<br><br><br>The question is if such a behavior is intentional (I didn't find an issue suggesting the opposite)<br>and if it is, what differs it from scenarios where a call site is always bimorphic and where the C2<br>successfully performs inlining (or where the C1 simply can't inline a monomorphic vcall initially)?<br><br>Thanks in advance,<br>Filipp.<br><br>[1] <a href="https://github.com/fzhinkin/bimorphic-inlining-issue/tree/main/">https://github.com/fzhinkin/bimorphic-inlining-issue/tree/main/</a><br>[2] <a href="https://github.com/openjdk/jdk/blob/7004c2724d9b150112c66febb7f24b781ff379dd/src/hotspot/share/ci/ciMethod.cpp#L489">https://github.com/openjdk/jdk/blob/7004c2724d9b150112c66febb7f24b781ff379dd/src/hotspot/share/ci/ciMethod.cpp#L489</a><br>[3] <a href="https://github.com/openjdk/jdk/blob/7004c2724d9b150112c66febb7f24b781ff379dd/src/hotspot/share/ci/ciMethod.cpp#L510">https://github.com/openjdk/jdk/blob/7004c2724d9b150112c66febb7f24b781ff379dd/src/hotspot/share/ci/ciMethod.cpp#L510</a></div></div><div>[4] <a href="https://github.com/fzhinkin/bimorphic-inlining-issue/tree/main/results">https://github.com/fzhinkin/bimorphic-inlining-issue/tree/main/results</a></div></div>