Covariant overrides on the Buffer Hierachy

[Joe Darcy]

Hello,

I'm reminded of Professor Knuth's observation that "Premature 
optimization is the root of all evil."

If from an API perspective the new code is preferable, I would say that 
should take precedence over an at most marginal performance degradation. 
If performance of is a high concern in that area, perhaps a jmh 
experiment could help tease about the difference in speed.

-Joe

On 04/27/2014 04:08 PM, Richard Warburton wrote:
> 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>