MaxBCEAEstimateSize and inlining clarification

[Vitaly Davidovich]

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

>
>     Yes, it's sort of "pseudo inlining". EA happens after inlining is
>>     over (both parse & post-parse phases). For calls with known target,
>>     EA performs static analysis to compute escape info for arguments. It
>>     happens for methods smaller than MaxBCEAEstimateSize.
>>     MaxBCEAEstimateLevel limits the inlining depth during analysis.
>>
>> By "known target", does that take profiling into account or it has to be
>> statically known? But basically, it sounds like this is what Roland said
>> -- any methods not inlined for whatever reason (not hot enough, too big,
>> etc) are also inspected for EA purposes, but with the
>> MaxBCEAEstimateSize and Level limits.
>>
>
> 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?

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.

>
>
>     I wish -XX:+PrintEscapeAnalysis & -XX:+PrintEliminateAllocations
>>     were available in product binaries, but they aren't, unfortunately.
>>
>> Yes, that would be great! Is there a good reason they couldn't be turned
>> into prod flags for, say, java 9?
>>
>
> 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.

>
>
>     You can build an "optimized" JVM though. It's close to product
>>     binaries w.r.t. speed, but contains also provides most of diagnostic
>>     logic (e.g., all nonproduct flags are available).
>>
>>
>>     If autoboxing is involved, you can try -XX:+AggressiveUnboxing.
>>
>> So I see this is behind UnlockExperimentalVMOptions (I'm on 8u92).  Some
>> of the instances I'm seeing are, indeed, autoboxing.  Is this feature
>> stable? What additional optimizations does it enable? Or put another
>> way, why is it experimental? :)
>>
>
> The approach to box elimination it does is more reliable (operates on
> valueOf calls instead of an inlined method).
>
> At least, we are not aware of any bugs in the implementation. It is still
> experimental because we haven't had time to test it thoroughly yet and it
> went out of our radars after intergration.. Hope to take care of it in 9u.
>
Ok, thanks.

>
> Best regards,
> Vladimir Ivanov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160908/6f6a4281/attachment.html>