JDK-8272873 : C2: Inlining should not depend on absolute call site counts
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,17,18
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-08-24
  • Updated: 2024-02-06
  • Resolved: 2021-08-26
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 18
18 b13Fixed
Related Reports
Relates :  
Description
C2 considers absolute call site counts in its inlining decisions, which seems very wrong considering the asynchronous nature of profiling and background compilation (See InlineTree::should_inline()). It causes substantial over-inlining, which in presence of a depth-first inlining can lead to an early cut off. It also is inherently unstable. C2 already uses call frequency as an additional factor and it's better to consider only that in the inlining heuristic. I did extensive benchmarking it yielded almost no losses and single-digit wins (up to 5%) on some benchmarks. I think it's safe to remove/deprecate InlineFrequencyCount and continue using InlineFrequencyRatio instead. I found that converting the frequency computation to FP and setting InlineFrequencyRatio=0.25 (inline a method that is called a least 25% of the time) works best.
Comments
Changeset: 673ce7ef Author: Igor Veresov <iveresov@openjdk.org> Date: 2021-08-26 00:17:15 +0000 URL: https://git.openjdk.java.net/jdk/commit/673ce7efa56e7eb54266af6fe795d46d57f51bdc
26-08-2021

ILW = Performance loss due to wrong/sub-optimal inline decisions, medium?, no workaround = MMH = P3
24-08-2021