Covariant overrides on the Buffer Hierachy

[Paul Sandoz]

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.

--

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.

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20140422/02e7af16/signature-0001.asc>