在堆增大的同时确保垃圾回收停顿时间短暂——专访 Cliff Click 博士

  • Charles Humble
  • 崔康

2010 年 4 月 27 日

话题:JavaJVM语言 & 开发架构

为了达到所需的吞吐量,越来越多的采用 Java 编写的企业级应用把大部分处理过程从数据库转移到内存中。这类应用的特点是存在大量活跃堆数据和线程级别的并发,并且往往运行在高端多核处理器上。这种特点意味着堆大小和垃圾回收停顿时间之间的强相关性成为 Java 应用伸缩性的主要限制之一,专家进行了大量的研究以努力改进这种情况。

例如预计今年推出的 Java 7 中,即将包含一个新的垃圾回收器— Garbage-First—目的是确保持续的短停顿时间,尽量消除低延迟 / 高吞吐量之间的折衷。与这种纯软件方法相反 Azul Systems硬件基于自定制的 54 核处理器构建,专为运行高标准 Java 应用程序设计,支持内置于处理器的写操作和读操作屏障。InfoQ 最近采访了 HotSpot Server 编译器的前架构师和首席程序员、现任 Azul Systems 公司首席 JVM 架构师的 Cliff Click 博士,讨论了 Azul 的解决方案。第一个问题是 Azul 硬件适用的领域:

任何需要可靠的低停顿时间(业务关键应用)或者超大堆的领域。类似金融建模的超大堆应用可能需要 300G 大小的堆存储金融数据,然后通过数百个处理器并行操作。我们针对 Java DB 缓存也做得很好,在缓存中提供 10 到 100G 的数据。

低停顿时间应用通常意味着你希望及时地将网页回馈给客户。几秒钟的延迟通常会让客户认为“网站关闭了”并转向他处或者提出投诉。一些大牌公司在 Azul 设备上部署 Web 展现应用,因为我们能够提供高负载下的出色(平稳)响应时间。一些典型的用途如客户的门户网站、大缓存(针对性能和扩展性)和内部业务应用的 Web 版(如库存管理、“请假系统”等等)。

InfoQ: 按照我的理解,Azul 硬件的关键优势之一是它直接支持写操作和读操作屏障以获得低 GC 停顿。是这样吗?

是啊!特别是,拥有读操作屏障允许你切换到较简单的 GC 算法—更易于并发、扩展和强壮。我们在多年前已经改变了算法,我们的垃圾回收机制能够处理超越竞争对手数量级大小的堆(和分配频率)。

InfoQ: 显然采用软件也能够做到。哪些情况下值得使用硬件?

学术文献已经对该领域做了很多探讨,已知的问题是单线程性能下降大约 10% 到 20%。IBM 的 Metronome 硬实时垃圾回收器采用 Brooks 风格的读操作屏障,并极力把延迟时间降低到正常回收器的 30%... 但是,一些消耗在于硬实时和不仅仅是读操作屏障。IBM 的确卖出了 Metronome 回收器(我相信大部分是军事领域)。

InfoQ: Azul 的 GC 停顿与 Oracle 的 Garbage-First 垃圾回收器或者使用 Java 实时产品相比如何?

我觉得 G1 将很有意思... 如果有的话。我们的垃圾回收器到目前为止已经在生产环境中稳定运行了 4 年。我认为现在与 G1 比较为时过早。

实时 Java 产品往往存在一些问题导致它们不适合大型企业应用——通常是 GC 局限于 4G 堆大小或者单垃圾回收器(有时是单 mutator 线程)。RTSJ 规范要求程序重写以使用有限的内存。

InfoQ: 对于 GC 来说,并发存在哪些局限?是否存在某部分 GC 算法在非并发情况下效率也很高?

人们总是把堆搞得难以并发收集,但实际上大多数大型堆有足够的并发性。其他 GC 问题也可以逐个解决,我们多年来一直在进行这项工作,并有了极具扩展性和并发性的 GC。我们能够(有时候)有效地并发运行超过 100 个 GC 线程。

InfoQ: 是否计划开源 Azul 虚拟机(或者重新为 OpenJDK 项目工作)?

我们一直在考虑开源部分成果,因为这很有意义。例如,我们的 CheckedCollections 和 LockedCollections 捕捉(或者纠正)常见的编程错误,如标准的非锁定 Collections 类被多个线程使用同时一个线程正在写入。

Azul 虚拟机的更多信息可以查看这里或者 Click 博士的博客

查看英文原文Keeping Garbage Collection Pauses Short with Growing Heap Sizes: Q&A With Dr. Cliff Click

JavaJVM语言 & 开发架构