TrustFinalNonStaticFields clarification
Vitaly Davidovich
vitalyd at gmail.com
Tue Apr 21 18:02:50 UTC 2015
Anyone? :)
In my brief experimentation on 7u60, only thing I noticed is Enum.ordinal()
replaced with constant in compiled method. I couldn't, however, get it to
constant propagate array length, eliminate null receiver check, etc.
sent from my phone
On Apr 20, 2015 10:58 AM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:
> Fixed the flag name in the subject.
>
> On Fri, Apr 17, 2015 at 9:07 PM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
>
>> Hi guys,
>>
>> I'm hoping someone could clarify/confirm my understanding of this
>> experimental flag's effects:
>>
>> 1) final instance array length is constant propagated? Even if array is
>> passed in as ctor arg rather than being instantiated in the ctor?
>> 2) final instance fields seen as never null are forever considered as
>> such? So even if a method call on that object is fully eliminated (e.g. the
>> method is empty) no null check is left behind?
>> 3) concrete runtime type of the instance field is propagated to uses and
>> no additional type checks are done? Say the declared type is an
>> interface/abstract with multiple implementations loaded but only one type
>> stored in the field - is a type check eliminated and calls are fully
>> devirtualized?
>> 4) primitive type final fields have their value constant propagated if
>> compiler sees only one value always stored?
>> 5) do derived classes and base class share field profile or not? For
>> example subclasses always store concrete type but each subclass stores a
>> different type from the others.
>>
>> Also, there's been some talk about doing these optimizations
>> automatically with invalidations builtin. Just curious where that stands.
>>
>> Thanks
>>
>> sent from my phone
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150421/f0ad6dd0/attachment.html>
More information about the hotspot-compiler-dev
mailing list