简记V8与SquirrleFish/Tamarin的对比点

刚才还是忍不住到V8的官网读了些文档，想看看到底它的技术特点是什么。
V8官网：Google V8 JavaScript Engine
设计概念的文档：Design Elements
有人初试V8的经过：http://d.hatena.ne.jp/amachang/20080903/1220405193

V8是BSD许可证的，比较自由，方便用在各种项目中。
它是一个相当快的JavaScript实现。根据其设计概念的文档，它的高性能主要来自：

• 快速的属性访问
• 动态机器码生成
• 高效的垃圾收集

其中前两点应该是紧密相关联的。在JavaScript引擎的实现中，V8特别就特别在“隐藏类”（hidden class）的使用。Hidden class的概念可以到那篇文档去看，解释得比较生动。简单来说，对于某个对象，每次属性的数量（或类型？这个得回头仔细研究下。更新：V8虽然后来的版本里可以跟踪属性的类型，但这并不影响hidden class transition）发生改变时，虚拟机就会新创建一个对应的隐藏类，记录下其中各个属性的相对偏移量，并将原本的隐藏类与新的隐藏类之间建立一个关联。当再次有同一类型的对象创建时则不会重复创建隐藏类，而能复用前面已经出现的隐藏类。

其它JavaScript引擎（以及许多其它脚本语言的实现）一般使用某种形式的关联容器来储存所有变量；通常叫字典，也会被称为映射表或者关联数组，典型的实现方式是哈希表或者红黑树等。对象中的成员变量（下面将称为“属性”）一般也是这样与某个对象关联在一起的。访问某个对象的某个属性时就需要动态查询这样的关联容器，是不可忽视的开销。
V8则不使用关联容器来储存属性，而是采用更接近于静态编译的类的形式，将对象中每个属性的相对偏移量记下来，在生成机器码时直接把偏移量写到指令中。这样，访问某个对象的某个属性就只需要很少量的指令就能完成，比起关联容器的方式高效许多。

V8使用动态机器码生成，先把要执行的JavaScript代码直接编译为机器码，而不使用字节码也不通过解释的方式来执行。这样在执行一些被大量重复执行的代码时效果会特别好。与之相对，Apple Webkit的JavaScriptCore/SquirrelFish是先将JavaScript编译到字节码，然后以纯解释的方式执行字节码；Mozilla/Adobe的Tamarin则是先将JavaScript编译到字节码，然后以即时编译（JIT）的方式执行。SquirrelFish与Tamarin的字节码设计思路又不一样：前者是基于寄存器的，而后者是基于栈的。一般认为基于寄存器形式的字节码比较快，而基于栈形式的字节码比较小，总之也是各有特点。
与“隐藏类”相关的是，V8会预先猜测某段代码中的对象对应的隐藏类，如果命中的话就能直接用已经生成到机器码里的偏移量；如果没有命中，则使用实际的隐藏类中的信息来修改已生成的机器码。这样，如果多次执行中对象的“实际类型”都与猜测一样，执行速度就可以非常的快。
Mozilla SpiderMonkey里的新JIT编译器，TraceMonkey则通过别的方式来提高执行速度。通过记录代码执行的路径，当发现某条执行路径回到了某个早先经过的节点，就发现了一个“trace”；然后对trace花时间做重点优化，编译为高效的机器码。与HotSpot JVM不同的是，trace不是以函数（或者说方法）为单位的，可以在更小的范围内做精确的优化，减少不必要的优化开销。

在垃圾收集器方面，V8采用的是一个两代的分代式准确垃圾收集器。相对的，JavaScriptCore的GC继承自KJS，没记错的话是一个没有分代的准确M&S式（mark-and-sweep）垃圾收集器；Tamarin使用的则是Adobe提供的MMgc，主要算法是“延迟的引用计数”（DRC，Deferred Reference Counting），外加增量式保守M&S的垃圾收集器。这三种实现方式各有特点，实际效果要比较起来恐怕比较难。准确式的垃圾收集器必须知道堆的位置和布局，所以难以做成通用的；保守式收集器则可以做得很通用，著名的Boehm GC是个典型的例子。但保守式收集器有潜在的内存泄漏的危险，因为可能会把并不是对象指针的数据识别为指针，使本来应该已经可以释放的空间无法被释放。

===========================================================================

V8中使用了下列第三方库：

