Re: Style Police (a rant)
Jan Burse wrote:
Without the final keyword a JIT potentially needs to reoptimize
code, when classes are later loaded. Since although an analysis
might yield that a class method is actually not overridden,
it might still get overridden at run time.
Of course the problem is not so much there for JITs that do
call site specific PICs. So a method that is not overridden
will also have not multiple entries in the PICs.
But with the final keyword we can put a closure mark on the
PICs we don't need to bother of extending them at runtime
in case a new method implementation pops up at the call site.
And this could change the realization of the PICs.
So I guess this is not an urban legend. Unfortunately I did
document so much my findings that final has an impact. It
occurs to me once a while. But also I am switching the JDK
a couples of time, i.e. migrating form 32-bit to 64-bit.
With the 64-bit I noticed I different sensitivity profile.
Things that made the 32-bit JDK stumble don't have any impact
at all for the 64-bit. For example the garbage collection runs
very smooth with much less effort.
So not an urban legend but maybe yes a moving target.
Thanks for the information.
Except in performance-critical hot spots in code, such as yours presumably =
was, the movability of the target militates against such strategies. More i=
mportantly, use of 'final' on classes and methods is a semantic restriction=
; you have to be responsible for the consequences to program logic. Fortuna=
tely for your use case, it's frequently the right thing to do.
As usual, the rule is to do the right thing for the logic first and foremos=
t. The problem with your post on the optimization aspect is that it reads l=
ike a general rule when in fact it was a particular case for a particular e=
nvironment with a (presumably) important effect on (presumably) critical pe=
rformance. By your post cited here, it isn't even a durable effect. Again=
, the downside is mitigated by the likely semantic benefit of using 'final'=
in that context, but that seems more coincidental in this case than delibe=
rate.
I notice that you didn't describe your performance-test methodology. HotSp=
ot compilation has some interesting variation in its effects depending on r=
un-time considerations like whether you've heated up the analyzer (run thro=
ugh the code x thousand times), other things in the JVM, changes in the und=
erlying platform, brand of JVM (strictly speaking only Oracle's has "HotSpo=
t"), and so on. In your case I'll presume your methodology was rigorous en=
ough, although "Unfortunately I did document so much my findings that final=
has an impact" should make anyone nervous about that. But that does not m=
ean that one should recommend 'final' as a way to encourage inlining as a g=
eneral technique, particularly in the face of the many expert warnings agai=
nst that very practice.
--
Lew