YARV和JIT，还有JRuby……
酆茂才
昨天承night_stalker老兄的[url=http://www.iteye.com/problems/12381]提醒[/url]，去google了一下[url=http://www.atdot.net/yarv/]YARV[/url]，看看我是不是把事情记错了。记得Ruby还没1.9的时候我就稍微关注过YARV的信息，但印象中Ruby 1.9/YARV是没有JIT的……
Hmm，我貌似是没记错。目前的Ruby 1.9.1里并没有JIT。
首先需要定义我这里所指的JIT是什么。JIT，Just-In-Time Compiler，也就是所谓的即时编译器，其过程是JIT compilation，即时编译。
广义上说，只要有一个环境E直接支持某种语言B的运行，另外有一个程序是以语言A所编写的，在E上运行前没有单独的编译阶段，而是直接在运行前“即时”将A编译为B，这个即时编译的过程就可以称为JIT，无论A是高级语言也好字节码也好，B是别的字节码也好机器指令也好。
但实践中JIT一般是指将某种中间代码形式转换为机器指令的过程，及执行这个过程的编译器。例如说在x86上运行的Sun Hotspot JVM，其中的JIT会在一定条件下将JVM字节码编译为x86指令；或者说在x86上运行的微软CLR，其中的JIT会在执行某个托管方法之前先检查其是否已经被编译为x86指令，如果还没有的话就将其中的MSIL（CLR的字节码，也叫CIL）给JIT为x86指令，然后再执行那个方法。
Ruby（以下直接提到Ruby实现如无特别说明皆指CRuby，也就是官方版）在1.8系列及之前的版本采用的运行方式是：
[b][color=darkblue]Ruby源代码 => 解析为AST（抽象语法树） => 直接在抽象语法树上解释执行[/color][/b]
由Sasada Koichi先生所写的YARV进化为了Ruby 1.9.x的虚拟机，它的运行方式是：
[b][color=darkblue]Ruby源代码 => 解析为AST => 从AST生成YARV字节码 => 直接在YARV字节码上解释执行[/color][/b]
YARV后端的字节码解释器采用的是direct threaded code的解释方式，其特征是在每执行完一条指令之后直接对下一条指令解码，并直接跳转到下一条指令所对应的函数去；这样避免了使在一个大的中央循环内通过switch来做指令解码和分发，减少了CPU的分支预判的失败。在指令流水线较长的CPU上，这种技巧对提高执行速度很有好处。最经典的threaded code应该是各种Forth的实现，其中包括directed threaded code与indirected threaded code等不同的实现方式。
至少在Ruby 1.9.1上，YARV并没有将YARV字节码先JIT为本地机器指令后再执行。我认为这就可以称为“没有使用JIT”。
像是CPython的运行过程：
[b][color=darkblue]Python源代码 => 解析为AST => 从AST生成Python字节码 => 直接在Python字节码上解释执行[/color][/b]
跟YARV的看起来很像对吧？如果YARV算是使用了JIT，那CPython自然也算是使用了JIT了。照这个推广，用JIT的解释器可就多了。老的SpiderMonkey（Mozilla FireFox的JavaScript引擎）也是先将源码编译为它自己的字节码然后在字节码上解释执行的，KJS（KDE Konqueror的JavaScript引擎）也是类似，……嘛
对YARV的实现方式有兴趣的话可以留意Ruby 1.9的源码里vm开头的源文件。其中字节码解释器的主循环在vm_exec.c的vm_exec_core()函数里；每条指令对应的函数则在vm.inc里。让我们看看其中加号对应的YARV字节码opt_plus的实现函数：
[quote="vm.inc"]
离JIT还是有一段距离的，嗯。
原本的YARV规划里是有JIT的，但，现实是在Ruby 1.9.1里它还没到位（*）。引用RubyConf 2005上Koichi先生的话：
[quote="Sasada Koichi"]JIT Compilation
• I made easy one for x86, but…
• Too hard to do alone. I retired.[/quote]
和当时的图：
[img]http://rednaxelafx.iteye.com/upload/picture/pic/32643/a8df83e2-c911-3d18-aef6-a58412fbefe2.jpg[/img]
到RubyConf 2006的时候，AOT有进展了而JIT仍然没到位。
RubyConf 2008，Koichi先生第四次参加RubyConf……这次他没提到JIT的问题。还是得读代码去了解现状 =w=
[color=red]（*）：或者它到位了而我没发现。求知道详情的讲解一下～～[/color]
=========================================================================
YARV自己是还没有JIT，不过这不能阻止其他人为YARV编写JIT后端。下面是相关的两个项目，yajit和yarv2llvm的一些链接：
Shinichiro Hamaji: [url=http://d.hatena.ne.jp/shinichiro_h/20080525#1211708735]yajit[/url]
Miura: [url=http://github.com/miura1729/yarv2llvm/tree/master]yarv2llvm[/url]
[url=http://d.hatena.ne.jp/miura1729/20090123/1232707764]Inside yarv2llvm(その1)[/url]
[url=http://d.hatena.ne.jp/miura1729/20090123/1232718980]Inside yarv2llvm(その2)[/url]
[url=http://d.hatena.ne.jp/miura1729/20090124/1232800717]Inside yarv2llvm(その3)[/url]
[url=http://d.hatena.ne.jp/miura1729/20090126/1232978092]Inside yarv2llvm(その4)[/url]
[url=http://d.hatena.ne.jp/miura1729/20090130/1233297567]Inside yarv2llvm(その5)[/url]
[url=http://d.hatena.ne.jp/miura1729/20090202/1233575382]Inside yarv2llvm(その6)[/url]
=========================================================================
再看看JRuby。它的执行方式可以在启动JRuby虚拟机之前配置，例如说强制使用或禁用某些编译模式之类。
默认情况下，JRuby的运行方式是：
[b][color=darkblue]Ruby源代码 => 解析为AST => 在AST上解释执行（JRuby自己的解释器）
==> 某个CallSite的成功调用次数超过一定限制后（现在默认为是50次），将对应方法的AST即时编译为JVM字节码
（由JVM执行字节码，有没有进一步的JIT取决于JVM）[/color][/b]
JRuby也有预先编译的模式：
[b][color=darkblue]运行之前做预先编译（AOT，Ahead-of-Time compilation）：
Ruby源代码 => 解析为AST => 将AST编译为JVM字节码
运行时：
JVM字节码由JVM执行（有没有JIT取决于JVM）[/color][/b]
那JRuby算不算有JIT呢？
值得注意的是，JRuby自身是运行在JVM之上的。如果它底下的JVM是有JIT的，那么它也就算有了半个JIT。在JRuby的JIT模式被激活了之后，Ruby方法就会被JRuby编译为JVM字节码，进而[b]有可能[/b]被JVM的JIT编译为本地机器指令。挺微妙的，呵呵。
至于JRuby的性能嘛，
[url=http://blog.headius.com/]Charles O. Nutter[/url]如是说：[url=http://blog.headius.com/2008/11/noise-cancelling.html]"Noise Cancelling"[/url] (2008-11-23)
[quote="Charles O. Nutter"]A year ago, we were generally a bit slower than Ruby 1.8.6; this year, we're faster in most cases than Ruby 1.9.[/quote]
而根据[url=http://antoniocangiano.com/]Antonio Cangiano[/url]在2008-12-09的测试结果：[url=http://antoniocangiano.com/2008/12/09/the-great-ruby-shootout-december-2008/]The Great Ruby Shootout (December 2008)[/url]
[quote="Antonio Cangiano 09 Dec 2008 at 9:51 am"]JRuby was the second best, Ruby 1.9.1 was fastest.[/quote]
当然，那是去年年底的测试结果，使用的还是JRuby 1.1.6RC1 vs Ruby 1.9.1；它们其实算是不相上下，各有侧重。现在JRuby已经出到1.2.0RC1了，性能比起1.1.6又有了一定的提升；官方Ruby方面则暂时还没发布1.9.2系列的preview。谁更快其实不好说。
其实要说“谁更快”很关键的一点在于自己的应用的类型。如果是I/O-bound的类型，那无论VM速度如何可能对应用的性能都不会带来多少影响；如果是需要真的并行计算，那么在当前的Ruby 1.9.1里的[url=http://en.wikipedia.org/wiki/Global_Interpreter_Lock]GIL[/url]限制显然会让它慢于支持真正多线程的JRuby；如果是需要高的交互性能，那么解释执行反而可能比[url=http://en.wikipedia.org/wiki/Just-in-time_compilation]JIT[/url]更合适，等等。有很多外在因素使得各种microbenchmark与实际自己的应用侧重的性能需求有所不同，所以基本上大家在提到benchmarks的时候都会说“Benchmarks are just lies damn lies”（引用自[url=http://www.iunknown.com/]John Lam[/url]）
JRuby比较占优势的应该是长时间运行、多线程的应用场景。运行时间不够长的话JRuby主要是在解释模式运行的；只有当某个CallSite被调用了超过50次并且都是指向同一个目标时，JRuby才会考虑把目标方法编译为JVM字节码。在长时间、高强度的循环里这会带来一定的好处。
不过，不出意外的，JRuby的JIT对底下的Sun JVM的Hotspot JIT也会造成影响：Hotspot会根据它所看到的JVM字节码来决定是否做内联、peephole之类的优化；当执行路径发生改变时，Hotspot会发现它做的一些假设不成立了，于是要退回到解释JVM字节码的模式，重新对执行状况做分析。Charles提到过他们在对JRuby做benchmark的时候，发现有些benchmark在执行到50次之前都还好好的，反而在50次之后JRuby做了JIT使Hotspot退到了慢速路径上而且久久没能恢复过来。以后JRuby还有很多潜力可以挖掘，让它与Hotspot能更好的匹配。（然而专门对Hotspot做的优化对其它JVM或许又是个毒药……要留心）
=========================================================================
IronRuby是.NET上的Ruby实现，它运行在CLI之上；在微软平台上的话，CLI的实现就是CLR；在*-nix平台上则有Novell支持的Mono作为CLI的实现。Anyway，为了讨论的方便，就以CLR为具体例子来说明。
目前的IronRuby也有两种运行模式，一种是预先编译的模式，另一种是解释模式；目前前者是默认模式。
预先编译模式：
[b][color=darkblue]Ruby源代码 => 解析为AST => 将AST转换为Expression Tree => 从Expression Tree生成MSIL => 由CLR执行（CLR会JIT）[/color][/b]
解释模式：
[b][color=darkblue]Ruby源代码 => 解析为AST => 将AST转换为Expression Tree => 由DLR解释执行Expression Tree[/color][/b]
所以IronRuby算不算有JIT呢？跟JRuby有相似之处。也是很微妙。不过目前IronRuby的解释模式不会触发Expression Tree => MSIL的编译过程，比JRuby的自适应性要弱一些。
[color=red]更新：新的DLR解释器也开始有自适应编译了：先解释执行ETv2，一个“方法”被调用三次才触发ETv2 => MSIL的编译。请见这帖：[/color][url]http://www.iteye.com/topic/353790[/url]
Hmm，我貌似是没记错。目前的Ruby 1.9.1里并没有JIT。
首先需要定义我这里所指的JIT是什么。JIT，Just-In-Time Compiler，也就是所谓的即时编译器，其过程是JIT compilation，即时编译。
广义上说，只要有一个环境E直接支持某种语言B的运行，另外有一个程序是以语言A所编写的，在E上运行前没有单独的编译阶段，而是直接在运行前“即时”将A编译为B，这个即时编译的过程就可以称为JIT，无论A是高级语言也好字节码也好，B是别的字节码也好机器指令也好。
但实践中JIT一般是指将某种中间代码形式转换为机器指令的过程，及执行这个过程的编译器。例如说在x86上运行的Sun Hotspot JVM，其中的JIT会在一定条件下将JVM字节码编译为x86指令；或者说在x86上运行的微软CLR，其中的JIT会在执行某个托管方法之前先检查其是否已经被编译为x86指令，如果还没有的话就将其中的MSIL（CLR的字节码，也叫CIL）给JIT为x86指令，然后再执行那个方法。
Ruby（以下直接提到Ruby实现如无特别说明皆指CRuby，也就是官方版）在1.8系列及之前的版本采用的运行方式是：
[b][color=darkblue]Ruby源代码 => 解析为AST（抽象语法树） => 直接在抽象语法树上解释执行[/color][/b]
由Sasada Koichi先生所写的YARV进化为了Ruby 1.9.x的虚拟机，它的运行方式是：
[b][color=darkblue]Ruby源代码 => 解析为AST => 从AST生成YARV字节码 => 直接在YARV字节码上解释执行[/color][/b]
YARV后端的字节码解释器采用的是direct threaded code的解释方式，其特征是在每执行完一条指令之后直接对下一条指令解码，并直接跳转到下一条指令所对应的函数去；这样避免了使在一个大的中央循环内通过switch来做指令解码和分发，减少了CPU的分支预判的失败。在指令流水线较长的CPU上，这种技巧对提高执行速度很有好处。最经典的threaded code应该是各种Forth的实现，其中包括directed threaded code与indirected threaded code等不同的实现方式。
至少在Ruby 1.9.1上，YARV并没有将YARV字节码先JIT为本地机器指令后再执行。我认为这就可以称为“没有使用JIT”。
像是CPython的运行过程：
[b][color=darkblue]Python源代码 => 解析为AST => 从AST生成Python字节码 => 直接在Python字节码上解释执行[/color][/b]
跟YARV的看起来很像对吧？如果YARV算是使用了JIT，那CPython自然也算是使用了JIT了。照这个推广，用JIT的解释器可就多了。老的SpiderMonkey（Mozilla FireFox的JavaScript引擎）也是先将源码编译为它自己的字节码然后在字节码上解释执行的，KJS（KDE Konqueror的JavaScript引擎）也是类似，……嘛
对YARV的实现方式有兴趣的话可以留意Ruby 1.9的源码里vm开头的源文件。其中字节码解释器的主循环在vm_exec.c的vm_exec_core()函数里；每条指令对应的函数则在vm.inc里。让我们看看其中加号对应的YARV字节码opt_plus的实现函数：
[quote="vm.inc"]
INSN_ENTRY(opt_plus){
{
VALUE val;
VALUE recv = TOPN(1);
VALUE obj = TOPN(0);
DEBUG_ENTER_INSN("opt_plus");
ADD_PC(1+0);
PREFETCH(GET_PC());
POPN(2);
#define CURRENT_INSN_opt_plus 1
#define INSN_IS_SC() 0
#define INSN_LABEL(lab) LABEL_opt_plus_##lab
#define LABEL_IS_SC(lab) LABEL_##lab##_##t
USAGE_ANALYSIS_INSN(BIN(opt_plus));
{
#line 1287 "insns.def"
if (0) {
}
#if 1
else if (FIXNUM_2_P(recv, obj) &&
BASIC_OP_UNREDEFINED_P(BOP_PLUS)) {
/* fixnum + fixnum */
#ifndef LONG_LONG_VALUE
val = (recv + (obj & (~1)));
if ((~(recv ^ obj) & (recv ^ val)) &
((VALUE)0x01 << ((sizeof(VALUE) * CHAR_BIT) - 1))) {
val = rb_big_plus(rb_int2big(FIX2LONG(recv)),
rb_int2big(FIX2LONG(obj)));
}
#else
long a, b, c;
a = FIX2LONG(recv);
b = FIX2LONG(obj);
c = a + b;
if (FIXABLE(c)) {
val = LONG2FIX(c);
}
else {
val = rb_big_plus(rb_int2big(a), rb_int2big(b));
}
#endif
}
#endif
else if (!SPECIAL_CONST_P(recv) && !SPECIAL_CONST_P(obj)) {
if (0) {
}
#if 1
else if (HEAP_CLASS_OF(recv) == rb_cFloat &&
HEAP_CLASS_OF(obj) == rb_cFloat &&
BASIC_OP_UNREDEFINED_P(BOP_PLUS)) {
val = DBL2NUM(RFLOAT_VALUE(recv) + RFLOAT_VALUE(obj));
}
#endif
#if 1
else if (HEAP_CLASS_OF(recv) == rb_cString &&
HEAP_CLASS_OF(obj) == rb_cString &&
BASIC_OP_UNREDEFINED_P(BOP_PLUS)) {
val = rb_str_plus(recv, obj);
}
#endif
#if 1
else if (HEAP_CLASS_OF(recv) == rb_cArray &&
BASIC_OP_UNREDEFINED_P(BOP_PLUS)) {
val = rb_ary_plus(recv, obj);
}
#endif
else {
goto INSN_LABEL(normal_dispatch);
}
}
else {
INSN_LABEL(normal_dispatch):
PUSH(recv);
PUSH(obj);
CALL_SIMPLE_METHOD(1, idPLUS, recv);
}
#line 1901 "vm.inc"
PUSH(val);
#undef CURRENT_INSN_opt_plus
#undef INSN_IS_SC
#undef INSN_LABEL
#undef LABEL_IS_SC
END_INSN(opt_plus);}}}离JIT还是有一段距离的，嗯。
原本的YARV规划里是有JIT的，但，现实是在Ruby 1.9.1里它还没到位（*）。引用RubyConf 2005上Koichi先生的话：
[quote="Sasada Koichi"]JIT Compilation
• I made easy one for x86, but…
• Too hard to do alone. I retired.[/quote]
和当时的图：
[img]http://rednaxelafx.iteye.com/upload/picture/pic/32643/a8df83e2-c911-3d18-aef6-a58412fbefe2.jpg[/img]
到RubyConf 2006的时候，AOT有进展了而JIT仍然没到位。
RubyConf 2008，Koichi先生第四次参加RubyConf……这次他没提到JIT的问题。还是得读代码去了解现状 =w=
[color=red]（*）：或者它到位了而我没发现。求知道详情的讲解一下～～[/color]
=========================================================================
YARV自己是还没有JIT，不过这不能阻止其他人为YARV编写JIT后端。下面是相关的两个项目，yajit和yarv2llvm的一些链接：
Shinichiro Hamaji: [url=http://d.hatena.ne.jp/shinichiro_h/20080525#1211708735]yajit[/url]
Miura: [url=http://github.com/miura1729/yarv2llvm/tree/master]yarv2llvm[/url]
[url=http://d.hatena.ne.jp/miura1729/20090123/1232707764]Inside yarv2llvm(その1)[/url]
[url=http://d.hatena.ne.jp/miura1729/20090123/1232718980]Inside yarv2llvm(その2)[/url]
[url=http://d.hatena.ne.jp/miura1729/20090124/1232800717]Inside yarv2llvm(その3)[/url]
[url=http://d.hatena.ne.jp/miura1729/20090126/1232978092]Inside yarv2llvm(その4)[/url]
[url=http://d.hatena.ne.jp/miura1729/20090130/1233297567]Inside yarv2llvm(その5)[/url]
[url=http://d.hatena.ne.jp/miura1729/20090202/1233575382]Inside yarv2llvm(その6)[/url]
=========================================================================
再看看JRuby。它的执行方式可以在启动JRuby虚拟机之前配置，例如说强制使用或禁用某些编译模式之类。
默认情况下，JRuby的运行方式是：
[b][color=darkblue]Ruby源代码 => 解析为AST => 在AST上解释执行（JRuby自己的解释器）
==> 某个CallSite的成功调用次数超过一定限制后（现在默认为是50次），将对应方法的AST即时编译为JVM字节码
（由JVM执行字节码，有没有进一步的JIT取决于JVM）[/color][/b]
JRuby也有预先编译的模式：
[b][color=darkblue]运行之前做预先编译（AOT，Ahead-of-Time compilation）：
Ruby源代码 => 解析为AST => 将AST编译为JVM字节码
运行时：
JVM字节码由JVM执行（有没有JIT取决于JVM）[/color][/b]
那JRuby算不算有JIT呢？
值得注意的是，JRuby自身是运行在JVM之上的。如果它底下的JVM是有JIT的，那么它也就算有了半个JIT。在JRuby的JIT模式被激活了之后，Ruby方法就会被JRuby编译为JVM字节码，进而[b]有可能[/b]被JVM的JIT编译为本地机器指令。挺微妙的，呵呵。
至于JRuby的性能嘛，
[url=http://blog.headius.com/]Charles O. Nutter[/url]如是说：[url=http://blog.headius.com/2008/11/noise-cancelling.html]"Noise Cancelling"[/url] (2008-11-23)
[quote="Charles O. Nutter"]A year ago, we were generally a bit slower than Ruby 1.8.6; this year, we're faster in most cases than Ruby 1.9.[/quote]
而根据[url=http://antoniocangiano.com/]Antonio Cangiano[/url]在2008-12-09的测试结果：[url=http://antoniocangiano.com/2008/12/09/the-great-ruby-shootout-december-2008/]The Great Ruby Shootout (December 2008)[/url]
[quote="Antonio Cangiano 09 Dec 2008 at 9:51 am"]JRuby was the second best, Ruby 1.9.1 was fastest.[/quote]
当然，那是去年年底的测试结果，使用的还是JRuby 1.1.6RC1 vs Ruby 1.9.1；它们其实算是不相上下，各有侧重。现在JRuby已经出到1.2.0RC1了，性能比起1.1.6又有了一定的提升；官方Ruby方面则暂时还没发布1.9.2系列的preview。谁更快其实不好说。
其实要说“谁更快”很关键的一点在于自己的应用的类型。如果是I/O-bound的类型，那无论VM速度如何可能对应用的性能都不会带来多少影响；如果是需要真的并行计算，那么在当前的Ruby 1.9.1里的[url=http://en.wikipedia.org/wiki/Global_Interpreter_Lock]GIL[/url]限制显然会让它慢于支持真正多线程的JRuby；如果是需要高的交互性能，那么解释执行反而可能比[url=http://en.wikipedia.org/wiki/Just-in-time_compilation]JIT[/url]更合适，等等。有很多外在因素使得各种microbenchmark与实际自己的应用侧重的性能需求有所不同，所以基本上大家在提到benchmarks的时候都会说“Benchmarks are just lies damn lies”（引用自[url=http://www.iunknown.com/]John Lam[/url]）
JRuby比较占优势的应该是长时间运行、多线程的应用场景。运行时间不够长的话JRuby主要是在解释模式运行的；只有当某个CallSite被调用了超过50次并且都是指向同一个目标时，JRuby才会考虑把目标方法编译为JVM字节码。在长时间、高强度的循环里这会带来一定的好处。
不过，不出意外的，JRuby的JIT对底下的Sun JVM的Hotspot JIT也会造成影响：Hotspot会根据它所看到的JVM字节码来决定是否做内联、peephole之类的优化；当执行路径发生改变时，Hotspot会发现它做的一些假设不成立了，于是要退回到解释JVM字节码的模式，重新对执行状况做分析。Charles提到过他们在对JRuby做benchmark的时候，发现有些benchmark在执行到50次之前都还好好的，反而在50次之后JRuby做了JIT使Hotspot退到了慢速路径上而且久久没能恢复过来。以后JRuby还有很多潜力可以挖掘，让它与Hotspot能更好的匹配。（然而专门对Hotspot做的优化对其它JVM或许又是个毒药……要留心）
=========================================================================
IronRuby是.NET上的Ruby实现，它运行在CLI之上；在微软平台上的话，CLI的实现就是CLR；在*-nix平台上则有Novell支持的Mono作为CLI的实现。Anyway，为了讨论的方便，就以CLR为具体例子来说明。
目前的IronRuby也有两种运行模式，一种是预先编译的模式，另一种是解释模式；目前前者是默认模式。
预先编译模式：
[b][color=darkblue]Ruby源代码 => 解析为AST => 将AST转换为Expression Tree => 从Expression Tree生成MSIL => 由CLR执行（CLR会JIT）[/color][/b]
解释模式：
[b][color=darkblue]Ruby源代码 => 解析为AST => 将AST转换为Expression Tree => 由DLR解释执行Expression Tree[/color][/b]
所以IronRuby算不算有JIT呢？跟JRuby有相似之处。也是很微妙。不过目前IronRuby的解释模式不会触发Expression Tree => MSIL的编译过程，比JRuby的自适应性要弱一些。
[color=red]更新：新的DLR解释器也开始有自适应编译了：先解释执行ETv2，一个“方法”被调用三次才触发ETv2 => MSIL的编译。请见这帖：[/color][url]http://www.iteye.com/topic/353790[/url]
类似资料：