JavaScriptCore, WebKit的JS实现(完)

曾经终败给现在 2022-06-02 05:42 163阅读 0赞

什么是method JIT? 什么是DFG JIT? JSC的DFG JIT与V8 Crankshaft相比有何优劣?

**JIT:一个方法式的JIT(a method jit)**

*\*关于method JIT，可以参考另一份*[*档案*][Link 1]*。*

关于解释器(interpreter)和堆栈(stack,也就是寄存器文件,register file)都是应用了方法式JIT(method JIT). 所谓简单方法JIT(确实没什么特别的名字)做得事和字节码解释器完全一样，只不过它的结果是机器码，而不是虚拟的机令集。

也没什么好说的，JIT的结果可以减少调度的开销，特别是允许对特定上下文进行编译时(原文:jitting the code has the result you would expect, reducing dispatching overhead, while at the same time allowing some context-specific compilation), 就比如当给一个变量赋个整数常量。这个JIT只能算是凑合(quick-and dirty), 所以传统的Method JIT，像HotSopt C1及C2, 并没有明显的好处。相对而言，寄存器式的VM字节码却保证可以为JSC带来显著的提升，不过到目前为止，JSC在这个方向上并没做什么。

再思考一下，我认为对于JavaScript而言，CSE只有在你知道类型时才可能有作用，毕竟JS的valueOf()并不那么靠谱！

**DFG:JSC的Crankshaft? (dfg: a new crankshaft for jsc)?**

由Gavin Barraclough和Filip Pizlo开发的数据流图JIT(data flow graph,DFG JIT)是一种推测性优化技术。比如，当有如下JS代码:

a[i++] = 0.7*x;

那么a很可能是一个浮点型数组，而i则很可能是一个整数。你应该可以想到，如果使用原始的数组和整数操作，就能达到很好的性能，于是尝试着将这份代码按照这个假设编译出了一个新的版本。如果这个方法最终失败了(有不符先前假设的情况发生了)，就把这份代码中全身而退(bail out)，再回到原先的method JIT。

事实上，解释器(interpreter)和simple method JIT有一个清晰的字节码语义模型来确保在必要时从DFG JIT中轻易地退出来。只需要重建虚拟寄存器和Register Windows(奇怪的名字,和register file一样. ^\_^)的状态，然后跳转回原先的代码即可。 (V8 称之为"逆优化(deoptimization)"; DFG则称之为"投机不成(speculation failure)".)

还有另一种从simple JIT跳转到DFG JIT的方法，叫栈上替换([on-stack replacement][], OSR). DFG JIT就是这样做的。我就听说用了OSR就可以在[Kraken][](一个JS性能测试器)测试中胜出,这个测试器会使用大量紧凑的循环，所以你必须能够在不依赖函数的反复进入的情况下优化你的代码（Method JIT就是这么干的!）。

当DFG JIT启用后，解释器(如果有的话)和简单方法(simple method) JIT会对性能数据进行判断，它会记录代码各部分的流转类型(flow types)。如果一个循环被执行相当次数(目前是大于1000次),或者一个函数会调用了很多次(目前是70次), DFG JIT就会行动了。它将相应的字节码解析为SSA(Static Single Assignment)形式, 然后沿着执行路径收集类型信息。这个过程很像我在[另一篇文章][Link 2]中所说明的情形。

JSC和Crankshaft的区别在于Crankshaft从Inline Caches中直接获得类型信息，而不是从代码中检测。我认为Crankshaft的实现更为优雅一些，但当GC(垃圾回收,garbage collection)释放了缓存(cache)后，它就会得很弱了。

我以前提到过inlining,  DFG JIT就会使用它，并且像HotSpot一样在解析时使用。类型分析(type profiling) (也称为value profiling)组合运用一些简易的静态分析技术，使得DFG可以使int32和双精度数据类型区分开来。

有一件事DFG JIT目前还做不到，就是代码移动中一些情况(code motion,又是一个编译领域的名词)。它虽然可以做去除死代码和公共表达式，但它的前提条件是必须能做类型分析(value profile)。而针对[循环不变量][Link 3]的code motion，这是做不到的（因为值不变嘛）。

另外,DFG的寄存器分配器(register allocator)不及Crankshaft的好。这是由于JSC汇编造成的的阻碍。在构造良好的、健壮的代码片段的同时,JSC的汇编程序使用双地址的接口(interface)而不是三址的。这意味着,不需要像add(dest,op1,op2)的方法，而是add(op1,op2),其结果被默认存在第一个操作数中。它是针对x86指令集的,但对于有更多寄存器的系统(如x86 - 64),这并不算什么。

对于计算结果，需要更多代码的基于计数的优化触发方式并不是绝对必要, 但这种策略确实有个很好的特性：DFG的性能是可预见的且可衡量的。而另一方面的Crankshaft则使用统计方式触发,其性能是一种[统计式的分布][Link 4]。

对于性能，因为DFG仅在Mac OS 64位版本可用，所以可以使用[AWFY on the mac][Link 4]进行测试。你一定要使用正确的工具进行性能评测。

看看结果就知道，JSC对V8基准(benchmark)的表现很不错。有趣的是，对于SunSpider测试，JSC打败了V8。不过V8一旦热身后，仍然是表现最好的. JSC做得很不错，而且正在逐渐改进中。

**未来(future)**

这就是JavaScriptCore. 当前团队的三个人(是的),正专注在DFG JIT上。其中最关键的是什么时候可以将DFG JIT运行到其它系统上。

JSC的另一个工作是新一代的垃圾回收器(new generational garbage collector)。它确实在做，但很慢。虽然有了Card-Marking write barriers(这是一垃圾回收领域的专业名词)的预留函数(stubs),但目前为止并没有相应的实现。不过，至少JSC提供了[Handle][] API, 盖过了SpiderMonkey。

上一篇: [JavaScriptCore, WebKit的JS实现(一)][JavaScriptCore_ WebKit_JS]

转载请注明出处: [http://blog.csdn.net/horkychen][http_blog.csdn.net_horkychen]

[Link 1]: http://download.csdn.net/detail/horkychen/4519002
[on-stack replacement]: http://wingolog.org/archives/2011/06/20/on-stack-replacement-in-v8
[Kraken]: http://krakenbenchmark.mozilla.org/
[Link 2]: http://wingolog.org/archives/2011/08/02/a-closer-look-at-crankshaft-v8s-optimizing-compiler
[Link 3]: http://blog.csdn.net/yizhili/article/details/4705377
[Link 4]: http://arewefastyet.com/?a=b&machine=8
[Handle]: http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/heap/Handle.h
[JavaScriptCore_ WebKit_JS]: http://blog.csdn.net/horkychen/article/details/7888647
[http_blog.csdn.net_horkychen]: http://blog.csdn.net/horkychen