JDK-8326369 : Add test to verify bimorphic inlining happens after morphism changes
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,21,23
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2024-02-20
  • Updated: 2024-11-28
  • Resolved: 2024-11-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 24
24 b26Fixed
Related Reports
Relates :  
Description
When the tiered compilation is on, the C2 compiler doesn't perform bimorphic inlining at a call site if the call site was monomorphic when a method was compiled by the C1 at tier 3 but then morphism changed.

Following events trigger the issue:
- there's a class hierarchy consisting of an abstract base class and two concrete sibling subclasses, each implementing an abstract method;
- initially, only one of these sibling classes is loaded;
- a method with a yet monomorphic virtual call is compiled by the C1 and the compiler is capable of resolving a target method, thus the call is inlined;
- later, a second class is loaded and it it's instance start being a receiver at a call site mentioned above;
- previously compiled methods are invalidated and at some point the C2 recompiles a method with bimorphic call site, but it does not apply bimorphic inlining there.

If the problematic call site is bimorphic right from the beginning, or the tiered compilation is off, then the C2 successfully performs bimorphic inlining.

The benchmark illustrating the problem is attached to this issue, as well as a jtreg test reproducing the problem.

I was able to reproduce the issue with JDK17, 21 and 23 (built from the main branch recently).
Comments
Changeset: 5ccd5106 Branch: master Author: Galder ZamarreƱo <galder@openjdk.org> Committer: Andrew Dinn <adinn@openjdk.org> Date: 2024-11-21 09:48:08 +0000 URL: https://git.openjdk.org/jdk/commit/5ccd5106e023dbb47473e8914035c811e0cc6ee1
21-11-2024

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/21920 Date: 2024-11-06 09:06:47 +0000
06-11-2024

This issue was fixed by JDK-8339299.
06-11-2024

I've just run the reproducer jtreg test and it passes. I also run the benchmark and the inlining seems to happen right now: ``` 558 3 org.example.BimorphicInliningBenchmark::staticallyResolvableTarget (19 bytes)(code size: 832) @ 15 org.example.ClassHierarchyA::callSiteHolder succeed: inline (end time: 0.1650) @ 1 org.example.ClassHierarchyA::inlinee fail: no static binding (end time: 0.0000) 563 4 org.example.BimorphicInliningBenchmark::staticallyResolvableTarget (19 bytes)(code size: 448) @ 15 org.example.ClassHierarchyA::callSiteHolder succeed: inline (hot) (end time: 0.1650) @ 1 org.example.ClassHierarchyA::inlinee (0 bytes) (end time: 0.0000) type profile org.example.ClassHierarchyA -> org.example.ClassHierarchyA$SubclassA (100%) @ 1 org.example.ClassHierarchyA$SubclassA::inlinee succeed: inline (hot) (end time: 0.1650) 563 make_not_entrant 598 4 org.example.BimorphicInliningBenchmark::staticallyResolvableTarget (19 bytes)(code size: 448) @ 15 org.example.ClassHierarchyA::callSiteHolder succeed: inline (hot) (end time: 4.1830) @ 1 org.example.ClassHierarchyA::inlinee (0 bytes) (end time: 0.0000) type profile org.example.ClassHierarchyA -> org.example.ClassHierarchyA$SubclassA (95%) @ 1 org.example.ClassHierarchyA$SubclassA::inlinee succeed: inline (hot) (end time: 4.1830) @ 1 org.example.ClassHierarchyA$SubclassB::inlinee succeed: inline (hot) (end time: 4.1830) ``` Before, as shown in the benchmark, the second level 4 compilation would fail to inline it. I don't know right now which other issue has fixed this.
05-11-2024

ILW = Bimorphic inlining is expected but not applied by C2, reproducible but edge case, no workaround = MLH = P4
26-02-2024

The issue was initially discussed here: https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2024-February/073062.html
20-02-2024