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