Re: 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.ll...@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