MaxBCEAEstimateSize and inlining clarification

[Vitaly Davidovich]

On Wed, Sep 14, 2016 at 1:50 PM, Ruslan <cheremin at gmail.com> wrote:

> Afaik, InlineSmallCode is 2000 in 1.8+. Which makes such scenarios not so
> often
>
If you disable tiered compilation, it's 1000.

----
> 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? :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160914/bd4ad854/attachment.html>