MaxBCEAEstimateSize and inlining clarification

[Vladimir Ivanov]

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

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

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

Best regards,
Vladimir Ivanov