MaxBCEAEstimateSize and inlining clarification

[Vladimir Ivanov]

>     Profiling info isn't used at all. At the beginning all calls with
>     known targets are already static calls (CallStaticJavaNode in the
>     IR). And during analysis only static info (CHA) is used to
>     devirtualize calls.
>
> Thanks.  Does that mean that marking classes/methods final helps here
> even if at runtime there're no subclasses? I know marking
> classes/methods final removes the need to register guards (by virtue of
> making the call static when receiver is final), but does it have added
> benefit for EA purposes here as well?

Marking classes/methods final can only reduce number of dependencies 
associated with a method, produced by CHA, but it doesn't give any new 
information to the analysis itself, so shouldn't affect inlining decisions.

> I'm slightly confused by your "only static info (CHA) is used to
> devirtualize calls" statement.  Are you referring to the same CHA
> concept where loaded class hierarchy is inspected? It sounds like you're
> not since you mention "static info", but CHA is dynamic in my mind.  I'm
> probably misinterpreting this.

Yes, sorry for the confusion. That's the same concept which is used 
during ordinary inlining: class hierarchy inspection and nmethod 
dependencies to trach changes.

>     It's not that simple, since the flags use dumping logic not
>     available in product binaries (e.g., Node::dump() to print
>     corresponing IR nodes).
>
>     I don't see a compelling reason not to have all the dumping logic
>     available in product binaries, but it's much larger project,
>     comparing to changing type for a couple of flags from "nonproduct"
>     to "diagnostic".
>
> Ok, understood.  I do think this would be very valuable, so if you guys
> can make it happen it'd be greatly appreciated.

Filed JDK-8165716 [1].

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8165716