MaxBCEAEstimateSize and inlining clarification

[Vitaly Davidovich]

On Thu, Sep 8, 2016 at 11:53 AM, Vladimir Ivanov <
vladimir.x.ivanov at oracle.com> wrote:

>
>     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.

Right.  We're on the same page now with respect to "static info (CHA)" :).

By the way, and this is off-topic to this thread (apologies), but while
we're discussing marking classes/methods final, are there any other
footprint advantages to doing it even if CHA will devirt calls properly? So
removing the need to register dependencies is one, and is good.  Are the
vtables smaller for these cases? Anything else that's an added benefit
(from JVM runtime standpoint)?

>
>
> 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.

Yup, all good - thanks.

>
>
>     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].
>
Thank you!

>
> Best regards,
> Vladimir Ivanov
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8165716
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160908/dc2fca30/attachment.html>