之前一直在研究执行代码之类的问题,现在正好有机会和大家讨论一下.
这一篇重要说明解释器的基本工作过程和JSC的核心组件的实现。
作为一个语言，就像人在的平常交流时一样，当接收到信息后，包括两个过程：先懂得再行为。懂得的过程就是语言解析的过程，行为就是根据解析的结果执行对应的行为。在计算机范畴，懂得就是编译或解释，这个已被研究的很透彻了，并且有了工具来帮助。而执行则千变万化，也是性能优化的重心。下面就来看看JSC是如何来懂得、执行JavaScript脚本的。
解释器工作过程
JavaScriptCore基本的工作过程如下:
对于一个解释器，首先必需要明白所支撑的语言, JSC所支撑的是EMCAScript-262规范。
词法分析和语法分析就是懂得的过程，将输入的文本转为一种它可以懂得的语义情势(抽象语法树), 或者更进一步的生成供后续应用的中间代码(字节码,ByteCode)。
解释器就是担任执行解析输出的结果。正因为执行是优化的重心，所以有JIT来提高执行效能。根据资料，V8还会优化Parser的输出，省去了bytecode, 当解释器有能力直接基于AST执行。
词法分析及语法分析，最著名的工具就是lex/yacc，以及后继者flex/bison(The LEX&YACC Page)。它们为很多软件提供了语言或文本解析的功能，相当壮大，也很有趣。虽然JavaScriptCore并没有应用它们，而是自行编写实现的，但基本思路是相似的。
词法分析(lexer)，其实就是一个扫描器，依据语言的定义，提取出源文件中的内容变为一个个语法可以识别的token，比如关键字，操作符，常量等。在一个文件中定义好规矩就可以了。
语法分析(paser), 它的功能就是根据语法(token的顺序组合)，识别出不同的语义(目标操作)。
比如:
i=3;
经过lexer可能被识别为以下的tokens:
VARIABLE EQUAL CONSTANT END
经过parser一分析，就了解这是一个"赋值操作，向变量i赋值常量3"。随后再调用对应的操作加以执行。
如果你对lexer和parser还不太熟悉，可参考的资料很多，这里有一个基本的入门指引:Yacc与Lex快速入门。
关于解释器和JIT的说明在第3节。
执行的基本环境(Register-based VM)
JSC解析生成的代码放到一个虚拟机上来执行(广义上讲JSC主身就是一个虚拟机)。JSC应用的是一个基于寄存器的虚拟机(register-based VM)，另一种实现方式是基于栈的虚拟机(stack-based VM)。两者的差异可以简略的懂得为指令集传递参数的方式，是应用寄存器，还是应用栈。
绝对于基于栈的虚拟机,因为不需要频繁的压、出栈，以及对三元操作的支撑，register-based VM的效率更高，但可移植性绝对弱一些。
所谓的三元操作符，其中add就是一个三元操作,
add dst, src1, src2
功能是将src1与src2相加，将结果保存在dst中。dst, src1,src2都是寄存器。
为了便利和<<深刻懂得Java虚拟机>>中的示例停止比较，也利用JSC输出以下脚本的ByteCode如下:
[ 0] enter [ 1] mov r0, Cell: 0133FC40(@k0) [ 4] put_by_id r0, a(@id0), Int32: 100(@k1) [ 13] mov r0, Cell: 0133FC40(@k0) [ 16] put_by_id r0, b(@id1), Int32: 200(@k2) [ 25] mov r0, Cell: 0133FC40(@k0) [ 28] put_by_id r0, c(@id2), Int32: 300(@k3) [ 37] resolve_global r0, a(@id0) [ 43] resolve_global r1, b(@id1) [ 49] add r0, r0, r1 [ 54] resolve_global r1, c(@id2) [ 60] mul r0, r0, r1 [ 65] ret r0
*参考: JSC字节码规格 (WebKit没有及时更新，只做为参考，最新的内容还是要看代码.)
而基于栈的虚拟机的生成的字节码如下:
0： bipush 100 2: istore_1 3: sipush 200 6: istore_2 7: sipush 300 10: istore_3 11: iload_1 12: iload_2 13: iadd 14: iload_3 15: imul 16: ireturn
可以帮助懂得它们之间的差异。
核心组件
*这部份基本上译自WebKit官网的JavaScriptCore说明的前半部份。
JavaScriptCore 是一个正在演进的虚拟机(virtual machine), 包括了以下模块: lexer, parser, start-up interpreter (LLInt), baseline JIT, and an optimizing JIT (DFG).
Lexer 担任词法解析(lexical analysis) , 就是将脚本分解为一系列的tokens. JavaScriptCore的 lexer是手动撰写的，大部份代码在parser/Lexer.h 和 parser/Lexer.cpp 中.
Parser 处置语法分析(syntactic analysis), 也就是基于来自Lexer的tokens创立语法树(syntax tree). JavaScriptCore 应用的是一个手动编写的递归下降解析器(recursive descent parser), 代码位于parser/JSParser.h 和 parser/JSParser.cpp .
LLInt, 全称为Low Level Interpreter, 担任执行由Paser生成的字节码(bytecodes). 代码在llint/ 目录里, 应用一个可移植的汇编实现，也被为offlineasm (代码在offlineasm/目录下), 它可以编译为x86和ARMv7的汇编以及C代码。LLInt除了词法解析和语法解释外,JIT编译器所执行的调用、栈、以及寄存器转换都是基本没有启动开销(start-up cost)的。比如，调用一个LLInt函数就和调用一个已被编译原始代码的函数相似, 除非机器码的入口恰是一个共用的LLInt Prologue(公共函数头,shared LLInt prologue). LLInt还包括了一些优化，比如应用inline cacheing来加速属性访问.
Baseline JIT 在函数被调用了6次，或者某段代码循环了100次后(也可能是一些组合，比如3次带有50次枚举的调用)就会触发Baseline JIT。这些数字只是大概的估计，实际上的启发(heuristics)过程是依赖于函数大小和当时内存状态的。当JIT卡在一个循环时，它会执行On-Stack-Replace(OSR)将函数的全部调用者从新指向新的编译代码。Baseline JIT同时也是函数进一步优化的后备，如果没法优化代码时，它还会通过OSR调整到Baseline JIT. BaseLine JIT的代码在 jit/ . 基线JIT也为inline caching执行几乎全部的堆访问。
无论是LLInt和Baseline JIT者会收集一些轻量级的性能信息，以便择机到更高一层级(DFG)执行。收集的信息包括近来从参数、堆，以及返回值中的数据。另外，全部inline caching也做了些处置，以便利DFG停止类型判断，例如，通过查询inline cache的状态，可以检测到应用特定类理停止堆访问的频率。这个可以用于决定是不是进入DFG (文中称这个行为叫speculation, 有点赌一把的意思，能优化获得更高的性能最好，不然就退回来)。在下一节中侧重讲述JavaScriptCore类型推断。
DFG JIT 在函数被调用了至少60次，或者代码循环了1000次，就会触发DFG JIT。一样，这些都是近似数，整个过程也是趋向于启发式的。DFG积极地基于前面(baseline JIT&Interpreter)收集的数据停止类型揣测，这样就可以尽早获得类型信息(forward-propagate type information)，从而减少了大批的类型检查。DFG也会自行停止揣测，比如为了启用inlining, 可能会将从heap中加载的内容识别出一个已知的函数对象。如果揣测失败，DFG取消优化(Deoptimization)，也称为"OSR exit". Deoptimization可能是同步的(某个类型检测分支正在执行)，也可能是异步的(比如runtime视察到某个值变化了，并且与DFG的假设是冲突的)，后者也被称为"watchpointing"。 Baseline JIT和DFG JIT共用一个双向的OSR:Baseline可以在一个函数被频繁调用时OSR进入DFG, 而DFG则会在deoptimization时OSR回到Baseline JIT. 反复的OSR退出(OSR exits)还有一个统计功能: DFG OSR退出会像记载发生频率一样记载下退出的理由(比如对值的类型揣测失败), 如果退出一定次数后，就会引发从新优化(reoptimization), 函数的调用者会从新被定位到Baseline JIT,然后会收集更多的统计信息，或许根据需要再次调用DFG。从新优化应用了指数式的回退策略(exponential back-off,会越来越来)来应对一些奇葩代码。DFG代码在dfg/.
任何时候，函数, eval代码块，以及全局代码(global code)都可能会由LLInt, Baseline JIT和DFG三者同时运行。一个极端的例子是递归函数，因为有多个stack frames，就可能一个运行在LLInt下，另一个运行在Baseline JIT里，其它的可能正运行在DFG里。更为极端的情况是当从新优化在执行过程被触发时，就会出现一个stack frame正在执行本来旧的DFG编译，而另一个则正执行新的DFG编译。为此三者计划成维护雷同的执行语义(execution semantics), 它们的混合应用也是为了带来显著的效能晋升。
*如果想要视察它们的工作，可以在WebKit中的子工程jsc的jsc.cpp中，应用JSC::Options添加一部份log输出.
参考阅读:
虚拟机随谈(一): 解释器，树遍历解释器，基于栈与基于寄存器，大杂烩 http://rednaxelafx.iteye.com/blog/492667
转载请注明出处:http://blog.csdn.net/horkychen
文章结束给大家分享下程序员的一些笑话语录：
人工智能今天的发展水平：8乘8的国际象棋盘其实是一个体现思维与创意的强大媒介。象棋里蕴含了天文数字般的变化。卡斯帕罗夫指出，国际象棋的合法棋步共有1040。在棋局里每算度八步棋，里面蕴含的变化就已经超过银河系里的繁星总数。而地球上很少有任何数量达到这个级别。在金融危机之前，全世界的财富总和大约是1014人民币，而地球人口只有1010。棋盘上，所有可能的棋局总数达到10120，这超过了宇宙里所有原子的总数！经典语录网