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

我使用上面的代码创建了一个dedicated project。基准测试使用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有一些标志）可以确认。

Answer 2

另一个答案已过时且不再有效。在 Java 11 中，默认方法像抽象类中的虚拟方法一样被内联。

然而，在抽象类中，宏态默认方法的速度是宏态虚方法的两倍。

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

2 个答案: