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 版本的二进制下载。

关于受访者

Gil Tene是 Azul Systems 的 CTO 与联合创始人，他在过去 25 年的工作中都在与虚拟机技术打交道，并且从 1995 年就开始创建基于 Java 技术的产品了。

查看英文原文： InfoQ Talks to Azul Systems Gil Tene about Zing, Zulu, and New Releases