Oniguruma的Java移植版让JRuby提速

Ola Bini 报告说Oniguruma的移植版Joni已被合并入JRuby的代码主干：

\u0026#xD;\n

这是光辉的一天！Joni（Oniguruma正则表达式引擎的Java移植版，Marcin的出色成果）已经被合并入JRuby的代码主干。现在看起来工作得非常好。

\u0026#xD;\n

JRuby团队成员Marcin Mielczynski当初接下了将Oniguruma Regex引擎移植到Java代码的工作——Oniguruma是Ruby 1.9.x中包含的正则表达式引擎。

\u0026#xD;\n

总也说不完的JRuby与正则表达式（Regex）引擎之间的故事，这次总算画上了句号。早期的JRuby使用Java内建的Regex库（由Java 1.4引入）来实现Ruby正则表达式。虽然这是最简单的方案，不需要任何第三方库或者移植，但它也带来了一些问题，因此不适合JRuby。由于JRuby目标是成为与Ruby 1.8.x（及以后版本）兼容的实现，因此有必要支持同样的正则表达式。Java内建的实现被发现不兼容，部分是因为算法中的实现细节让它不能处理某些表达式。Ola解释了随后的步骤：

\u0026#xD;\n

为了解决这个问题，我们集成了JRegex作为替代。这是JRuby 1.0发布时带的引擎，现在用的也仍然是它。它工作得很好。对于一个用Java编写的引擎来说，它已经算快了，但还不够快。具体地说，它不支持对字符串的精确查找，不支持fail-fast，而且该引擎要求我们把byte[]字符串转换成char[]或者String。不尽理想。另一个问题是损害了与MRI的兼容性，特别是在多字节支持上。

\u0026#xD;\n

所有这些问题应该也将会被Joni解决掉。Regex性能过去是一个大问题（例子可见《在JRuby on Rails上构建Oracle Mix的收获》），Joni看起来对此也有帮助。Charles Nutter用新的代码来检验了REXML的性能：

\u0026#xD;\n

在经过一系列基本的优化后，我们先前担忧的大多数关键表达式的性能都至少和JRegex一样，甚至要好很多，于是Ola花了几天时间完成了转换。Marcin正继续在进行各种优化。我和Ola都已经试验过新的代码。看起来很不错。

\u0026#xD;\n

Nutter接着给出了合并代码前后的基准测试结果对比，数据显示出Joni代码带来了显著的速度提升。

\u0026#xD;\n

这个问题也暴露出了很多Ruby实现共同面对的一个麻烦。Rubinius是大部分用Ruby编写的一个Ruby实现，它可以直接采用最简单的方案——包含Oniguruma。但在VM（如JVM和.NET）上完成的Ruby实现，如果要包含一个原生库，会让部署变得更加困难（它们必须为各平台发行专门的版本）。除此之外，Marcin指出还存在其它集成问题：

\u0026#xD;\n

我们已经考虑过[包含Oniguruma]。有几个理由：
多线程：Oniguruma在初始化代码范围表或者管理共享的AST节点（如Character类散列表）时，使用全局锁。Oniguruma字节码解释器也使用线程锁（可以关闭该特性，但在Java中这项特性是自带的，而且混合异种线程和Java线程属于歪道）。
异常：很难从segfaults从恢复。把Oniguruma转换成Ruby异常也是一种丑陋的歪道。
JNI：JNI要求本地数据与VM数据分离，因此所有的字符串、字节都要进行复制。
额外的二进制分发包：希望你编译时不会遇到什么麻烦:D

查看英文原文： Oniguruma Java port speeds up JRuby