JRuby近况：1.5、AOT、Java 7

作者 Werner Schuster 译者 丁雪丰 发布于 2010年6月23日

领域

语言 & 开发

主题

JVM ,

JRuby ,

虚拟机 ,

运行时 ,

Ruby ,

Java ,

动态语言 ,

语言 ,

编程 ,

Ruby 1.9

分享到

JRuby 1.5发布了，InfoQ借此机会采访了JRuby团队的Charles Nutter，讨论了该版本中的一些大变化、JRuby在当前和以后的JVM上的未来等内容。

InfoQ JRuby 1.5中的AOT目前是什么状况？

我们一直都有提前编译器，用于以.class文件的形式来生成预编译的Ruby代码。但还有一些美中不足的地方：
* 那些预编译的文件会继续生成“invoker” ，生成的代码桩将绑定文件里所有的方法和块。这会在同步防止预编译脚本在禁止字节码生成的环境（例如Applet或Android）中工作时造成额外的类加载命中。
* 没有办法产生“真正的”Java类。生成的.class文件和.rb文件是1:1的，通过这个机制能在不生成大量输出的情况下预编译脚本。但在实践中，这还远远不够，人们需要的是根据Ruby代码生成真正的Java类。

1.5里已经通过下面几个额外的标志改正了这两个问题：
--java和--javac能根据给定文件中的Ruby类生成“真正的”Java类。你能用它们来编译Java代码、为它们添加注解、实现接口、反射其中的方法，像普通Java类一样构造它们。

--handles能在编译的时候生成所有运行时要生成的“invoker”句柄。这意味着你能“完全”预编译Ruby脚本，根本无需发生运行时代码生成。

我们还添加了一个--sha1标志，它能根据实际Ruby源代码的SHA1散列值命名生成的.class文件。使用了这种更标准的命名后，你能以任意目录布局发布.rb文件，.class文件则放在classpath的某处，JRuby会维护.rb和.class的关联。

InfoQ 发布说明中提到了'jruby.jit.codeCache'设置；这些类文件仅仅是在运行过程中被缓存，还是与AOT功能有所关联？

实际上，两者都有。如果你将codeCache=<dir>和-X+C结合使用，能在加载时强制编译所有文件，你将在运行过程中看到它正在保存所有被*确实*加载的文件。理想情况下你的应用程序在生产环境中运行时可以只用那些类文件，而不是预编译每个库中的每个文件（假设运行时会用到所有文件）。如果是在普通执行中使用codeCache，它只会保存那些足以JIT的经过编译的方法体。如果你想仅仅预编译你的应用程序，在使用jrubyc进行jar打包或codeCache时结合--sha1和--handles标志即可。
 
我们正打算整理一些文档和howto，我已经在博客中写了一点用--sha1和--handles预编译针对Android的Ruby应用程序的文章了。

InfoQ AOT有什么限制，例如，是否能够使用eval()、元编程等特性？

只要我们一起发布Ruby代码的解析器和解释器就可以使用eval。唯一的限制是能否在运行时JIT那段代码，在有些环境（例如Android上的Ruboto--JRuby）中这是不行的。我们还考虑构建一个简化版的JRuby运行时，它只包含运行预编译代码所需的部分；这样eval就不能用了……但这么做可能会很值，因为我们不用再发布解析器、解释器、AST类、编译器、ASM（用于字节码生成）和其他潜在内容。

如果你的元编程需要eval，那它也必须遵循相同的要求。但如果不用eval，那这段代码始终是能运行的。方法和块能被“完全”编译，因此可以在eval不可用时使用define_method等一系列方法。

InfoQ FFI和其他访问本地库的方法目前处在什么状况？

在JRuby 1.5中，我们从JNA（Java Native Access）切换到了JFFI（Java Foreign Function Interface）。我们的本地绑定专家Wayne Meissner在JNA上做了大量工作，他将这些知识带到了JFFI上，让它更快更高效。我们所有的本地库逻辑，包括通常不能运行在JVM上的POSIX函数（JRuby能使用符号链接、open UNIX Socket等等），现在都能通过JFFI了，而且我们针对所有流行平台和几个不太常见的平台（PPC-AIX! zLinux）发布了JFFI的本地支持。

InfoQ Wayne Meissner的JRuby Native Extension支持怎么样了？

