MaxBCEAEstimateSize and inlining clarification
vladimir.x.ivanov at oracle.com
Thu Sep 8 15:53:11 UTC 2016
> 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 .
More information about the hotspot-compiler-dev