转载

InfoQ与Azul Systems的Gil Tene进行了一次对话，谈及了Zing、Zulu和新的发布

在提供JVM与算法服务方面，Azul Systems已经成为了业界的领先者，他们在大规模系统方面已经走在了业界标准的前面。Azul和CTO与联合创建人Gil Tene与InfoQ进行了一次对话，深入地讨论了Azul是如何应对业界的挑战的。

InfoQ：让我们首先来谈论一下Zing的新发布版本吧，这个版本是在去年9月发布的，正好是在JavaOne大会的前后。你能够说明一下这个新发布的特性，以及它在你的整个产品路线图中占据了怎样的位置吗？

Gil ：这个版本的发布有一些重要的意义。我想特别指出其中的两点主要意义，首先这是第一个支持Java 8的Zing版本，它比起Oracle的第一个Java 8只晚了6个月，在我看来这很了不起。除了Oracle之外，我们是唯一一个支持Java 8版本支持的JVM提供商，当然我们还有Zulu，这是我们的OpenJDK二进制发布版本，它同样也支持Java 8。因此我们在整个市场中具有一定的领先优势，等到Java 9推出时，我们还会进一步加快动作。

其次，我们加入了一个新的特性集，名为ReadyNow，它能够记录最优化的日志。它专注于避免或消除在启动时或在解优化时产生的放慢效应。这对于市场的开放或关闭等事件来说非常重要，也能够控制weby应用程序的响应时间。我们的许多商业服务客户要求我们实现这一功能。在Azul的历史上，在垃圾回收之后，这一点就是用户提出要求次数最多的特性了。

这一特性的开发目前已经经过了许多年，相关的需求也逐渐变得清晰。我们在今年早些时候启动了ReadyNow中第一部分特性集的开发，当时我们刚刚找到了解优化发生的根本原因，并且找到了某些方法，让编译器以某些特殊的方式处理方法。在新的发布中，我们新加入了一个功能，可以重用之前的运行中使用的优化日志，并使用这些日志影响这些运行时的决策。尤其它允许用户告诉JVM避免在前一次运行中使用过的激进的优化方式，这种方式在这次运行中会产生解优化，而这正是我们试图为用户解决的头疼的问题。

InfoQ：如果在某次运行中的表现与之前的基准产生了很大的偏差，我有时将其称为“美国非农数据日问题”（数据的好坏体现了经济的走势），这时候应该怎么做？如果你所记录的优化决策对于某些特别的日子来说并不是最佳的，又会发生什么事？

Gil ：我们现在所说的情况是指那些在昨天还运行得好好的优化决策，到了今天就变得不管用了，事实就是这样。我认为在这种情况下无法提供什么有效应对措施。不过，就我所见，这种情况非常罕见。更常见的情况是，某个所应用的优化在昨天一开始还能够运行，然后就开始出错并出现解优化情形，然后在昨天的运行中必然无法坚持到最后。

比方说，在交易算法中，代码会对大量的市场数据进行侦听，很可能只在偶尔的情况下才会运行（取决于交易算法的种类）。因此编译器会对不进行交易的场景进行优化，随后你发现你需要进行交易了，很显然此时你希望代码能够尽快运行。

希望在这一天结束的时候，JVM能够尽量平静下来，因此在初始化时使用的过于激进的优化方式能够被解优化，然后再根据真实的情况进行重新优化。这条知识能够保留在你的脑海中，你能够重新应用它，而无需每天都要重新学习一遍。

InfoQ：有哪些方面的优化例子能够归类到这一类中？

Gil ：根据较小的代码集对类结构层次进行优化，之后可能会被classloading失效。或是任何基于未采取路径的优化措施，例如某个分支的预测。不过，重要的是要理解我们不会记住昨天运行时的优化，我们也不会在启动时应用编译优化。我们所记住的是状态，这一点区别非常重要。Java对于初始化具有清晰的定义，我们无法促使它提前发生。因此我们所拥有的是一个完整的状态集合，只有在类可用的时候，我们才能够应用优化措施。

InfoQ：让我们谈谈Zulu吧，这是你们新的OpenJDK版本，我还看到你们在发布会上表示这是目前唯一一个支持的OpenJDK版本。那么Red Hat的IcedTea产品呢？是否表示Red Hat还没有推出一个IcedTea的OpenJDK 8版本呢？

Gil ：是的，没错。我每隔几周就会看看这方面的发展情况，但截至目前为止，我们是唯一一家提供OpenJDK 8的二进制分发下载的。你可以从其它人那里获取实验性的源代码树编译，但Red Hat应该是唯一能够获得OpenJDK二进制下载包的其它来源了。

InfoQ：Debian似乎也打算发布一个OpenJDK 8版本。

Gil ：如果你拉下它的源代码并生成一个“Java版本”，你就会发现它宣称自己支持Java 8 Update 40，而这个版本要到2015年3月份之后才会存在。这是个绝佳的讽刺，从互联网上下载某个二进制文件并且认为它能够做到它声称所能做到的事，事实并非如此。现在并不存在JDK Update 40，这里的问题在于，Docker将其用做一种“官方”的Java版本，然而等到真正的Update 40发布之后，这个二进制包将会变得非常不同。“Update 40”这个名称不应当用于当前他们所发布的产品之中，而这一点不仅仅发生在一个公司中，由于这些公司提供了错误了名称，用户因此不知道自己是否还能够相信OpenJDK的版本了。

作为一种直接的反应，我们在Zulu中也进行了某些工作。Azul对我们的二进制版本进行了认证，某种特别的.rpm、或.deb、或.zip文件会带有一个特殊的校验和，它通过了所有测试（包括了我们的压力测试），它与Java测试兼容包（TCK）完全兼容，并且已经通过了Java规范的兼容认证。我们对所发布的所有二进制包都进行了认证，因此人们知道他们可以相信Zulu。我不清楚这能否完全解决这种情形，但我认为能有人为OpenJDK的二进制包的创建负责，确定他们所提供的二进制包的“正确性”，这有助于排除这些混淆情形。比方说，我也乐于看到Red Hat这么做，因为我知道他们创建了非常优秀的、经过良好测试的JDK。

InfoQ：因此实际上，Debian（以及Docker）的OpenJDK并没有通过任何测试兼容包的测试。

Gil ：没错。我们之所以知道这一点，是因为我们可以查看OpenJDK TCK的网站上有关签约的部分，可以看到上面没有任何来自于Canonical或Debian项目的人。所以他们所放出的已知版本是不可能通过TCK测试的。

更新：在这次访谈记录之后，Canonical已经在SE 8的签约页面上加入了自己的名字。

InfoQ：我注意到FreeBSD基金会同样也在OpenJDK TCK的页面上签名了。

Gil ：我对此也感到非常吃惊，但这对他们来说是件好事，我也认为这是一件好事。我希望有些基于FreeBSD的应用能够需要使用Java，而且FreeBSD的家伙们已经走在了这场游戏的前头。OpenJDK TCK是一个相当友好的认证，任何打算创建或分发一种能够让终端用户信任的OpenJDK二进制包的人都应该利用这个认证。

顺便说一场，我们已经将Zulu部署在Docker库上了，如果你搜索Zulu（希望OpenJDK也是如此），那么你就能够找到对应JDK 6、7和8版本的二进制下载。