Covariant overrides on the Buffer Hierachy

[David M. Lloyd]

On 04/22/2014 08:24 AM, Paul Sandoz wrote:
> On Apr 22, 2014, at 2:48 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>
>> If the methods were final, AFAICT it'd be more like this:
>>
>> public final ByteBuffer position(int newPosition) {
>>     // iirc super upcall is already bytecoded as invokespecial
>>     invokespecial (Buffer)Buffer.position(newPosition);
>>     return this;
>> }
>>
>> public synthetic final Buffer position(int newPosition) {
>>     return effectively-invokespecial (ByteBuffer)ByteBuffer.position(newPosition);
>> }
>>
>> Since there would only be one possible target for the invokevirtual, my understanding is that the JIT will convert that into an invokespecial, letting the whole works be optimized at worst and inlined at best.
>>
>
> Here is a simple example with the Java 8 byte code
>
> public class TestBridge {
>      static class A {
>          public A pos(int i) { return this; }
>      }
>
>      static class B extends A {
>          public final B pos(int i) { super.pos(i); return this; }
>      }
> }
>
>    public final TestBridge$B pos(int);
>      flags: ACC_PUBLIC, ACC_FINAL
>      Code:
>        stack=2, locals=2, args_size=2
>           0: aload_0
>           1: iload_1
>           2: invokespecial #2                  // Method TestBridge$A.pos:(I)LTestBridge$A;
>           5: pop
>           6: aload_0
>           7: areturn
>
>    public TestBridge$A pos(int);
>      flags: ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC
>      Code:
>        stack=2, locals=2, args_size=2
>           0: aload_0
>           1: iload_1
>           2: invokevirtual #3                  // Method pos:(I)LTestBridge$B;
>           5: areturn
>
> I dunno why the synthetic bridge method is not marked as final.

Hmm that seems like a bug to me, I'll take it over to compiler-dev and 
see what they say...

> It's too hard for me to speculate what any performance impact might be. My suspicion is these methods are probably not used that often in hot loops so even if performance results are marginally worse the API improvement may trump that.

Yeah I am not sure we can say with certainty either way without testing. 
  But if there is a performance cost, IMO it should be done anyway, and 
the performance cost should be fixed in javac and/or the JIT.

-- 
- DML