On Apr 22, 2014, at 2:48 PM, David M. Lloyd <[email protected]> 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.
