MaxBCEAEstimateSize and inlining clarification

[Vitaly Davidovich]

Hi Kris,

On Thu, Sep 8, 2016 at 12:14 PM, Krystal Mok <rednaxelafx at gmail.com> wrote:

> 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.
>
Right.  I just wanted to make sure that was the case here.  "JIT-time
static" would prevent confusion :).

>
> 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.
>
Yes.  I make use of that quite a bit to make javac-time dynamic expressions
be JIT-time constants.  However, I hope the whole trusting final instance
fields stuff happens soon.  Otherwise, seemingly const-foldable code like
this:

static long makeMask() {
    return (1L << SomeEnum.A.ordinal()) | (1L << SomeEnum.B.ordinal()); //
etc
}

isn't folded when makeMask is compiled.  But make that mask a static final:

static final long MASK = // same expression as above

and we're good.


> Just my two cents ;-)
>
> - Kris
>

Anyway, we're going off on a tangent here, but thanks for the thoughts
Kris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160908/ab2db77d/attachment-0001.html>