MaxBCEAEstimateSize and inlining clarification

[Ruslan]

Afaik, InlineSmallCode is 2000 in 1.8+. Which makes such scenarios not so often
----
Ruslan

> 14 сент. 2016 г., в 19:15, Vitaly Davidovich <vitalyd at gmail.com> написал(а):
> 
> Looking at PrintInlining output of an application with places where SR isn't happening (but should, in my mind), it appears that lots of call graphs along the path where the object "escapes" end because some part of the path fails to inline with "already compiled into a big method" failure reason.  So basically we end up hitting a "black hole" along the way, and the JIT can no longer prove the object doesn't escape.
> 
> I wonder how 1000 (when tiered is disabled) for 64bit was chosen as the default value for InlineSmallCode - is that still the current thinking as a good default? I understand the rationale for this check, but it also seems like this heuristic is somewhat problematic; how do we, for example, know that inlining that method (and whatever was inlined into it to cause it to be > InlineSmallCode) won't produce smaller machine code because more optimizations can be done? It also seems like it would be nice to force inlining if bcEscapeAnalysis estimates that some allocations can go away as a result.
> 
> Also, is the size of the method already taking into account any untaken/cold code pruning that was done prior to code gen? I assume so, but just wanted to check.
> 
> Finally, would it be possible to print out the actual native code size as part of the "already compiled into a big method" message? Otherwise, it's hard to say what value I should try for InlineSmallCode.
> 
> Thanks
> 
> P.S. When is @ForceInline going to be part of Java SE? :)