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