MaxBCEAEstimateSize and inlining clarification

[Krystal Mok]

Hi Vitaly,

On Thu, Sep 8, 2016 at 6:54 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
> 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.
>

One general rule of thumb: when you see JIT people talking about "static
info" (e.g. statically resolvable target), that means values that are know
at JIT-compile time. Or simply, at compile time. From the JIT compilers'
point of view, CHA information is considered "static" with dependencies.

Speaking of "statically known", I'd like to make a side note about static
finals. Assuming we trust static finals will not be changed after first
assignment (excluding outliers like System.in, System.out, System.err),
then there's an interesting difference between what a JIT compiler consider
as "static constant" than javac.
In Java, "final" is really overloaded with two different meanings on the
language level: "const" and "readonly" (using C#'s terminology) -- "const"
for javac-level compile-time constants, and "readonly" for values that are
initialized at runtime, but stay immutable after initialization.
javac implements the Java Language Spec, and only treats "const" usage as
constants. On the other hand, to a JIT compiler, both "const" and
"readonly" usages would be considered as static constants, because the
value is known at JIT-compile time and won't change afterwards.

Just my two cents ;-)

- Kris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160908/fae5af1e/attachment.html>