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

  • Charles Humble
  • 张龙

2010 年 6 月 21 日

话题:Java语言 & 开发架构

现在有越来越多的产品服务器在运行着托管代码,无论是 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

Java语言 & 开发架构