0

最近，我在这里阅读了关于 JVM 优化的文章，这很棒，
但是我对一种优化有疑问，即Null Check Elimination（或 Uncommon trap）

总而言之，Null Check Elimination删除了 aif (obj == null) ...并希望最好，而如果遇到Segmentation Fault它会重新编译代码，这次包括被忽略的if (obj == null) ....

我的问题是，鉴于：

bool foo(MyClass obj)
{
   if(obj == null)
      return false;
   m_someVar++;
   obj.doSomething(m_someVar);
}

因为 Null-Check 已被消除，并且仅在m_someVar++.
当 c 为空时， foo 会执行m_someVar++额外的时间吗？

编辑：

是否有一些资源可以更深入地解释这种优化的实现，它解释了这种优化如何使代码在语义上保持不变？

谢谢

4

2 回答 2

1

有很多可能性可以避免这个问题：评论中已经提到了延迟或撤销增量。JVM 有一大堆技巧，其中一些适用：

  • 当obj.doSomething(m_someVar)是非虚拟方法调用（private或final方法，或从未覆盖的方法）时，它可能需要显式的空检查（*），因为不会有 SEGV，但必须在调用之前抛出 NPE。我假设该方法没有内联，否则应该在内联后应用此分析。
  • 什么时候obj.doSomething(m_someVar)是一个虚方法调用，那么你必须做“方法分派”，即，obj.getClass().getPointerToMethod("doSomething(int)")为了确定调用什么具体方法。我写了“类似的东西”，因为这样做确实非常耗时，并且会尽可能地优化。这个调度可以移动到增量之上，它本身会抛出一个 NPE，如果obj碰巧是null.
  • 如果幸运的话，调度可能看起来像if (obj.getClass() != MyClass.class) uncommon_trap();，这是最简单的情况（称为“单态调用站点”），但即使这涉及取消引用obj，您也会再次获得null.

(*) 空值检查可能看起来像汇编程序中从相对于指针obj.getClass()的固定偏移量加载的单条指令。obj当然obj == null后一个未映射的页面被击中。

于 2017-09-05T04:03:41.650 回答
0

它认为您误解了空检查消除实际上是关于什么的。

实际上，它是关于消除（例如）在实例上调用方法时隐含的空检查。

在您的示例中，if(obj == null)不会消除显式。这将（如您所见）改变程序的行为。消除该空检查将是不正确的优化。

但是，下面的隐式空检查HERE：

bool foo(MyClass obj)
{
   if(obj == null)
      return false;
   m_someVar++;
   obj.doSomething(m_someVar);  // HERE
}

可以消除，因为 JIT 编译器应该能够推断出obj在代码到达该点时将始终为非空。（不过，这是一种不同的空值检查优化。）

是否有一些来源可以更深入地解释这种优化的实施......

我不相信。至少，没有什么是确定的。（除非您计算 JIT 编译器源代码中可能的注释！）

未指定 JIT 优化器行为。只要不违反 JLS 中定义的 Java 语义，它基本上可以做任何事情。

...这解释了这种优化如何使代码在语义上保持不变？

正如我所解释的，您正在阅读的乐观空检查消除优化不适用于您的示例。（这会使代码按照 JLS 的行为不正确。）

于 2017-09-05T05:05:12.713 回答