MaxBCEAEstimateSize and inlining clarification

[Vitaly Davidovich]

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/f09966da/attachment.html>