As noted before, static finals can be treated as true constants by the JIT (after class initialization). And all JITs seem to do a good job with that. Code guarded by a static final boolean is effectively free (when the boolean is off), except for it's potential impact on inlining decisions in some JITs (which are sometimes driven by byte code counts on the target methods).
The Zing JVM now does what we call "Truly Final" optimization in our latest releases with the Falcon JIT compiler. These optimizations apply to any instance field declared final (private or not doesn't matter), and they allow the JIT to do some important optimizations that were not previously possible (e.g. hoist final field lookups out of loops, and along with them eliminate dependent operations from the loops, like range checks on final arrays. See cool discussion of this "problem" here <http://psy-lob-saw.blogspot.com/2014/02/when-i-say-final-i-mean-final.html>. Instance fields that have their finality overridden (e.g. via reflection or via Unsafe) will have this optimization dynamically disabled before the override occurs. On Monday, December 19, 2016 at 12:58:07 AM UTC-8, Richard Warburton wrote: > > Hi, > > You're right that serialization is called out, but I always understood >> that as Java serialization, and not some other type of serialization. >> You're right that in practice it's hard to know for the JIT and the >> practical implication is everyone is allowed to do it, but again, on paper >> I thought it refers only to builtin serialization. This is a good example >> of a feature that's rarely (relatively) used but is an optimization fence >> for all code. >> >> As for deopt tracking, I believe the current plan is to track this at the >> class level, not a field - I think this makes it more palatable and doesn't >> require using modules. But we'll see how this pans out. >> > > I'll be intrigued to see what happens on this front, specifically whether > the de-optimisation path traps Unsafe usage. BigInteger is a good example > of a JDK class that doesn't use reflection to set a final field, but uses > Unsafe, albeit only in serialization. > > regards, > > Richard Warburton > > http://insightfullogic.com > @RichardWarburto <http://twitter.com/richardwarburto> > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
