Implement an inlining policy that takes PGO data more directly into account.

The general heuristic for an inline should be something like:

Cost = code size impact (may be negative) Benefit = (global importance) * (local importance) * (per-call benefit) Inline if: Cost <= 0 ;; inline is "free" Benefit/Cost > threshold ;; code size growth is justified by perf win Global importance is somehow related to how often the root method is called. Perhaps non-linear, say max(1, log10(#calls/10,000)) + 1 Local importance is the normalized execution count of the call site, that is call site count / method entry count Per call benefit is related to the likelihood of callee specialization / caller benefit roughly how many cycles are saved per call by doing the inline 

Suggest we start with the ModelPolicy which already has most of this structure, and amend/modify/clone it. Make the threshold adjustable and start to experiment.

We can use the size estimates that it produces as that seemed fairly accurate (in particular pretty good at predicting size-decreasing inlines).

Perhaps leave off global importance for now as we can't necessarily infer from TieredPGO how often a method is called, the value will depend in part on the rate of promotion to Tier1. So low method entry count may just mean the method got tiered up quickly (on the other hand, a high count does mean the method is called a lot).