Graal final field treatment with respect to optimizations

[Tom Rodriguez]

> On Apr 24, 2015, at 6:55 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> Hi guys,
> 
> I recently had a thread on hotspot-compiler-dev where John Rose shed some
> light on what the TrustNonStaticFinalFields experimental flag implies in
> the C2 compiler:
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-April/017739.html
> 
> Based on that exchange, I see that there are some scenarios where some
> optimization opportunities are missed, specifically due to missing field
> profiling.  That got me thinking -- how does Graal handle this, and does it
> do something better here? Clearly Graal has to also be mindful of final
> fields being changed via reflection, but are there any speculative
> optimizations around trusting that final fields are mostly unchanged (or
> plans to do that)?

We have a similar flag TrustFinalDefaultFields which defaults to true.  I think anyone modifying final fields of published objects through reflection should just be laughed at and told to go away.  The hole that allows modification of final fields through reflection was introduced to support deserialization. Any other use should just be considered undefined behaviour.

tom