为什么这个代码片段在使用热点服务器 JVM 运行时实际上需要更长的时间？

Question

这是代码片段：

https://gist.github.com/987751

对我来说，它的时间就像：

java -client:
  for loop took:     23
  method call took:  19

java -server:
  for loop took:     0   # faster, as expected
  method call took:  48  # slower--expected?

所以第一个问题是“为什么它比客户端虚拟机慢”

另外我想下一个问题是“是否有可能为方法调用方式获得超级 0ms 加速（几乎相同的代码）？”

我还认为，尽管有这种奇怪的现象，热点通常运行得更快，即使有匿名类等？

谢谢！

-罗杰-

Answer 1

这都是关于如何调整两种风格的 Hotspot：

• 客户端已调整为快速（呃）启动。它“几乎”立即进行 JIT 编译方法。

• 在假定为长调整服务器实例的生命周期内，服务器被调整为高（更高）吞吐量。它让解释器在 JIT 编译方法之前运行方法的时间更长（收集使用情况统计信息）。然后（我相信）它会执行更积极的优化......这需要更长的时间。

相关答案：“java -server”和“java -client”？

顺便说一句，它是运行客户端和服务器模式的同一个 Hotspot JVM。 AFAIK，差异是由于两种模式选择不同的默认 JVM 调整/配置参数造成的。

---

所以第一个问题是“为什么它比客户端虚拟机慢”

我不知道。

也许客户端模式可以实现特定的优化，真正有助于这个（高度人为的）基准测试。或者也许服务器模式优化之一实际上是针对此（高度人为的）基准测试的反优化。如果你真的想知道，请让 JIT 编译器转储本机代码并详细分析它。 （但我认为这是浪费时间。）

而且我猜下一个问题是“是否有可能为方法调用方式获得超级 0ms 的加速（几乎相同的代码）？”

这很容易。优化器发现该方法调用不会影响其他任何内容，并优化了该调用。然后循环也可以被优化掉。

我还认为，尽管有这种奇怪的情况，热点通常运行得更快，即使使用匿名类等？

我认为你不应该假设任何事情。

然而，我也不认为你的微基准对真实程序有任何意义。一般来说，微基准往往会产生误导，而您的微基准是有缺陷的（例如，被优化掉的循环），并且似乎没有测试典型（编写良好的）Java 程序会做的事情。

如果您确实关心 HotSpot 两种模式的相对性能，则应该在实际数据上运行并测量应用程序的性能。

...为什么服务器 JVM 会选择看起来更糟糕的东西？

优化器旨在优化实际程序......而不是花时间做与有用计算没有任何相似之处的奇怪事情的微基准。并非所有优化在所有情况下都有益，并且您可能遇到了某种边缘情况。

但只有当您在实际应用程序中看到同样的事情发生时，这才有意义。

---

最后，您没有提供 JVM 版本、平台和硬件的任何详细信息。这些事情可能会对相对绩效指标产生巨大影响。