Wayne为JRuby模拟了一个“Ruby C API”的早期原型，希望社区成员能帮助我们完成它，这样我们至少能运行一些人们写的本地扩展。但在这个层上的工作并非对所有人都有用，它对我们面对的其他bug和那些我们认为更重要的特性没什么帮助。
但是，也有些好消息：作为Ruby Summer of Code的一部分，JRuby在这个夏天会有一个专门的学生来帮助我们做一些C扩展支持的工作。我不确定我们是否能做到让*绝大多数*扩展跑起来，但我想我们可以提供一个安全子集，让*一些*扩展能够运行。我还想说明一下，只有那些实现了特定API（说明自己可“安全”实现的API），我们会进一步为C Ruby提供一些保护。

InfoQ 1.9支持现在是什么情况？

我们在这个版本中针对Ruby 1.9支持做了更多的工作，有一些用户在1.9模式下运行JRuby……但我们之前没有在这方面下太多功夫。这下有个好理由；去年晚些时候，Ruby 1.9.2的管理员Yuki Sonoda（yugui）打破了“圣诞节版本”的传统，宣布1.9.2需要更多的工作，它的发布会延期到2010年。他们正在接近完成1.9.2，这意味着我们很快会有一个能认真追赶的1.9“稳定”版了。我想JRuby 1.6会是个加入更“完整”1.9支持的版本。

InfoQ Java 7里的MLVM现在是什么情况，例如invoke_dynamic等等？

MLVM中最有趣也是比较成熟的组件——invokedynamic，在刚刚过去的一个秋季中经过了不少横向修改。例如，API得到了改善，Hotspot中的底层实现有了相当多的提升。我们一直在追踪这些变化，保持JRuby的invokedynamic支持与之同步。我们还观察到JRuby+invokedynamic比在Java 6上运行JRuby要稍微快一点；这让我们觉得这条路很有前途。

另一个有趣的东西是针对MLVM（也许最终是针对JVM本身）的协程支持工作。Lukas Stadler最近发表了一篇博客，他重做了JRuby的Ruby 1.9“纤程”支持（你知道的名字可能是协程、threadlet或协作计划微线程(cooperatively-scheduled microthread)），在Hotspot上使用他做的协程支持。其结果令人印象深刻；JRuby纤程加上Lukas做的东西运行起来比Ruby 1.9中的绿色线程实现更好，这让我们觉得有些不可思议。更好的是它不再需要使用本地线程，现在JRuby在标准JVM上就是这样模拟协程的。我不知道是否有机会将协程纳入真正的JVM版本中，但对那些需要协程或threadlet的语言来说这点很有帮助。

Lukas Stadler做的将协程支持带入JVM的相关工作。

InfoQ 关于1.6有什么大的计划吗？

我们有一些想法：
* 继续集成剩余的Java平台，为Rake添加Maven支持，为jrubyc --java添加扩展支持，还计划要支持很多之前在JRuby中使用困难或无法使用的基于类的框架。
* Ruby 1.9.2支持。我们已经做了很多工作，但还有更多事情需要去做。在这方面我们无疑需要一些社区的帮助。
* 为JRuby的性能翻开新的一页。比起标准Ruby实现，我们在这方面一直做得很好，但在一些特定的领域，像MacRuby和Rubinius这样的新实现很容易就超越我们了。一部分原因是运行于JVM之上的内在限制，例如需要100%封装的数字（这在数字算法方面给了我们很大的打击）。但大多数原因要归咎于从2008年年中开始我们就没有在JRuby的性能方面下太多功夫。我们知道有很多地方可以改善……它们只是有点棘手而已。

InfoQ JRuby团队正在写一本JRuby的书，是针对哪些目标读者的呢？

我们试图让这本书能同时被那些对使用JVM或Java库感兴趣的Ruby开发者和希望将一部分代码移到Ruby上（或一部分Web应用程序移到Rails上）的Java开发者所接受。我们已经定好了很多内容，很多入门到进阶级的内容，后续还会有更多的章节。

Charles最近发表了一篇博客，内容是关于在未来版本中提升JRuby性能的计划。

InfoQ EngineYard现在提供商业JRuby支持，有没有关于这方面的消息？

是的！EngineYard现正为那些对JRuby有所顾虑的组织中的JRuby用户提供支持和服务。你可以获得远程客户支持、专门的bug修复时间，甚至现场时间。我们希望这能帮助大客户更有信心地转向JRuby，并将其视为所有用户所享受的顶级OSS风格支持的完美补充（当然，如果时间允许的话）。

查看英文原文：The State of JRuby: 1.5, AOT, Java 7

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。