引用

  - Jscre, located under third_party/jscre.  This code is copyrighted
    by the University of Cambridge and Apple Inc. and released under a
    2-clause BSD license.

  - Dtoa, located under third_party/dtoa.  This code is copyrighted by
    David M. Gay and released under an MIT license.

  - Strongtalk assembler, the basis of the files assembler-arm-inl.h,
    assembler-arm.cc, assembler-arm.h, assembler-ia32-inl.h,
    assembler-ia32.cc, assembler-ia32.h, assembler.cc and assembler.h.
    This code is copyrighted by Sun Microsystems Inc. and released
    under a 3-clause BSD license.

JSCRE我没怎么听说过，不知道跟PCRE（Perl Compatible Regular Expressions）的关系是怎样的。在JSCRE源码的目录里看到了"pcre"的字样，不过详细情况还是以后再看看好了。Apple Webkit里的JavaScriptCore应该是直接用了PCRE的吧？还是说我看漏了……
（更新：JSCRE就是Apple Webkit改造过的版本的PCRE）

===========================================================================

今天Mozilla方面也没忘记对Chrome/V8的发布作出反应。Brendan Eich，JavaScript的创始者，在其blog上发表了一篇相关评论：
Brendan Eich: TraceMonkey Update

Brendan Eich 写道

（向右多的是TraceMonkey比较快，向左多的是V8比较快）
可以看到在Brendan做的SunSpider测试中，TraceMonkey在递归密集的程序中速度会比V8慢许多，而在正则表达式等方面则比V8快。据Brendan称，TraceMonkey的开发时间还不长，递归方面的trace还没多少进度，所以在这部分是比较慢的。但下一步将会解决这个问题。

P.S. KJS也不再用tree-walker方式实现解释器了，改用了字节码解释器：Say hello to KJS/Frostbyte -40.9° and Icemaker
Frostbyte分支的KJS是新的字节码解释器。这个版本的KJS在把JavaScript源码编译到字节码的过程中有做优化，指令选择、代码生成和解释器的主循环都由叫做Icemaker的工具来生成。很多其它编译器是在生成native code的codegen才会做这种指令选择，KJS选择在这个位置做感觉挺依赖解释器自身的性能⋯

评论

7 楼 lurker0 2010-02-17  

RednaxelaFX 写道

lurker0 写道

总结得比较全  很不错  鼓励一下

其实要说全的话，草稿箱里还堆着几篇跟V8相关的帖，但没整理好所以没发出来……
不过最近准备改变策略了，没整理好的资料也照样扔到HLL VM圈子里堆着再说 >_<||

扔吧，我等着 ：） 

6 楼 RednaxelaFX 2010-02-11  

lurker0 写道

总结得比较全  很不错  鼓励一下

其实要说全的话，草稿箱里还堆着几篇跟V8相关的帖，但没整理好所以没发出来……
不过最近准备改变策略了，没整理好的资料也照样扔到HLL VM圈子里堆着再说 >_<||

5 楼 lurker0 2010-02-10  

总结得比较全  很不错  鼓励一下

4 楼 RednaxelaFX 2008-09-05  

哈哈，这让我产生个有趣的联想：听说过微软的Volta的人应该会知道，Volta有能力将CIL（或者叫MSIL，.NET平台的字节码）转换为其它形式，使.NET Framework可以延伸到更广泛的平台上。其中一个重要的组成部分就是CIL-to-JavaScript的转换器。换言之，利用Volta，以后有机会用C#写在浏览器中运行的客户端程序，而不一定要客户端安装任何形式的.NET Framework（包括Silverlight 2或更高版本）。现有的已正式发布的浏览器中的JavaScript引擎要负担起高强度的计算恐怕还是很勉强，但随着V8、TraceMonkey和JavaScriptCore/SquirrelFish的出现，状况有了很大的变化。对微软来说有高速的JavaScript引擎也未尝不是一件好事呢。

3 楼 achun 2008-09-05  

V8能生成机器码,照这个下去,前后台语言就要统一了.
对javascript越来越有信心了.

2 楼 RednaxelaFX 2008-09-05  

lwwin 写道

你看了这么多脚本的实现吗＝ ＝??

没全看啦。老的（或者说现在在FireFox 3.0里的）SpiderMonkey看得比较多，其次是KDE的KJS；Mozilla/Adobe的Tamarin/AMV2很仔细的阅读过它的文档，看了指令集和生成代码的状况；Apple Webkit的JavaScriptCore只看了很少一点，而Google V8才抓下来还没详细的看。上面的多数信息都是从它们的官方文档收集过来的，有很少部分是我自己看代码了解的。

1 楼 lwwin 2008-09-04  

你看了这么多脚本的实现吗＝ ＝??