Covariant overrides on the Buffer Hierachy (original) (raw)

Richard Warburton richard.warburton at gmail.com
Sun Apr 27 23:08:28 UTC 2014

Hi,

There are multiple possible targets for invokevirtual

position:(I)Ljava/nio/Buffer; - all the methods that override it in all subclasses loaded. It doesn't matter if they are final or not (only if they are effectively final or not). The non-finality of a method has a performance impact only if the method is overridden in any of the loaded subclasses, otherwise it is effectively final and treated as such by JIT (at least that's how I understand it - any hotspot JIT expert please debunk my claims).

That is only true if you are calling the method on the base class, which is normally seldom done (though it will be nearly always in legacy code, but see below). That might also be the answer to why the synthetic method need not be marked as final if the covariant method is. The synthetic method can never be overridden in a sub-class (at least not by javac) - only the covariant method can be. Doesn't sound quite right to me, but I'll defer to any experts who might wish to discuss it on compiler-dev. But as Paul noted, the methods on Buffer are probably not used in hot loops alone, since they are just for reading/adjusting position/limit/mark. The hot loops probably also contain methods for reading/writing the buffer and those are only defined on particular sub-types of java.nio.Buffer, so it can reasonably be expected that the static (guaranteed) type of target upon which methods are called in hot loops is a particular subtype of java.nio.Buffer and JIT only has one method to choose from in this case. Yeah new code will call the covariant final method directly in almost all cases for sure, having been compiled against it. The tricky case is old code - even if the JIT can figure out that it is really a subclass being invoked upon, it'd still be forced to target the non-covariant synthetic method due to the specific method reference in the bytecode. Hopefully at this point though, as you say, the lack of overriding classes will be enough to optimize the dispatch.

So interestingly the original patch didn't add final to the covariant overrides. I've updated the patch to do this.

http://cr.openjdk.java.net/~rwarburton/buffer-overrides-1/

I'm not sure what would satisfy people on the performance front. Some guidance would be most appreciated here.

regards,

Richard Warburton

http://insightfullogic.com @RichardWarburto <http://twitter.com/richardwarburto>

More information about the core-libs-dev mailing list