JägerMonkey与Carakan动态更新
孙元明
今天读了几篇与JavaScript引擎相关的帖。三篇关于Mozilla的新JavaScript JIT编译器——JägerMonkey的：
David Mandelin：
[url=http://blog.mozilla.com/dmandelin/2010/02/26/starting-jagermonkey/]Starting JägerMonkey[/url]
David Anderson：
[url=http://www.bailopan.net/blog/?p=683]JaegerMonkey – Fast JavaScript, Always![/url]
MozillaWiki：
[url=https://wiki.mozilla.org/JaegerMonkey]JaegerMonkey[/url]
从这几篇的描述来看，JägerMonkey是在SpiderMonkey的解释器上的改进，与TraceMonkey中的trace compiler相辅。
JägerMonkey采用的本地代码生成方式是inline-threading，是代码复制（code replication）的一种应用。这是将解释器进化为“JIT编译器”的一种快捷而有效的方式；与纯解释相比，inline-threading消除了指令分派的开销，但并不会比原本的解释器难实现多少，只是比原本要吃更多内存而已。
以方法为单位做最简单的代码复制，概念上就像是这样：
假设有一个直观的字节码解释器来执行它，实现类似
（随便造了一种字节码，凑合看吧）
while循环里就是一个[url=http://en.wikipedia.org/wiki/Instruction_cycle]FDX循环[/url]（Fetch-Decode-eXecute），每轮循环就是一个“指令周期”；里面的switch是decode/dispatch，每个case就是对于的execute。
然后假设有个要被解释执行的方法，其中的字节码指令是：
如果在这个解释器的基础上应用inline-threading，则上面的方法就会在被解释执行前先通过代码复制被展开为：
这样FDX循环就变成只剩X了，F与D都被“折叠”掉，与指令分派相关的开销自然就没了。展开的过程是一种抽象解释，就像是在实际解释之前把F与D执行并缓存下结果。
需求简单并且设计得当的话，PC也不需要自己维护了，相应开销也节省了下来。“需求简单”是指不需要让外界知道原解释器的状态；有时候会需要知道原PC的值，例如调试时，或者是原架构支持自我修改的代码时，不需要支持这些的话就简单很多。
每个被解释的方法都经过这种展开的话，需要占用的内存自然就比原本纯解释要多些。最基本的inline-threading只是单纯把每个字节码指令的处理程序复制了一份，而不对生成的代码做优化，所以生成出来的代码质量比做优化的编译器生成出来的差，冗余也比较多，“代码膨胀”比做了冗余削除的编译方法会严重些。
通过inline-threading，JägerMonkey就不再有解释器的“主循环”了；与TraceMonkey的trace compiler配合使用时，基准模式是inline-threading，热代码则被trace compiler编译为更快的、更特化的代码，比原本TraceMonkey在无法trace编译时要退回到纯解释要进了一步。可以说JägerMonkey的执行模式是从TraceMonkey的解释/编译混合模式进化为多层编译模式，启动开销会稍微增加，不过后面的执行速度会快不少。
[url=http://hg.mozilla.org/users/danderson_mozilla.com/jaegermonkey/]JägerMonkey的代码[/url]今晚连抓三次都异常退出了，真郁闷。今天跟Mozilla的连接那么糟糕么 T T
说到inline-threading，JVM里[url=http://www.cacaovm.org/]Cacao VM[/url]、[url=http://www.sablevm.org/]SableVM[/url]跟[url=http://sourceforge.net/projects/jamvm/]JamVM[/url]等也有采用这类实现方式。
然后还读了篇去年年底的Carakan消息更新。才发现我居然已经半年没更新过Carakan的消息，完全是奥特曼了。原来2月中Opera 10.50又出了新的beta，得找时间抓下来分析一下。
Roberto Mateu：
[url=http://labs.opera.com/news/2009/12/22/]Opera 10.5 pre-alpha for Labs[/url]
Jens Lindström：
[url=http://my.opera.com/core/blog/2009/12/22/carakan-revisited]Carakan Revisited[/url]
要是哪里有更详细的Carakan相关资料就好了。以前的一篇也只是不痛不痒的说了些优化方向而已，
Jens Lindström：
[url=http://my.opera.com/core/blog/2009/02/04/carakan]Carakan[/url]
基于寄存器的字节码指令集，本地代码生成，对象结构识别，编译代码缓存，按tab分离的GC堆（每个堆还是用基本的标记-清除式算法收集）。
既没有说明解释器具体使用的指令分派方式，也没有说寄存器分配器是用最近流行的线性扫描方式还是图着色方式还是什么别的。想拿它与开源的几种JavaScript引擎来比较实现方式颇困难，只能说感觉它的思路跟Nitro类似，但比Nitro的实现复杂。如果说它现在是最快的JavaScript引擎，那多半是以复杂为代价而获得的。V8则一直坚持“简单高效”的理念，感觉更轻便可靠些。
==================================================================
稍微更新：
抓到JägerMonkey代码后稍微看了下。在jaegermonkey/js/src/methodjit目录里的就是新增的JIT编译器。其中在Compiler.cpp，Compiler::Compile()方法里有个循环+switch，看上去就跟一个普通的switch-threading解释器的主循环一样。这就是前面我说JägerMonkey的实现是“从解释器进化为编译器很直观的方式”，同样有这种样子的主循环，只是解释器在循环中就直接把字节码执行掉了，而进化为编译器后在这个循环里做的是生成代码的工作——也就把指令分派开销一次过付清了。
目前（2010-03-04）JägerMonkey仍然采用基于栈的模型来生成代码，只是把很简单的操作直接通过MacroAssembler写成机器码；而稍微复杂一些的，例如JSOP_ADD就是通过stubCall调用到VM内的js::jsl_Add()去执行，感觉还是更像subroutine-threading……或许以后会有更多部分真正被inline？
David Mandelin：
[url=http://blog.mozilla.com/dmandelin/2010/02/26/starting-jagermonkey/]Starting JägerMonkey[/url]
David Anderson：
[url=http://www.bailopan.net/blog/?p=683]JaegerMonkey – Fast JavaScript, Always![/url]
MozillaWiki：
[url=https://wiki.mozilla.org/JaegerMonkey]JaegerMonkey[/url]
从这几篇的描述来看，JägerMonkey是在SpiderMonkey的解释器上的改进，与TraceMonkey中的trace compiler相辅。
JägerMonkey采用的本地代码生成方式是inline-threading，是代码复制（code replication）的一种应用。这是将解释器进化为“JIT编译器”的一种快捷而有效的方式；与纯解释相比，inline-threading消除了指令分派的开销，但并不会比原本的解释器难实现多少，只是比原本要吃更多内存而已。
以方法为单位做最简单的代码复制，概念上就像是这样：
假设有一个直观的字节码解释器来执行它，实现类似
// pc = program counter，字节码的程序计数器
// bytecode，字节码序列
// operand_stack，求值栈，或者叫操作数栈
// sp = stack pointer，求值栈指针
// ret_val = return value，返回值
// done，判断是否完成执行
while (!done) {
opcode = bytecode[pc++]; // 取下一条指令（fetch）
switch (opcode) { // switch方式的指令分派（decode/dispatch）
case PUSH_INT_0:
operand_stack[sp++] = 0;
break;
case PUSH_INT_1:
operand_stack[sp++] = 1;
break;
case ADD_INT:
operand2 = operand_stack[--sp]; // pop
operand1 = operand_stack[sp]; // peek
operand_stack[sp] = operand1 + operand2; // set_top
break;
case RETURN_INT:
ret_val = operand_stack[--sp]; // pop
done = true;
break;
// ...其它指令的处理程序
}
}
return ret_val;（随便造了一种字节码，凑合看吧）
while循环里就是一个[url=http://en.wikipedia.org/wiki/Instruction_cycle]FDX循环[/url]（Fetch-Decode-eXecute），每轮循环就是一个“指令周期”；里面的switch是decode/dispatch，每个case就是对于的execute。
然后假设有个要被解释执行的方法，其中的字节码指令是：
push_int_0
push_int_1
add_int
return_int如果在这个解释器的基础上应用inline-threading，则上面的方法就会在被解释执行前先通过代码复制被展开为：
operand_stack[sp++] = 0; // push constant 0
operand_stack[sp++] = 1; // push constant 1
operand2 = operand_stack[--sp]; // pop
operand1 = operand_stack[sp]; // peek
operand_stack[sp] = operand1 + operand2; // set_top
ret_val = operand_stack[--sp]; // set return value
return ret_val; // return这样FDX循环就变成只剩X了，F与D都被“折叠”掉，与指令分派相关的开销自然就没了。展开的过程是一种抽象解释，就像是在实际解释之前把F与D执行并缓存下结果。
需求简单并且设计得当的话，PC也不需要自己维护了，相应开销也节省了下来。“需求简单”是指不需要让外界知道原解释器的状态；有时候会需要知道原PC的值，例如调试时，或者是原架构支持自我修改的代码时，不需要支持这些的话就简单很多。
每个被解释的方法都经过这种展开的话，需要占用的内存自然就比原本纯解释要多些。最基本的inline-threading只是单纯把每个字节码指令的处理程序复制了一份，而不对生成的代码做优化，所以生成出来的代码质量比做优化的编译器生成出来的差，冗余也比较多，“代码膨胀”比做了冗余削除的编译方法会严重些。
通过inline-threading，JägerMonkey就不再有解释器的“主循环”了；与TraceMonkey的trace compiler配合使用时，基准模式是inline-threading，热代码则被trace compiler编译为更快的、更特化的代码，比原本TraceMonkey在无法trace编译时要退回到纯解释要进了一步。可以说JägerMonkey的执行模式是从TraceMonkey的解释/编译混合模式进化为多层编译模式，启动开销会稍微增加，不过后面的执行速度会快不少。
[url=http://hg.mozilla.org/users/danderson_mozilla.com/jaegermonkey/]JägerMonkey的代码[/url]今晚连抓三次都异常退出了，真郁闷。今天跟Mozilla的连接那么糟糕么 T T
说到inline-threading，JVM里[url=http://www.cacaovm.org/]Cacao VM[/url]、[url=http://www.sablevm.org/]SableVM[/url]跟[url=http://sourceforge.net/projects/jamvm/]JamVM[/url]等也有采用这类实现方式。
然后还读了篇去年年底的Carakan消息更新。才发现我居然已经半年没更新过Carakan的消息，完全是奥特曼了。原来2月中Opera 10.50又出了新的beta，得找时间抓下来分析一下。
Roberto Mateu：
[url=http://labs.opera.com/news/2009/12/22/]Opera 10.5 pre-alpha for Labs[/url]
Jens Lindström：
[url=http://my.opera.com/core/blog/2009/12/22/carakan-revisited]Carakan Revisited[/url]
要是哪里有更详细的Carakan相关资料就好了。以前的一篇也只是不痛不痒的说了些优化方向而已，
Jens Lindström：
[url=http://my.opera.com/core/blog/2009/02/04/carakan]Carakan[/url]
基于寄存器的字节码指令集，本地代码生成，对象结构识别，编译代码缓存，按tab分离的GC堆（每个堆还是用基本的标记-清除式算法收集）。
既没有说明解释器具体使用的指令分派方式，也没有说寄存器分配器是用最近流行的线性扫描方式还是图着色方式还是什么别的。想拿它与开源的几种JavaScript引擎来比较实现方式颇困难，只能说感觉它的思路跟Nitro类似，但比Nitro的实现复杂。如果说它现在是最快的JavaScript引擎，那多半是以复杂为代价而获得的。V8则一直坚持“简单高效”的理念，感觉更轻便可靠些。
==================================================================
稍微更新：
抓到JägerMonkey代码后稍微看了下。在jaegermonkey/js/src/methodjit目录里的就是新增的JIT编译器。其中在Compiler.cpp，Compiler::Compile()方法里有个循环+switch，看上去就跟一个普通的switch-threading解释器的主循环一样。这就是前面我说JägerMonkey的实现是“从解释器进化为编译器很直观的方式”，同样有这种样子的主循环，只是解释器在循环中就直接把字节码执行掉了，而进化为编译器后在这个循环里做的是生成代码的工作——也就把指令分派开销一次过付清了。
目前（2010-03-04）JägerMonkey仍然采用基于栈的模型来生成代码，只是把很简单的操作直接通过MacroAssembler写成机器码；而稍微复杂一些的，例如JSOP_ADD就是通过stubCall调用到VM内的js::jsl_Add()去执行，感觉还是更像subroutine-threading……或许以后会有更多部分真正被inline？
类似资料：