Azul Systems 将要开源 Managed Runtime Initiative 中的重要技术

现在有越来越多的产品服务器在运行着托管代码，无论是 Java、.NET、Ruby 还是 Python，然而无论是硬件还是操作系统，其基本设计上都没有考虑到对这种情况进行优化。这导致的一个问题就是在垃圾收集（GC）时所产生的停顿现象。

对于众多的企业架构师和开发者来说，一方面越来越多的程序被放在了内存当中，另一方面 GC 会产生停顿现象，如何权衡这两者已经成为一个棘手的问题。在企业级 Java 中，这种停顿所带来的影响可以通过分布式程序（降低堆的大小）来缓解，或是通过其他技术解决，譬如在吞吐量比响应时间更为重要的情况下，可以通过异步调用以“批处理”的方式解决。

虽然从工程角度来看，这些解决方案是合情合理的，但结果却并不理想。在与 Azul Systems 技术副总裁兼 CTO Gil Tene 的对话中，他对目前的情况和 DOS 时代的核心与扩展、增强的内存模式进行了比对，后者的设计目的是在 PC 支持的情况下，充分利用 640KB 限度之上的内存。

我们的经验与推测表明在运行普通的企业负载的情况下，单核的至强可以产生~0.5GB/sec 的新对象。由于现在每个 Socket 可以持有 6～8 个核心，因此 $20K 以下的系统可以持有 12～48 个核心，这样在现代系统（假设 CPU 的实际处理能力都用在了有用的地方）上就会达到 5-15GB/sec 的分配率。 上面提到的~0.5GB/sec 有些主观臆断，说的不太清楚，我们所看到的实际范围（每个核心从 150MB 到 1+GB/sec 不等）取决于工作负载。如果主要工作是“转换型”负载（比如消息总线、Web 应用、集成服务器、DB 为中心的事务性负载、数据缓存等等），那么分配率就会高一些；如果主要工作是数字计算型负载（比如蒙特卡罗模拟、加密、压缩、有限元分析等等），那么分配率就会低一些。可以通过常见的工业基准找到一些支撑数据，但我并不热衷于这些基准，主要是因为他们都忽略掉了真实世界的 GC 效应。关于 GC，这些基准普遍存在的一个盲点是他们都是人们刻意制造出来的，但在运行时却忽略掉了 GC 效应，没法填满一台现代服务器并进行度量。通过与假设保持紧密的一致性并避免长期的堆搅动问题（会在运行期导致实际的压缩 GC 事件），他们可以长时间维持基准以度量吞吐量，接下来在包含的时间窗口之外产生完整的 GC 事件时有意忽略掉不可避免的失败情况。然而，就像这些基准没法推断负载下真实世界的应用行为一样，可以在每个 OP 分配时（几个调查已经做过这些事情了）度量其工作量，之后的数据就可以用于表示这些负载上的对象分配率了（以及生成的垃圾）。

举个例子吧：

JOP 是 SPECjAppServer2004 基准中的操作度量（我想它代表的应该是 Java 操作），请查看 www.spec.org 来了解详情。这是一个单元数，表示没有什么东西超出了度量，但可以比较基于同样基准的结果。

编辑注： 这些 OP 数来自于此。

Azul Systems 通过内置于硬件中的对写与读屏障的直接支持来解决垃圾回收问题。Dr. Cliff Click 最近曾向 InfoQ 解释过：

…可以切换到更简单的 GC 算法上：简单的算法更易于达到并行、可伸缩、并发以及健壮的要求。我们早就转换算法了，相比于其他竞争者来说，GC 所能处理的堆容量（以及分配率）要超出一个数量级。

Tene 说到即便是硬件，尤其是 Intel 和 AMD 最新的芯片都对托管负载提供了良好的支持，这样 Azul GC 算法就能同时应用在这两家处理器上了：

特别地，对于 Intel 来说，这意味着芯片包含了 EPT（Extended Page Table）特性（首度出现在 Intel 的至强 55xx 中，后来的至强 56xx、65xx 和 75xx 也都加入了）；对于 AMD 来说，芯片包含了 NPT（又叫做 AMD-V Nested Paging）。这些新的虚拟内存架构特性（EPT 和 NPT）都支持我们的 GC 算法，同时在 x86 平台上还有读屏障和高持久性的虚拟内存映射变化率。Vega 处理器包含了一个客户化的读屏障指令，它具有字段检查元数据和针对 GC 压缩页面的特殊的虚拟内存保护。我们基于 x86 的 JVM 使用多种 x86 指令执行与 Vega 读屏障操作相对应的语义，还使用了 x86 虚拟内存子系统来重新映射并保护 GC 压缩页面，这也达到了同样的读屏障效果，同时对于 Pauseless GC 算法来说也保证了算法的不变性。“读屏障”指令集是由 JIT 编译器发出的，并有效地融入到了正常的指令流当中（在这些现代的 x86-64 核心管道中拥有足够的空间来容纳他们），虚拟内存操纵使用了新的 OS API 以追上大量虚拟内存映射变化率的步伐（超出大多数 OS 所能保持的 100 多倍）。好处是借助于现代的 x86 核心中的 EPT/NPT 和健壮的 TLB（translation look-aside buffer）支持，我们可以轻松保持 GB/sec 的分配率：这仅仅是对软件所作的修改（比如 OS 内核），也是我们的 Managed Runtime Initiative 的用武之地。

Managed Runtime Initiative 目标是采取整体研究的方法。它关注可伸缩性和响应时间的改进，旨在增强垂直组件和系统堆栈（比如运行时、内核、OS 及管理程序）的接口。该项目有一个参考实现，包含了对 OpenJDK（Java 6）和可加载的 Linux 内核对象（LKO）的增强，还有一些模块提供了新的功能与接口，他们都基于 GPLV2 许可。

Azul 为 Linux 内核发布了一个针对 GC 优化过的内存管理、策略增强组件和新的资源调度程序，该程序兼容于 Red Hat Enterprise Linux 6、Fedora C12 和 Suse。对于 OpenJDK 来说，该发布包含了一个新的 JIT 编译器，不会停顿的垃圾收集器和可伸缩的运行时。Azul systems 说 JVM 与 Linux 的组合对运行时的增强是现在的 100 倍，对象分配率也提升了两个数量级（以及支持的堆大小）。

该项目还得到了 Java 编程语言的发明者 James Gosling 的支持。新闻如是说：

我对 Managed Runtime Initiative 以及 Azul 对开源社区的贡献感到兴奋。管理运行时由来已久，可以追溯到上世纪 90 年代。然而，系统堆栈的其他部分尚无法满足这些普适应用环境的要求。该项目会给系统栈带来很多新功能，这样管理运行时就会继续其成长和变革之路了。

开源知识产权的关键部分是个大胆的决定。Azul Systems 发展迅速，上个季度的收益比第一季度提高了64% 。他们希能从合作者、ISV 和厂商那里获得支持以转向其他平台和运行时，比如Windows 上的.NET，还有Ruby、Python 等。Azul 的第二个目标是希望能有商业产品使用优化的Linux 和OpenJDK，但这取决于厂商的参与和支持。

查看英文原文： Azul Systems To Open Source Significant Technology in Managed Runtime Initiative