YARV和JIT，还有JRuby……

呵呵，嗯。确实许多问题都是这样，概念本身的定义太困难，或者说对概念的了解还不够透彻使得定义很暧昧。所以使用概念前都需要在语境下做一次明确的定义来解决当前语境下的概念分歧。
跟JIT相关，另外一个概念也是经常被弄得很混乱的：虚拟机。如果说Hotspot和VMWare都是虚拟机，它们却又很明显不一样。于是出现了高级语言虚拟机、应用虚拟机、系统虚拟机等概念。然后像是虚拟机的执行方式，有二进制翻译和二进制解释两种；而Hotspot等带有JIT的虚拟机却模糊了这个界线。

好文章。
回答我关于Ruby和JIT问题的就是你啊～，没想到下来又做了这么多功课，佩服佩服。

看你的Blog里，有日文Site的引用，难道还精通日文？！好厉害的说。

我也是个学生，在语言实现方面还是新米。很多东西都不懂，目前正在补功课。以后有机会多多交流啊～

我觉得ironruby不会实现jruby的那种‘混合’模式，对它来说没有必要。

jruby那样做有历史原因。因为最早的jruby,在charles nutter和tom之前，解释器已经做了，基本上是从c代码port到java的。后来不断积累完善，大多ruby代码能在下面跑的好好的了。

jruby的编译是比较后加入的，其实直到现在也不能完整的把ruby代码全部编译执行。所以charles一直用了个简单的办法--先'试图'编译一下，不行的话解释AST的老办法。这个实际效果其实很不错，用户的代码仍然跑得好好的（因为最差情况也就是继续解释AST的老办法），也能感受编译的好处。

ironruby是从头开始的，没有必要去花很大力气去做一个ruby 1.8那种的落后的解释器。

不知道萝卜ruby效果怎么样，召唤考据党

早期DLR的实现里就没有解释器，上层的语言实现将源码转换到DLR tree（现在与LINQ合并就叫做Expression Tree了）之后，DLR里的编译器就将DLR tree以LCG的方式编译为MSIL，得到LCG委托后去调用那个委托。
但是IronPython和IronRuby的实际表现使他们不得不考虑重新加入解释模式。去年下半年开始，DLR里就有一个通用的、功能简单的Expression Tree解释器了。上层的语言实现要用DLR的解释器基本上不用做多少修改，只要传入一个flag表明要解释执行即可。不过这个通用的解释器对语言特定的功能的支持可能不是最优的，所以如果要获得更高的解释性能，DLR允许语言实现自己插入解释器的实现。
John Lam在一些会议上也提到过IronRuby的发展过程与其它Ruby实现有所不同，就是IronRuby是先有编译模式再有解释模式。他提到在没有解释模式之前，IronRuby的启动速度慢得难以接受，而且在debug和交互式环境下编译的代价不值得，所以后来还是走回了解释的路上。

既然DLR已经有了纯解释模式，为了达到更好的性能平衡，以后发展出混合模式也是不奇怪的。