TrustFinalNonStaticFields clarification

[Vitaly Davidovich]

Ok last try to get some insight :).

sent from my phone
On Apr 21, 2015 2:02 PM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:

> 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/20150423/00e17bcf/attachment.html>