request for review (L): 7121756 Improve C1 inlining policy by using profiling at call sites

[Roland Westrelin]

> I guess something similar could be achieved by utilizing the regular tiered infrastructure (level 3 and/or interpreter) for profiling and then recompiling with C1 with type checked guarded inline like you did. So, this could've been, say, level 3.5 and tiered would've used it instead of current level 4 as a final compilation state (with perhaps substantially lower compile thresholds in this case). Have you tried doing something like that?

Yes something similar could have been achieved that way and that's actually what I tried first but results were not good.

The gain when going from c1 to c1 + extra inlining here is not as big as when going from c1 to c2 in tiered so the risk is that the gain you get from running the improved code once it is recompiled doesn't make up for the slow down due to the profiling code.

Profiling here happens out of line. Once a call site is seen a sufficient number of times, profiling is disabled and it causes no extra cost. If a call site is found to be hot and a recompilation is triggered, no more profiling code is run at this call site until the new code is ready. If a call site is found to be warm (the benefit from recompiling is not big enough but the cost of profiling is too high), profiling is fully disabled and there is no need for a new compilation to get code without profiling, so compiler threads are not loaded and new better code for other methods will get ready sooner.

To inline a virtual call here, we need to know whether a single receiver exists or not. If there's more than one, knowing what the others are doesn't matter. So profiling data can be collected at inline cache state change which is essentially free.

In principle it's similar to tiered but because the gain from c1 to c1+extra inlining, it has its own specialized way of collecting profile data tailored to get only what it needs with the smallest extra cost.

Roland.