Java默认方法比相同的代码慢,但在抽象类中

Question

我有一个界面PackedObject:

public interface PackedObject {
    int get();
    int sum();
    void setIndex(int index);
    default int defaultSum() {
        return get();
    }
}

抽象类AbstractPackedObject:

public abstract class AbstractPackedObject implements PackedObject {
    protected int index = 0;
    protected int[] buffer;

    public void setIndex(int index) {
        this.index = index;
    }

    public void setBuffer(int[] buffer) {
        this.buffer = buffer;
    }

    @Override
    public int sum(){
        return get();
    }
}

并具体实施WrappedPackedObject:

public class WrappedPackedObject extends AbstractPackedObject implements PackedObject {

    public WrappedPackedObject(int[] buffer) {
        this.buffer = buffer;
    }

    @Override
    public int get() {
        return buffer[index];
    }
}

我的基准测试defaultSum和sum方法(JMH基准测试的片段):

    for (int i = 0; i < NB; i++) {
        packedObject.setIndex(i);
        value += packedObject.defaultSum();
    }

    for (int i = 0; i < NB; i++) {
        packedObject.setIndex(i);
        value += packedObject.sum();
    }

我试图弄清楚为什么sum基准测试器的速度比defaultSum基准测试快1.7倍.

我已经开始深入研究JIT奥术了.调用网站目标只有一种方法,所以我期待内联完成.打印内联的输出如下:

@ 25   com.github.nithril.PackedObject::defaultSum (7 bytes)   inline (hot)
 \-> TypeProfile (479222/479222 counts) = com/github/nithril/WrappedPackedObject
  @ 1   com.github.nithril.WrappedPackedObject::get (14 bytes)   inline (hot)
    @ 10   java.nio.DirectByteBuffer::getInt (15 bytes)   inline (hot)


@ 25   com.github.nithril.AbstractPackedObject::sum (5 bytes)   inline (hot)
  @ 1   com.github.nithril.WrappedPackedObject::get (14 bytes)   inline (hot)
    @ 10   java.nio.DirectByteBuffer::getInt (15 bytes)   inline (hot)

我还不明白为什么会出现这条线 TypeProfile (479222/479222 counts) = com/github/nithril/WrappedPackedObject

我用上面的代码创建了一个专门的项目.基准测试使用JMH完成.

谢谢你的帮助.

编辑2015/05/20:

我简化了java代码.

内循环benchSum很简单:

0x00007f1bb11afb84: add    0x10(%r10,%r8,4),%eax  ;*iadd
                                              ; - com.github.nithril.PackedObjectBench::benchSum@29 (line 50)
0x00007f1bb11afb89: mov    %r8d,0xc(%r12,%r11,8)  ;*putfield index
                                              ; - com.github.nithril.AbstractPackedObject::setIndex@2 (line 13)
                                              ; - com.github.nithril.PackedObjectBench::benchSum@17 (line 49)
0x00007f1bb11afb8e: inc    %r8d               ;*iinc
                                              ; - com.github.nithril.PackedObjectBench::benchSum@31 (line 48)
0x00007f1bb11afb91: cmp    $0x2710,%r8d
0x00007f1bb11afb98: jl     0x00007f1bb11afb84

内部循环benchDefaultSum更复杂,索引的读/写和内部循环内部的数组绑定的比较.我还没有完全理解这种比较的目的......

0x00007fcfdcf82cb8: mov    %edx,0xc(%r12,%r11,8)  ;*putfield index
                                              ; - com.github.nithril.AbstractPackedObject::setIndex@2 (line 13)
                                              ; - com.github.nithril.PackedObjectBench::benchDefaultSum@17 (line 32)
0x00007fcfdcf82cbd: mov    0xc(%r10),%r8d     ;*getfield index
                                              ; - com.github.nithril.WrappedPackedObject::get@5 (line 17)
                                              ; - com.github.nithril.PackedObject::defaultSum@1 (line 15)
                                              ; - com.github.nithril.PackedObjectBench::benchDefaultSum@24 (line 33)
0x00007fcfdcf82cc1: cmp    %r9d,%r8d
0x00007fcfdcf82cc4: jae    0x00007fcfdcf82d1f  ;*iaload
                                              ; - com.github.nithril.WrappedPackedObject::get@8 (line 17)
                                              ; - com.github.nithril.PackedObject::defaultSum@1 (line 15)
                                              ; - com.github.nithril.PackedObjectBench::benchDefaultSum@24 (line 33)
0x00007fcfdcf82cc6: add    0x10(%rcx,%r8,4),%eax  ;*iadd
                                              ; - com.github.nithril.PackedObjectBench::benchDefaultSum@29 (line 33)
0x00007fcfdcf82ccb: inc    %edx               ;*iinc
                                              ; - com.github.nithril.PackedObjectBench::benchDefaultSum@31 (line 31)
0x00007fcfdcf82ccd: cmp    $0x2710,%edx
0x00007fcfdcf82cd3: jl     0x00007fcfdcf82cb8  ;*aload_2
[...]
0x00007fcfdcf82ce6: mov    $0xffffffe4,%esi
0x00007fcfdcf82ceb: mov    %r10,0x8(%rsp)
0x00007fcfdcf82cf0: mov    %ebx,0x4(%rsp)
0x00007fcfdcf82cf4: mov    %r8d,0x10(%rsp)
0x00007fcfdcf82cf9: xchg   %ax,%ax
0x00007fcfdcf82cfb: callq  0x00007fcfdcdea1a0  ; OopMap{rbp=NarrowOop [8]=Oop off=416}
                                              ;*iaload
                                              ; - com.github.nithril.WrappedPackedObject::get@8 (line 17)
                                              ; - com.github.nithril.PackedObject::defaultSum@1 (line 15)
                                              ; - com.github.nithril.PackedObjectBench::benchDefaultSum@24 (line 33)
                                              ;   {runtime_call}
0x00007fcfdcf82d00: callq  0x00007fcff1c94320  ;*iaload
                                              ; - com.github.nithril.WrappedPackedObject::get@8 (line 17)
                                              ; - com.github.nithril.PackedObject::defaultSum@1 (line 15)
                                              ; - com.github.nithril.PackedObjectBench::benchDefaultSum@24 (line 33)
                                              ;   {runtime_call}
[...]
0x00007fcfdcf82d1f: mov    %eax,(%rsp)
0x00007fcfdcf82d22: mov    %edx,%ebx
0x00007fcfdcf82d24: jmp    0x00007fcfdcf82ce6

Answer 1

只是粗略地反复通过粗略阅读hotspot-compiler-dev邮件列表而获取的信息,但这可能是缺少接口中默认方法的类层次结构分析,这会阻止接口方法的虚拟化.

请参阅JDK Bug 8065760和6986483

我的猜测是,即使该方法是内联的,它仍然是一个类型保护,在抽象情况下被CHA消除,但不是接口方法.

打印优化组件(我认为JMH有一些标志)可以证实这一点.