TrustFinalNonStaticFields clarification

[Vitaly Davidovich]

Ok, but in the array case what's there to profile? At compile or parse time
isn't the array length known since it's set internally in the class?
Perhaps you're still calling this profiling, but to me it sounds like
keeping simple metadata about the fields.  The only thing that could break
this is reflection, but I naively thought enabling the flag would make
compiler more confident (I see now that this isn't the case).  The other
case here is tracking whether final field is nullable or not; lots of
constructors do a null check and throw if they see a null.  It seems, on
the surface, fairly easy to detect that and then "stamp" the field as known
not null.

How difficult would it be to profile or keep some metadata about final
fields that can be gathered at parse time, taking reflection out of the
equation for a second? It seems like some additional optimization
opportunities are missed now as a result of this.

Thanks

sent from my phone
On Apr 23, 2015 11:03 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> On Apr 23, 2015, at 6:51 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>
> if this field is final and set inside constructor only, why still have the
> null check if I'm asking to trust instance final fields?
>
>
> The answer to all of your questions is that we don't profile fields.
>
> We also don't do class-wide analysis, since reflection can break the
> results of such analysis.
>
> The JIT only trusts field values that it can observe directly, either by
> compiling the sets in the same compilation unit, or by folding a constant
> object reference.
>
> — John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150423/1fed8539/attachment.html>