刚才还是忍不住到V8的官网读了些文档，想看看到底它的技术特点是什么。
V8官网：[url=http://code.google.com/p/v8/]Google V8 JavaScript Engine[/url]
设计概念的文档：[url=http://code.google.com/apis/v8/design.html]Design Elements[/url]
有人初试V8的经过：[url]http://d.hatena.ne.jp/amachang/20080903/1220405193[/url]
V8是BSD许可证的，比较自由，方便用在各种项目中。
它是一个相当快的JavaScript实现。根据其设计概念的文档，它的高性能主要来自：
[list][*]快速的属性访问
[*]动态机器码生成
[*]高效的垃圾收集[/list]
其中前两点应该是紧密相关联的。在JavaScript引擎的实现中，V8特别就特别在“隐藏类”（hidden class）的使用。Hidden class的概念可以到那篇文档去看，解释得比较生动。简单来说，对于某个对象，每次属性的数量（或类型？这个得回头仔细研究下。更新：V8虽然后来的版本里可以跟踪属性的类型，但这并不影响hidden class transition）发生改变时，虚拟机就会新创建一个对应的隐藏类，记录下其中各个属性的相对偏移量，并将原本的隐藏类与新的隐藏类之间建立一个关联。当再次有同一类型的对象创建时则不会重复创建隐藏类，而能复用前面已经出现的隐藏类。
其它JavaScript引擎（以及许多其它脚本语言的实现）一般使用某种形式的关联容器来储存所有变量；通常叫字典，也会被称为映射表或者关联数组，典型的实现方式是哈希表或者红黑树等。对象中的成员变量（下面将称为“属性”）一般也是这样与某个对象关联在一起的。访问某个对象的某个属性时就需要动态查询这样的关联容器，是不可忽视的开销。
V8则不使用关联容器来储存属性，而是采用更接近于静态编译的类的形式，将对象中每个属性的相对偏移量记下来，在生成机器码时直接把偏移量写到指令中。这样，访问某个对象的某个属性就只需要很少量的指令就能完成，比起关联容器的方式高效许多。
V8使用动态机器码生成，先把要执行的JavaScript代码直接编译为机器码，而不使用字节码也不通过解释的方式来执行。这样在执行一些被大量重复执行的代码时效果会特别好。与之相对，Apple Webkit的JavaScriptCore/[url=http://webkit.org/blog/189/announcing-squirrelfish]SquirrelFish[/url]是先将JavaScript编译到字节码，然后以纯解释的方式执行字节码；Mozilla/Adobe的[url=http://www.mozilla.org/projects/tamarin/]Tamarin[/url]则是先将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提供的[url=http://developer.mozilla.org/En/MMgc]MMgc[/url]，主要算法是“延迟的引用计数”（DRC，Deferred Reference Counting），外加增量式保守M&S的垃圾收集器。这三种实现方式各有特点，实际效果要比较起来恐怕比较难。准确式的垃圾收集器必须知道堆的位置和布局，所以难以做成通用的；保守式收集器则可以做得很通用，著名的[url=http://www.hpl.hp.com/personal/Hans_Boehm/gc/]Boehm GC[/url]是个典型的例子。但保守式收集器有潜在的内存泄漏的危险，因为可能会把并不是对象指针的数据识别为指针，使本来应该已经可以释放的空间无法被释放。
===========================================================================
V8中使用了下列第三方库：
[quote] - 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.[/quote]
JSCRE我没怎么听说过，不知道跟PCRE（Perl Compatible Regular Expressions）的关系是怎样的。在JSCRE源码的目录里看到了"pcre"的字样，不过详细情况还是以后再看看好了。Apple Webkit里的JavaScriptCore应该是直接用了PCRE的吧？还是说我看漏了……
（更新：JSCRE就是Apple Webkit改造过的版本的PCRE）
===========================================================================
今天Mozilla方面也没忘记对Chrome/V8的发布作出反应。Brendan Eich，JavaScript的创始者，在其blog上发表了一篇相关评论：
[url=http://weblogs.mozillazine.org/roadmap/archives/2008/09/tracemonkey_update.html]Brendan Eich: TraceMonkey Update[/url]
[quote="Brendan Eich"][img]http://rednaxelafx.iteye.com/upload/picture/pic/21171/c2cbf917-ce6a-356e-ad25-3ae36907ec8b.png[/img][/quote]
（向右多的是TraceMonkey比较快，向左多的是V8比较快）
可以看到在Brendan做的SunSpider测试中，TraceMonkey在递归密集的程序中速度会比V8慢许多，而在正则表达式等方面则比V8快。据Brendan称，TraceMonkey的开发时间还不长，递归方面的trace还没多少进度，所以在这部分是比较慢的。但下一步将会解决这个问题。
P.S. KJS也不再用tree-walker方式实现解释器了，改用了字节码解释器：[url=http://www.kdedevelopers.org/node/3323]Say hello to KJS/Frostbyte -40.9° and Icemaker[/url]
Frostbyte分支的KJS是新的字节码解释器。这个版本的KJS在把JavaScript源码编译到字节码的过程中有做优化，指令选择、代码生成和解释器的主循环都由叫做Icemaker的工具来生成。很多其它编译器是在生成native code的codegen才会做这种指令选择，KJS选择在这个位置做感觉挺依赖解释器自身的性能⋯
V8官网：[url=http://code.google.com/p/v8/]Google V8 JavaScript Engine[/url]
设计概念的文档：[url=http://code.google.com/apis/v8/design.html]Design Elements[/url]
有人初试V8的经过：[url]http://d.hatena.ne.jp/amachang/20080903/1220405193[/url]
V8是BSD许可证的，比较自由，方便用在各种项目中。
它是一个相当快的JavaScript实现。根据其设计概念的文档，它的高性能主要来自：
[list][*]快速的属性访问
[*]动态机器码生成
[*]高效的垃圾收集[/list]
其中前两点应该是紧密相关联的。在JavaScript引擎的实现中，V8特别就特别在“隐藏类”（hidden class）的使用。Hidden class的概念可以到那篇文档去看，解释得比较生动。简单来说，对于某个对象，每次属性的数量（或类型？这个得回头仔细研究下。更新：V8虽然后来的版本里可以跟踪属性的类型，但这并不影响hidden class transition）发生改变时，虚拟机就会新创建一个对应的隐藏类，记录下其中各个属性的相对偏移量，并将原本的隐藏类与新的隐藏类之间建立一个关联。当再次有同一类型的对象创建时则不会重复创建隐藏类，而能复用前面已经出现的隐藏类。
其它JavaScript引擎（以及许多其它脚本语言的实现）一般使用某种形式的关联容器来储存所有变量；通常叫字典，也会被称为映射表或者关联数组，典型的实现方式是哈希表或者红黑树等。对象中的成员变量（下面将称为“属性”）一般也是这样与某个对象关联在一起的。访问某个对象的某个属性时就需要动态查询这样的关联容器，是不可忽视的开销。
V8则不使用关联容器来储存属性，而是采用更接近于静态编译的类的形式，将对象中每个属性的相对偏移量记下来，在生成机器码时直接把偏移量写到指令中。这样，访问某个对象的某个属性就只需要很少量的指令就能完成，比起关联容器的方式高效许多。
V8使用动态机器码生成，先把要执行的JavaScript代码直接编译为机器码，而不使用字节码也不通过解释的方式来执行。这样在执行一些被大量重复执行的代码时效果会特别好。与之相对，Apple Webkit的JavaScriptCore/[url=http://webkit.org/blog/189/announcing-squirrelfish]SquirrelFish[/url]是先将JavaScript编译到字节码，然后以纯解释的方式执行字节码；Mozilla/Adobe的[url=http://www.mozilla.org/projects/tamarin/]Tamarin[/url]则是先将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提供的[url=http://developer.mozilla.org/En/MMgc]MMgc[/url]，主要算法是“延迟的引用计数”（DRC，Deferred Reference Counting），外加增量式保守M&S的垃圾收集器。这三种实现方式各有特点，实际效果要比较起来恐怕比较难。准确式的垃圾收集器必须知道堆的位置和布局，所以难以做成通用的；保守式收集器则可以做得很通用，著名的[url=http://www.hpl.hp.com/personal/Hans_Boehm/gc/]Boehm GC[/url]是个典型的例子。但保守式收集器有潜在的内存泄漏的危险，因为可能会把并不是对象指针的数据识别为指针，使本来应该已经可以释放的空间无法被释放。
===========================================================================
V8中使用了下列第三方库：
[quote] - 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.[/quote]
JSCRE我没怎么听说过，不知道跟PCRE（Perl Compatible Regular Expressions）的关系是怎样的。在JSCRE源码的目录里看到了"pcre"的字样，不过详细情况还是以后再看看好了。Apple Webkit里的JavaScriptCore应该是直接用了PCRE的吧？还是说我看漏了……
（更新：JSCRE就是Apple Webkit改造过的版本的PCRE）
===========================================================================
今天Mozilla方面也没忘记对Chrome/V8的发布作出反应。Brendan Eich，JavaScript的创始者，在其blog上发表了一篇相关评论：
[url=http://weblogs.mozillazine.org/roadmap/archives/2008/09/tracemonkey_update.html]Brendan Eich: TraceMonkey Update[/url]
[quote="Brendan Eich"][img]http://rednaxelafx.iteye.com/upload/picture/pic/21171/c2cbf917-ce6a-356e-ad25-3ae36907ec8b.png[/img][/quote]
（向右多的是TraceMonkey比较快，向左多的是V8比较快）
可以看到在Brendan做的SunSpider测试中，TraceMonkey在递归密集的程序中速度会比V8慢许多，而在正则表达式等方面则比V8快。据Brendan称，TraceMonkey的开发时间还不长，递归方面的trace还没多少进度，所以在这部分是比较慢的。但下一步将会解决这个问题。
P.S. KJS也不再用tree-walker方式实现解释器了，改用了字节码解释器：[url=http://www.kdedevelopers.org/node/3323]Say hello to KJS/Frostbyte -40.9° and Icemaker[/url]
Frostbyte分支的KJS是新的字节码解释器。这个版本的KJS在把JavaScript源码编译到字节码的过程中有做优化，指令选择、代码生成和解释器的主循环都由叫做Icemaker的工具来生成。很多其它编译器是在生成native code的codegen才会做这种指令选择，KJS选择在这个位置做感觉挺依赖解释器自身的性能⋯
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
