RednaxelaFX
- 浏览: 3016445 次
- 性别:
- 来自: 海外
-
文章分类
- 全部博客 (430)
- Programming Languages (23)
- Compiler (20)
- Virtual Machine (57)
- Garbage Collection (4)
- HotSpot VM (26)
- Mono (2)
- SSCLI Rotor (1)
- Harmony (0)
- DLR (19)
- Ruby (28)
- C# (38)
- F# (3)
- Haskell (0)
- Scheme (1)
- Regular Expression (5)
- Python (4)
- ECMAScript (2)
- JavaScript (18)
- ActionScript (7)
- Squirrel (2)
- C (6)
- C++ (10)
- D (2)
- .NET (13)
- Java (86)
- Scala (1)
- Groovy (3)
- Optimization (6)
- Data Structure and Algorithm (3)
- Books (4)
- WPF (1)
- Game Engines (7)
- 吉里吉里 (12)
- UML (1)
- Reverse Engineering (11)
- NSIS (4)
- Utilities (3)
- Design Patterns (1)
- Visual Studio (9)
- Windows 7 (3)
- x86 Assembler (1)
- Android (2)
- School Assignment / Test (6)
- Anti-virus (1)
- REST (1)
- Profiling (1)
- misc (39)
- NetOA (12)
- rant (6)
- anime (5)
- Links (12)
- CLR (7)
- GC (1)
- OpenJDK (2)
- JVM (4)
- KVM (0)
- Rhino (1)
- LINQ (2)
- JScript (0)
- Nashorn (0)
- Dalvik (1)
- DTrace (0)
- LLVM (0)
- MSIL (0)
最新评论
-
mldxs：
虽然很多还是看不懂，写的很好！
虚拟机随谈（一）：解释器，树遍历解释器，基于栈与基于寄存器，大杂烩 -
HanyuKing：
Java的多维数组 -
funnyone：
Java 8的default method与method resolution -
ljs_nogard：
Xamarin workbook - .Net Core 中不 ...
LINQ的恶搞…… -
txm119161336：
allocatestlye1 顺序为 // Fields o ...
最近做的两次Java/JVM分享的概要
昨天承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的实现函数：
离JIT还是有一段距离的，嗯。
原本的YARV规划里是有JIT的，但，现实是在Ruby 1.9.1里它还没到位（*）。引用RubyConf 2005上Koichi先生的话：
和当时的图：
到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)
而根据Antonio Cangiano在2008-12-09的测试结果：The Great Ruby Shootout (December 2008)
当然，那是去年年底的测试结果，使用的还是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
早期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已经有了纯解释模式，为了达到更好的性能平衡，以后发展出混合模式也是不奇怪的。
嗯我知道你那个是分布式的作业，之前在校内看到了。这方面在我的盲区内，没办法了（摊手
精华不精华不重要啦。倒是能召唤到些VM有爱人士就好了 T T
嗯肯定是说这个没错。
segfault可以是任何地方的Access violation，经常出问题的地方和显示出来的那块东西完全不搭界……
关键的一点是在1.9里面，RSRING(str)->ptr没有了（用StringValueCStr才对），在1.8下面编译的扩展必定会出问题。
不过Nokogiri的文档说它支持Ruby 1.9的嘛，所以我才试的。结果segfault让我一头雾水 T T
于是我知道了……呜哇，突然觉得有点不好意思了（奔
RPC的书在图书室里肯定有，去挖一下吧～说来我们是什么课提到RPC的来着，除了设计模式讲到代理的时候？莫非是大软……OTL
丫的，现在是分布式系统，嗯，设计模式的倒没有什么，细节太多了，我准备去图书馆看看。
你好好的一个精华帖被我变成水帖了，不好意思啊，哈哈～。
嗯肯定是说这个没错。
segfault可以是任何地方的Access violation，经常出问题的地方和显示出来的那块东西完全不搭界……
关键的一点是在1.9里面，RSRING(str)->ptr没有了（用StringValueCStr才对），在1.8下面编译的扩展必定会出问题。
不过Nokogiri的文档说它支持Ruby 1.9的嘛，所以我才试的。结果segfault让我一头雾水 T T
于是我知道了……呜哇，突然觉得有点不好意思了（奔
RPC的书在图书室里肯定有，去挖一下吧～说来我们是什么课提到RPC的来着，除了设计模式讲到代理的时候？莫非是大软……OTL
ID很眼熟但是我想不起来了，郁闷啊
最近我没怎么上MSN，印象中……如果我知道你是谁的话那我们肯定在MSN上聊过 OTL
呃……你在校内上不是说得火热嘛，这都不知道。
RPC原理我就没怎么看过。抱歉推荐不了什么书了。以前课上提到CORBA的时候稍微读过些零散的资料，都是放狗去找的……
唉，作业头疼啊
呃……你在校内上不是说得火热嘛，这都不知道。
RPC原理我就没怎么看过。抱歉推荐不了什么书了。以前课上提到CORBA的时候稍微读过些零散的资料，都是放狗去找的……
唉，作业头疼啊
segfault可以是任何地方的Access violation，经常出问题的地方和显示出来的那块东西完全不搭界……
关键的一点是在1.9里面，RSRING(str)->ptr没有了（用StringValueCStr才对），在1.8下面编译的扩展必定会出问题。
ID很眼熟但是我想不起来了，郁闷啊
最近我没怎么上MSN，印象中……如果我知道你是谁的话那我们肯定在MSN上聊过 OTL
RPC原理我就没怎么看过。抱歉推荐不了什么书了。以前课上提到CORBA的时候稍微读过些零散的资料，都是放狗去找的……
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.
• 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
分享到：
评论
25 楼
夜鸣猪
2009-03-11
专程学习，先留脚印
24 楼
RednaxelaFX
2009-03-09
yawl 写道
我觉得ironruby不会实现jruby的那种‘混合’模式，对它来说没有必要。
早期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已经有了纯解释模式，为了达到更好的性能平衡，以后发展出混合模式也是不奇怪的。
23 楼
night_stalker
2009-03-09
不知道萝卜ruby效果怎么样，召唤考据党
22 楼
yawl
2009-03-09
我觉得ironruby不会实现jruby的那种‘混合’模式，对它来说没有必要。
jruby那样做有历史原因。因为最早的jruby,在charles nutter和tom之前，解释器已经做了，基本上是从c代码port到java的。后来不断积累完善，大多ruby代码能在下面跑的好好的了。
jruby的编译是比较后加入的，其实直到现在也不能完整的把ruby代码全部编译执行。所以charles一直用了个简单的办法--先'试图'编译一下，不行的话解释AST的老办法。这个实际效果其实很不错，用户的代码仍然跑得好好的（因为最差情况也就是继续解释AST的老办法），也能感受编译的好处。
ironruby是从头开始的，没有必要去花很大力气去做一个ruby 1.8那种的落后的解释器。
jruby那样做有历史原因。因为最早的jruby,在charles nutter和tom之前，解释器已经做了，基本上是从c代码port到java的。后来不断积累完善，大多ruby代码能在下面跑的好好的了。
jruby的编译是比较后加入的，其实直到现在也不能完整的把ruby代码全部编译执行。所以charles一直用了个简单的办法--先'试图'编译一下，不行的话解释AST的老办法。这个实际效果其实很不错，用户的代码仍然跑得好好的（因为最差情况也就是继续解释AST的老办法），也能感受编译的好处。
ironruby是从头开始的，没有必要去花很大力气去做一个ruby 1.8那种的落后的解释器。
21 楼
tetsu.soh
2009-03-09
好文章。
回答我关于Ruby和JIT问题的就是你啊～，没想到下来又做了这么多功课，佩服佩服。
看你的Blog里，有日文Site的引用，难道还精通日文？！好厉害的说。
我也是个学生，在语言实现方面还是新米。很多东西都不懂，目前正在补功课。以后有机会多多交流啊～
回答我关于Ruby和JIT问题的就是你啊～，没想到下来又做了这么多功课，佩服佩服。
看你的Blog里，有日文Site的引用，难道还精通日文？！好厉害的说。
我也是个学生，在语言实现方面还是新米。很多东西都不懂，目前正在补功课。以后有机会多多交流啊～
20 楼
RednaxelaFX
2009-03-09
呵呵，嗯。确实许多问题都是这样，概念本身的定义太困难，或者说对概念的了解还不够透彻使得定义很暧昧。所以使用概念前都需要在语境下做一次明确的定义来解决当前语境下的概念分歧。
跟JIT相关，另外一个概念也是经常被弄得很混乱的：虚拟机。如果说Hotspot和VMWare都是虚拟机，它们却又很明显不一样。于是出现了高级语言虚拟机、应用虚拟机、系统虚拟机等概念。然后像是虚拟机的执行方式，有二进制翻译和二进制解释两种；而Hotspot等带有JIT的虚拟机却模糊了这个界线。
跟JIT相关，另外一个概念也是经常被弄得很混乱的：虚拟机。如果说Hotspot和VMWare都是虚拟机，它们却又很明显不一样。于是出现了高级语言虚拟机、应用虚拟机、系统虚拟机等概念。然后像是虚拟机的执行方式，有二进制翻译和二进制解释两种；而Hotspot等带有JIT的虚拟机却模糊了这个界线。
19 楼
night_stalker
2009-03-09
还是维特根斯坦他老人家说得好：
问题无解，原因往往就是问题定义有问题，或者人类智能无法理解此概念。(大意..)
JIT就是个暧昧的概念，"Ruby是不是JIT了"就是个有问题的问题。
问题无解，原因往往就是问题定义有问题，或者人类智能无法理解此概念。(大意..)
JIT就是个暧昧的概念，"Ruby是不是JIT了"就是个有问题的问题。
18 楼
RednaxelaFX
2009-03-09
没错，Charles Nutter说的“JRuby的JIT”指的是JRuby将Ruby源码编译到JVM字节码的过程，与我所说的JIT不相符。但同时JVM字节码是有机会被JVM所JIT的。所以在JRuby做了JIT、JVM也做了JIT之后，整个过程就符合我所说的JIT了。所以说很微妙。
IronRuby方面比JRuby……或许没那么微妙。现在的IronRuby如果是在默认模式，会一口气把Ruby源码都解析为Expression Tree。然后DLR会将Expression Tree编译为MSIL。接着CLR会将MSIL给JIT成本地机器指令。整个过程没任何可选部分，整体上看就等同于把Ruby源码JIT到了本地机器指令才执行。
IronRuby的以后肯定也会实现混合模式的运行方式，虽然现在还没有。DLR有默认的解释模式，这种模式下Expression Tree只用于解释而不编译到MSIL。相对来说自适应性就没了。
JRuby默认用的是混合模式的运行方式，在刚启动时采用纯解释模式，在达到一些条件之后对部分热点做“JRuby的JIT”。之所以是“部分热点”是因为多了会塞爆PermGen；JRuby得对每个“JIT”出来的类用单独的class loader来加载，以保证在达到内存使用上限时能卸载掉一些老的“JIT”出来的类。
JRuby对Ruby核心库是有特别实现的：核心库的功能是用Java实现的，运行时创建许多小的包装类来实现快速调用，这样可以用相对具体的signature来从Ruby调用底下的Java方法。用比较具体的signature可以减少通用signature中varargs数组的包装，减轻GC的负担。对一般的Java库，JRuby还是用普通的反射来做调用的。
JRuby巨占资源这点恐怕比较难改善。以后invokedynamic正式合并到JVM spec里的话可以减少对包装类的需求，那样是可以减少一些资源占用。不过JVM本身就不是省油的灯就是了，呃呵呵。
不知道Sun的Kenai后面是用怎样的机器撑着的呢？有人有了解么？用JRuby on Rails来做hosting还真是一强悍的广告……
IronRuby方面比JRuby……或许没那么微妙。现在的IronRuby如果是在默认模式，会一口气把Ruby源码都解析为Expression Tree。然后DLR会将Expression Tree编译为MSIL。接着CLR会将MSIL给JIT成本地机器指令。整个过程没任何可选部分，整体上看就等同于把Ruby源码JIT到了本地机器指令才执行。
IronRuby的以后肯定也会实现混合模式的运行方式，虽然现在还没有。DLR有默认的解释模式，这种模式下Expression Tree只用于解释而不编译到MSIL。相对来说自适应性就没了。
JRuby默认用的是混合模式的运行方式，在刚启动时采用纯解释模式，在达到一些条件之后对部分热点做“JRuby的JIT”。之所以是“部分热点”是因为多了会塞爆PermGen；JRuby得对每个“JIT”出来的类用单独的class loader来加载，以保证在达到内存使用上限时能卸载掉一些老的“JIT”出来的类。
JRuby对Ruby核心库是有特别实现的：核心库的功能是用Java实现的，运行时创建许多小的包装类来实现快速调用，这样可以用相对具体的signature来从Ruby调用底下的Java方法。用比较具体的signature可以减少通用signature中varargs数组的包装，减轻GC的负担。对一般的Java库，JRuby还是用普通的反射来做调用的。
JRuby巨占资源这点恐怕比较难改善。以后invokedynamic正式合并到JVM spec里的话可以减少对包装类的需求，那样是可以减少一些资源占用。不过JVM本身就不是省油的灯就是了，呃呵呵。
不知道Sun的Kenai后面是用怎样的机器撑着的呢？有人有了解么？用JRuby on Rails来做hosting还真是一强悍的广告……
17 楼
yawl
2009-03-09
这个看你怎么抠概念了。
比如charles nutter一直说的jruby的'JIT',就完全不符合你说的JIT概念。jruby是混合模式，有些代码是自己直接解释AST,有些是编译成java字节码交给jvm。他所指的jit其实就是运行时编译的部分。
ruby的1.8及之前的实现，确实很业余。这点matz也承认。同样做个loop的话，ruby比其他语言慢几十上百倍。1.9改进了解释器的实现。在benchmark上轻松的上了个大台阶。
但是诸如rails这样的应用，loop快上几十倍就没大关系了，也就是几毫秒和几十毫秒的区别。同时，你的页面里也许有几个sql query,瓶颈大多在其他方面上了。我猜这是rails在1.9上目前没有大的提高的原因吧。
我也试过在jruby上跑过rails程序，和robbin说的一样，挺慢的，而且巨占资源。
比如charles nutter一直说的jruby的'JIT',就完全不符合你说的JIT概念。jruby是混合模式，有些代码是自己直接解释AST,有些是编译成java字节码交给jvm。他所指的jit其实就是运行时编译的部分。
ruby的1.8及之前的实现，确实很业余。这点matz也承认。同样做个loop的话，ruby比其他语言慢几十上百倍。1.9改进了解释器的实现。在benchmark上轻松的上了个大台阶。
但是诸如rails这样的应用，loop快上几十倍就没大关系了，也就是几毫秒和几十毫秒的区别。同时，你的页面里也许有几个sql query,瓶颈大多在其他方面上了。我猜这是rails在1.9上目前没有大的提高的原因吧。
我也试过在jruby上跑过rails程序，和robbin说的一样，挺慢的，而且巨占资源。
16 楼
night_stalker
2009-03-07
有快有慢，视情况而定。
ruby酱网站给过一系列的benchmark，总体来说是快了的。
当然benchmark不可信，但是一两个脚本的特例就更不可信了。
ruby酱网站给过一系列的benchmark，总体来说是快了的。
当然benchmark不可信，但是一两个脚本的特例就更不可信了。
15 楼
七猫
2009-03-07
>g:\ruby187\bin\ruby dzhreader.rb
>Exit code: 0 Time: 19.469
这是我编译的1.87(vc2008)
1.9运行结果：45秒(vc2008)
>ruby dzhreader.rb
>Exit code: 0 Time: 26.467
官方自带
vc2008加上一些优化选项的确能使性能有所提高，但1.9的速度感到很困惑。
>Exit code: 0 Time: 19.469
这是我编译的1.87(vc2008)
1.9运行结果：45秒(vc2008)
>ruby dzhreader.rb
>Exit code: 0 Time: 26.467
官方自带
vc2008加上一些优化选项的确能使性能有所提高，但1.9的速度感到很困惑。
14 楼
七猫
2009-03-07
我用2008优化编译的1.9在跑某个脚本需要的时间是1.87的两倍，没仔细去找原因了。
13 楼
RednaxelaFX
2009-03-07
seraphim871211 写道
丫的，现在是分布式系统，嗯，设计模式的倒没有什么，细节太多了，我准备去图书馆看看。
你好好的一个精华帖被我变成水帖了，不好意思啊，哈哈～。
你好好的一个精华帖被我变成水帖了，不好意思啊，哈哈～。
嗯我知道你那个是分布式的作业，之前在校内看到了。这方面在我的盲区内，没办法了（摊手
精华不精华不重要啦。倒是能召唤到些VM有爱人士就好了 T T
12 楼
seraphim871211
2009-03-06
RednaxelaFX 写道
ray_linn 写道
RPC? 远程方法调用？ Remote Procedure Call?
嗯肯定是说这个没错。
night_stalker 写道
RednaxelaFX 写道
...还有Ruby 1.9的兼容性问题。天啊，在Ruby 1.9.1上用不了Mechanize/Nokogiri真是太要命了。
...
...
segfault可以是任何地方的Access violation，经常出问题的地方和显示出来的那块东西完全不搭界……
关键的一点是在1.9里面，RSRING(str)->ptr没有了（用StringValueCStr才对），在1.8下面编译的扩展必定会出问题。
不过Nokogiri的文档说它支持Ruby 1.9的嘛，所以我才试的。结果segfault让我一头雾水 T T
seraphim871211 写道
呃……你在校内上不是说得火热嘛，这都不知道。
于是我知道了……呜哇，突然觉得有点不好意思了（奔
RPC的书在图书室里肯定有，去挖一下吧～说来我们是什么课提到RPC的来着，除了设计模式讲到代理的时候？莫非是大软……OTL
丫的，现在是分布式系统，嗯，设计模式的倒没有什么，细节太多了，我准备去图书馆看看。
你好好的一个精华帖被我变成水帖了，不好意思啊，哈哈～。
11 楼
RednaxelaFX
2009-03-06
ray_linn 写道
RPC? 远程方法调用？ Remote Procedure Call?
嗯肯定是说这个没错。
night_stalker 写道
RednaxelaFX 写道
...还有Ruby 1.9的兼容性问题。天啊，在Ruby 1.9.1上用不了Mechanize/Nokogiri真是太要命了。
...
...
segfault可以是任何地方的Access violation，经常出问题的地方和显示出来的那块东西完全不搭界……
关键的一点是在1.9里面，RSRING(str)->ptr没有了（用StringValueCStr才对），在1.8下面编译的扩展必定会出问题。
不过Nokogiri的文档说它支持Ruby 1.9的嘛，所以我才试的。结果segfault让我一头雾水 T T
seraphim871211 写道
呃……你在校内上不是说得火热嘛，这都不知道。
于是我知道了……呜哇，突然觉得有点不好意思了（奔
RPC的书在图书室里肯定有，去挖一下吧～说来我们是什么课提到RPC的来着，除了设计模式讲到代理的时候？莫非是大软……OTL
10 楼
seraphim871211
2009-03-06
seraphim871211 写道
RednaxelaFX 写道
seraphim871211 写道
没呢，我只是随便说说，你还知道我是谁啊。
ID很眼熟但是我想不起来了，郁闷啊
最近我没怎么上MSN，印象中……如果我知道你是谁的话那我们肯定在MSN上聊过 OTL
呃……你在校内上不是说得火热嘛，这都不知道。
引用
seraphim871211 写道
最近我要看RPC/RMI原理方面的东西，要自己实现个简单的“玩具”RPC，有好书推荐吗？最好语言是用java，C#的也行。
RPC原理我就没怎么看过。抱歉推荐不了什么书了。以前课上提到CORBA的时候稍微读过些零散的资料，都是放狗去找的……
唉，作业头疼啊
9 楼
seraphim871211
2009-03-06
RednaxelaFX 写道
seraphim871211 写道
没呢，我只是随便说说，你还知道我是谁啊。
ID很眼熟但是我想不起来了，郁闷啊
最近我没怎么上MSN，印象中……如果我知道你是谁的话那我们肯定在MSN上聊过 OTL
ID很眼熟但是我想不起来了，郁闷啊
最近我没怎么上MSN，印象中……如果我知道你是谁的话那我们肯定在MSN上聊过 OTL
呃……你在校内上不是说得火热嘛，这都不知道。
seraphim871211 写道
最近我要看RPC/RMI原理方面的东西，要自己实现个简单的“玩具”RPC，有好书推荐吗？最好语言是用java，C#的也行。
RPC原理我就没怎么看过。抱歉推荐不了什么书了。以前课上提到CORBA的时候稍微读过些零散的资料，都是放狗去找的……
唉，作业头疼啊
8 楼
night_stalker
2009-03-06
RednaxelaFX 写道
...还有Ruby 1.9的兼容性问题。天啊，在Ruby 1.9.1上用不了Mechanize/Nokogiri真是太要命了。
...
...
segfault可以是任何地方的Access violation，经常出问题的地方和显示出来的那块东西完全不搭界……
关键的一点是在1.9里面，RSRING(str)->ptr没有了（用StringValueCStr才对），在1.8下面编译的扩展必定会出问题。
7 楼
ray_linn
2009-03-06
RPC? 远程方法调用？ Remote Procedure Call?
6 楼
RednaxelaFX
2009-03-06
seraphim871211 写道
没呢，我只是随便说说，你还知道我是谁啊。
ID很眼熟但是我想不起来了，郁闷啊
最近我没怎么上MSN，印象中……如果我知道你是谁的话那我们肯定在MSN上聊过 OTL
seraphim871211 写道
最近我要看RPC/RMI原理方面的东西，要自己实现个简单的“玩具”RPC，有好书推荐吗？最好语言是用java，C#的也行。
RPC原理我就没怎么看过。抱歉推荐不了什么书了。以前课上提到CORBA的时候稍微读过些零散的资料，都是放狗去找的……
发表评论
-
The Prehistory of Java, HotSpot and Train
2014-06-02 08:18 0http://cs.gmu.edu/cne/itcore/vi ... -
MSJVM and Sun 1.0.x/1.1.x
2014-05-20 18:50 0当年的survey paper: http://www.sym ... -
Sun JDK1.4.2_28有TieredCompilation
2014-05-12 08:48 0原来以前Sun的JDK 1.4.2 update 28就已经有 ... -
IBM JVM notes (2014 ver)
2014-05-11 07:16 0Sovereign JIT http://publib.bou ... -
class data sharing by Apple
2014-03-28 05:17 0class data sharing is implement ... -
HotSpot Server VM与Server Class Machine
2014-02-18 13:21 0HotSpot VM历来有Client VM与Server V ... -
Java 8的lambda表达式在OpenJDK8中的实现
2014-02-04 12:08 0三月份JDK8就要发布首发了，现在JDK8 release c ... -
GC stack map与deopt stack map的异同
2014-01-08 09:56 0两者之间不并存在包含关系。它们有交集，但也各自有特别的地方。 ... -
HotSpot Server Compiler与data-flow analysis
2014-01-07 17:41 0http://en.wikipedia.org/wiki/Da ... -
基于LLVM实现VM的JIT的一些痛点
2014-01-07 17:25 0同事Philip Reames Sanjoy Das http ... -
tailcall notes
2013-12-27 07:42 0http://blogs.msdn.com/b/clrcode ... -
《自制编程语言》的一些笔记
2013-11-24 00:20 0http://kmaebashi.com/programmer ... -
字符串的一般封装方式的内存布局 (1): 元数据与字符串内容，整体还是分离？
2013-11-07 17:44 22258（Disclaimer：未经许可请 ... -
字符串的一般封装方式的内存布局 (0): 拿在手上的是什么
2013-11-04 18:22 21372（Disclaimer：未经许可请 ... -
字符串的一般封装方式的内存布局
2013-11-01 12:55 0（Disclaimer：未经许可请 ... -
关于string，内存布局，C++ std::string，CoW
2013-10-30 20:45 0（Disclaimer：未经许可请 ... -
Java的instanceof是如何实现的
2013-09-22 16:57 0Java语言规范，Java SE 7版 http://docs ... -
也谈类型: 数据, 类型, 标签
2013-08-18 01:59 0numeric tower http://en.wikiped ... -
oop、klass、handle的关系
2013-07-30 17:34 0oopDesc及其子类的实例 oop : oopDesc* ... -
Nashorn各种笔记
2013-07-15 17:03 0http://bits.netbeans.org/netbea ...
相关推荐
ZetaVM一个用于动态编程语言的虚拟机和JIT编译器
IBM的一份对Method JIT和Trace JIT说明的文档。
jit数据库题库jit数据库题库jit数据库题库jit数据库题库jit数据库题库jit数据库题库
jit JavaScript jit JavaScript jit JavaScript jit JavaScript
jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识及JIT优化jvm初识...
jit spray source code
jit计算机系统基础1jit计算机系统基础1jit计算机系统基础1jit计算机系统基础1jit计算机系统基础1jit计算机系统基础1jit计算机系统基础1jit计算机系统基础1jit计算机系统基础1jit计算机系统基础1jit计算机系统基础1...
有两种方式产生本机的机器代码：实时编译和预编译方式。CLR使用类型的方法表来路由所有的方法调用。类型的方法表由多个入口项组成。每个入口项指向一个唯一的存根例程。初始化时，每个存根例程包含一个对于CLR的JIT...
JIT是JUST IN TIME的意思，是精益生产的管理思想理论，借助JIT企业可以有效减少浪费，降低生产成本、提高产能、产品质量等。
JIT生产方式简介
——学习参考资料：仅用于个人学习使用！ 本代码仅作学习交流，切勿用于商业用途，否则后果自负。若涉及侵权，请联系，会尽快处理! 未进行详尽测试，请自行调试!
VMI-JITVMI-JITVMI-JITVMI-JITVMI-JIT
精益生产之JIT实务精益生产之JIT实务精益生产之JIT实务精益生产之JIT实务
JIT在供应链管理中的应用探析，李永祥，，JIT（Just-in-time，准时生产制）是针对企业内部的一种生产管理模式，其主旨是发现和消除浪费从而降低运营成本。通过发现企业内部潜在
Known as the JIT bible in Japan, JIT Implementation Manual ? The Complete Guide to Just-in-Time Manufacturing presents the genius of Hiroyuki Hirano, a top international consultant with vast ...
JIT—08 精益生产工具——生产线平衡分析和瓶颈改善.doc
JIT Spray技术.pdf ！！！！！！！！！！！！！！！！！
JIT看板生产系统WITNESS仿真建模和优化实现.pdf
HipHop PHP：Facebook出品的PHP虚拟机，运行时和JIT
Android 系统的深入介绍 PPT中详细介绍了Dalvik VM 的工作原理，Dalvik JIT的工作原理，以及android 一些framework的大致结构。 公司内部做过一次培训，感觉还不错，共享出来，希望有所帮助