JRuby 近况:1.6 RC1、JSR 292 及 Java 7 中的 NIO2、1.9.2 支持

  • Werner Schuster
  • 丁雪丰

2011 年 1 月 19 日

话题:JavaRuby编程语言语言 & 开发架构

JRuby 1.6 RC1发布了,带来了一大串改进:Charles Nutter 给出了 JRuby 1.6 的一个概述,Tom Enebo演示了改进后的 Windows 支持,Yoko Harada罗列 JRuby API 的变化

InfoQ 就 JRuby 的现状与未来采访了 JRuby 的Charles Nutter.

InfoQ:​JRuby 1.6 中有什么大的变化?​

JRuby 1.6 RC​有超过 2000 次提交,解决了超过 260 个问题。这让 JRuby 1.6 成为迄今为止最大的发布。​

JRuby 1.6 RC 中的主要特性有:Ruby 1.9 兼容性——JRuby 继续跟进 Ruby 的最新版本,即 1.9.2,JRuby 1.6​承诺改善大多数 1.9 应用程序的兼容性,包括支持新的编码 API。改善 Ruby 代码的性能——JRuby 1.6 吸纳了很多增量的性能改进内容,包括 Ruby 1.9 中更快的标准库,还为日后的开发打下基础。

改善 Windows 支持——JRuby 1.6 发布了新一轮的 Windows 支持内容,包括内置对 WIN32OLE 的支持,还有其他一些兼容性补丁​,它们让 Ruby 应用程序能无缝运行于 Windows 之上,就像在其他平台上一样。​

Ruby 1.9.2 的兼容性已经完成的差不多了。还有一些特性会安排在后续版本中:Encoding::Converter、非 ASCII 标识符以及“ripper”和“fiddle”库。​我们希望用户能在 1.9 模式中测试 JRuby,在 1.6.0 最终版前发现那些剩余的问题。

InfoQ:​纤程(Fiber)怎么样了?

JRuby 1.6 RC 中​已经有纤程了,我们在今后的版本中会继续改善性能。​

InfoQ:我想最近的 MLVM 已经有了协程(Coroutine)支持(Lukas Stadler 的工作?)​;你有没有尝试过呢?​

我们已经尝试过了 MLVM,计划在后续版本支持它。​​

InfoQ:​Ruby 社区以及其他一些来自 Node.js 社区的人最近一直在谈论关于异步和非阻塞 I/O 的好处。你是怎么看待阻塞式 I/O 和非阻塞式 I/O 的?​

和其他东西一样,混合多种方法通常才是最好的。​​异步 I/O 允许你​将 I/O 通道放在一个工作队列里,当 I/O 通道等待时释放线程和资源。

对单线程运行时(例如 MRI 或 V8)而言,这很重要,因为只有一个线程可以工作。对那些像 JRuby 这样的多线程实现,异步​I/O 同样很有用,​但它也可以有多个并发工作线程来处理阻塞和非阻塞调用。​混用阻塞和非阻塞 I/O 提供了最大的灵活性,那些不支持异步的系统调用或库​也不会对此有什么妨碍。​

InfoQ:JRuby 好像同时提供两种方式​,因为它和 MRI 不同,JRuby 既有并行线程,又有​NIO。有没有什么非阻塞 I/O(或带有Java 7 中的 NIO 2的异步 I/O)​可以发挥的场景?​

在实现一个必须处理数以千计连接的服务器或客户端时,唯一的选择就是弄一个较小的工作线程池来处理大量异步 I/O 通道​。大多数用户都不会碰到这样的场景,但在你需要异步通道时,它是无可替代的。JRuby 的 I/O 子系统​直接构建于 NIO 之上,​这就有可能在线程之间复用可选 I/O 通道​。任何一个对高并发、高负载 I/O 感兴趣的 Ruby 用户都应该来看看 JRuby。​

InfoQ:对于 Ruby 2.0 最近的工作​你有什么看法,例如 Ruby Refinements?你有没有尝试一下,或者试着在 JRuby 中实现它们(我相信你实现了一个关于选择器命名空间的初期概念)?​

Refinements 是一个很有意思的特性,我们希望规范再“细化”​一点后就支持它。如果可以安全地为monkey-patch分配命名空间,这就可以解决 Ruby 世界里的一个常见问题。我们在 Refinements 的讨论中贡献了评论和原型实现,而且在规范制定阶段会继续做一些模拟的范例实现。​

InfoQ:看起来 Java 7 可能会在 2011 年的某个时间成为现实;​你有没有计划在未来的某个 JRuby 版本(1.7、2.0……)​中使用 Java 7 的特性?如果有的话,会先做哪个特性(除了 invokedynamic)?

我们计划为 Java 7 特性增加端到端的支持。​具体来说,我们会大量利用 invokedynamic 和方法处理,让 JVM 能更方便地优化 Ruby 代码。对于 NIO2 中的文件系统级特性,我们也感到很兴奋,例如其中对符号链接的支持​、文件系统事件以及其他一些以前只能通过我们的本地 POSIX 扩展才能拥有的底层功能。​在进行文件系统操作时,NIO2 可能意味着 JRuby​能更接近本地 Ruby 实现。它也让 JRuby 成为了在跨平台衔接文件系统事件方面最可靠的 Ruby 实现。我们同时计划继续支持 Java 5 和 Java 6​。

InfoQ:JRuby 1.6 中有哪些性能改进​,其中哪一个是你想放在下一个版本中的?​

最大的性能方面的工作涉及到减少 Ruby 调用的开销。​在 JRuby 1.5 和更早的版本​中,所有的 Ruby 调用都会​在调用时占据一个 thread-local 数据结构。那个数据用于生成回溯​(backtrace​)、处理“super”​调用、决定当前的“self”​和包含类​等等。JRuby 1.6 中,​在生成回溯时不再需要这个数据结构了,这意味着很多 Ruby​方法现在的人为调用开销接近于 0​。这让一些大派发量的性能测试结果提升了好几倍​。​

我们还开始了对未来的优化目标的实验工作​。上面提到的“回溯”​方面的工作还让一个名为“dynopt”​的特性成为可能,它可以在编译时使用 JRuby 解释器的信息​将动态调用转为直接的静态 Java 调用。JRuby 1.6 并不支持此特性,但你可以通过 -Xcompile.dynopt=true 开启它。在小型性能测试上,能产生巨大的性能差异。另一个实验工作与我们在优化的编译器有关。我们在构建​一个新的编译器和​中间表述,这样在我们生成 JVM 字节码前更容易做一些优化​。这允许我们用 JVM 可能还没​发现到的方式来预优化 Ruby 代码​。在未来的 JRuby 版本中,我们会继续在这两个特性上下功夫的​。​

查看英文原文:The State of JRuby: 1.6 RC1, JSR 292 and NIO2 in Java 7, 1.9.2 Support​

JavaRuby编程语言语言 & 开发架构