YARV和JIT，还有JRuby……

昨天承night_stalker老兄的 提醒，去google了一下 YARV，看看我是不是把事情记错了。记得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系列及之前的版本采用的运行方式是：
Ruby源代码 => 解析为AST（抽象语法树） => 直接在抽象语法树上解释执行

由Sasada Koichi先生所写的YARV进化为了Ruby 1.9.x的虚拟机，它的运行方式是：
Ruby源代码 => 解析为AST => 从AST生成YARV字节码 => 直接在YARV字节码上解释执行

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的运行过程：
Python源代码 => 解析为AST => 从AST生成Python字节码 => 直接在Python字节码上解释执行
跟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的实现函数：

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先生的话：

Sasada Koichi 写道

JIT Compilation
• I made easy one for x86, but…
• Too hard to do alone.  I retired.

和当时的图：

到RubyConf 2006的时候，AOT有进展了而JIT仍然没到位。

RubyConf 2008，Koichi先生第四次参加RubyConf……这次他没提到JIT的问题。还是得读代码去了解现状 =w=

（*）：或者它到位了而我没发现。求知道详情的讲解一下～～

=========================================================================

YARV自己是还没有JIT，不过这不能阻止其他人为YARV编写JIT后端。下面是相关的两个项目，yajit和yarv2llvm的一些链接：

Shinichiro Hamaji: yajit

Miura: yarv2llvm
Inside yarv2llvm(その1)
Inside yarv2llvm(その2)
Inside yarv2llvm(その3)
Inside yarv2llvm(その4)
Inside yarv2llvm(その5)
Inside yarv2llvm(その6)

=========================================================================

再看看JRuby。它的执行方式可以在启动JRuby虚拟机之前配置，例如说强制使用或禁用某些编译模式之类。
默认情况下，JRuby的运行方式是：
Ruby源代码 => 解析为AST => 在AST上解释执行（JRuby自己的解释器）
       ==> 某个CallSite的成功调用次数超过一定限制后（现在默认为是50次），将对应方法的AST即时编译为JVM字节码
       （由JVM执行字节码，有没有进一步的JIT取决于JVM）

JRuby也有预先编译的模式：
运行之前做预先编译（AOT，Ahead-of-Time compilation）：
Ruby源代码 => 解析为AST => 将AST编译为JVM字节码
运行时：
JVM字节码由JVM执行（有没有JIT取决于JVM）

那JRuby算不算有JIT呢？
值得注意的是，JRuby自身是运行在JVM之上的。如果它底下的JVM是有JIT的，那么它也就算有了半个JIT。在JRuby的JIT模式被激活了之后，Ruby方法就会被JRuby编译为JVM字节码，进而 有可能被JVM的JIT编译为本地机器指令。挺微妙的，呵呵。

至于JRuby的性能嘛，
Charles O. Nutter如是说： "Noise Cancelling" (2008-11-23)

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.

而根据 Antonio Cangiano在2008-12-09的测试结果： The Great Ruby Shootout (December 2008)

Antonio Cangiano 09 Dec 2008 at 9:51 am 写道

JRuby was the second best, Ruby 1.9.1 was fastest.

当然，那是去年年底的测试结果，使用的还是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里的 GIL限制显然会让它慢于支持真正多线程的JRuby；如果是需要高的交互性能，那么解释执行反而可能比 JIT更合适，等等。有很多外在因素使得各种microbenchmark与实际自己的应用侧重的性能需求有所不同，所以基本上大家在提到benchmarks的时候都会说“Benchmarks are just lies damn lies”（引用自 John Lam）

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也有两种运行模式，一种是预先编译的模式，另一种是解释模式；目前前者是默认模式。
预先编译模式：
Ruby源代码 => 解析为AST => 将AST转换为Expression Tree => 从Expression Tree生成MSIL => 由CLR执行（CLR会JIT）
解释模式：
Ruby源代码 => 解析为AST => 将AST转换为Expression Tree => 由DLR解释执行Expression Tree

所以IronRuby算不算有JIT呢？跟JRuby有相似之处。也是很微妙。不过目前IronRuby的解释模式不会触发Expression Tree => MSIL的编译过程，比JRuby的自适应性要弱一些。

更新：新的DLR解释器也开始有自适应编译了：先解释执行ETv2，一个“方法”被调用三次才触发ETv2 => MSIL的编译。请见这帖： http://www.iteye.com/topic/353790