• Home
  • home > webfront > browser > webkit >

    JS引擎(0):JavaScript引擎群雄演义—起底JavaScript引擎

    Author：zhoulujun Date：

    其实早期的两个主要的JavaScript引擎实现，一直在用mark-and-sweep GC。Java写的Rhino一度能比用C写的SpiderMonkey跑得还快，因为Rhino得益于JVM里优秀的JIT编译器和GC，而SpiderMonkey还在用简易的解释器和GC。

    JavaScript 既是一个 面向过程的语言 又是一个 面向对象的语言。在 JavaScript 中，通过在运行时给空对象附加方法和属性来创建对象，与编译语言如 C++ 和 Java 中常见的通过语法来定义类相反。对象构造后，它可以用作是创建相似对象的原型。

    JavaScript 的动态特性包括运行时构造对象、可变参数列表、函数变量、动态脚本执行（通过 eval）、对象内枚举（通过 for ... in）和源码恢复（JavaScript 程序可以将函数反编译回源代码）。

    JavaScript方面，之前写过《ECMAScript进化史(1):话说Web脚本语言王者JavaScript的加冕历史》

    在看 各JavaScript引擎的简介，及相关资料/博客收集帖 ，结合自己的理解，整理一个笔记。现代JavaScript引擎都有哪些特征呢？跟以前的JavaScript引擎有怎样的差别，为什么变快了那么多？

    JavaScript引擎历史

    早期JavaScript引擎的实现普遍跟同时代的其它脚本语言一样，比较“偷懒”。反正是“脚本语言”，当时的JavaScript脚本通常只包含很简单的逻辑，只运行很短时间就完事。没啥性能压力，得不到足够的重视与开发资源，性能自然是好不到哪里去，却也足以满足当时的需求。

    Mocha

    非常早期的“Mocha”引擎实现得确实非常偷懒。字节码解释器、引用计数方式的自动内存管理、fat discriminated union形式的值表现形式。犀牛书第4版写了点JavaScript与引用计数的历史。

    SpiderMonkey

    1996年，祖师爷Brendan Eich新写的SpiderMonkey已经改为使用mark-and-sweep GC、tagged value。

    在V8出现前，SpiderMonkey是native application嵌入JavaScript的最流行选择。如果大家没留意过的话，UltraEdit就内嵌了SpiderMonkey来让用户使用JavaScript写宏与插件[/url]；Adobe Acrobat也类似。

    于是其实早期的两个主要的JavaScript引擎实现，Mozilla SpiderMonkey和Microsoft JScript其实都一直在用mark-and-sweep GC。也没啥别的主流JavaScript引擎用过引用计数方式来实现自动内存管理的。这点别被忽悠了。

    在叫得出名字的JavaScript引擎里只有quad-wheel（没听说过么？不奇怪，非主流嘛）是用引用计数方式实现自动内存管理的。

    老版本IE里JScript虽说是有因为循环引用而导致内存泄漏的问题，但那不是因为JScript自身用引用计数。问题出在JScript与DOM交互的边界上：IE的DOM节点（及其它host对象）是COM对象，而COM对象自身是引用计数的。在JS一侧GC时DOM节点被看作根节点，所以被DOM节点引用的JS对象不会死；反过来，被JS对象引用的DOM节点的引用计数不为0所以也不会死。这导致JScript与DOM交互时有可能被连累引发循环引用->内存泄漏的问题。

    IE9/Chakra里已经通过把DOM对象变成由JavaScript一侧的GC来管理解决了这个问题。

    早期JavaScript引擎得到的投入实在不足，而当时的Java虚拟机（JVM）却得到了大量资源实现各种优化，包括JIT编译器之类。这使得用Java写的Rhino一度能比用C写的SpiderMonkey跑得还快，因为Rhino得益于JVM里优秀的JIT编译器和GC，而SpiderMonkey还在用简易的解释器和GC。

    这个阶段中，JavaScript对象的布局或者说表现方式通常可以叫做“property bag”，本质上就跟hashmap一样。

    Rhino/Nashorn

    Rhino是Java版的SpiderMonkey。当时Netscape想用纯Java来实现新版浏览器，自然需要一个Java版的JavaScript引擎实现；另外也希望能在服务器端把JavaScript当作Java应用里的脚本语言使用。于是Rhino就诞生了。

    具体查看《Java集成JavaScript项目工程：基于Rhino的javascript后台开发》

    KJS

    Apple把KHTML拿去演化出了WebKit，其中的KJS演化成了JavaScriptCore。KJS影响力远不如JavaScriptCore。KJS是为数不多的没有JIT编译器的。

    JavaScriptCore

    JavaScriptCore源自KJS，但持续得到苹果的大力投入，终而青出于蓝胜于蓝，已经完全超越了它的前身。

    QtScript背后也使用JavaScriptCore。

    虽然iOS的Safari和UIWebView控件里跑的都是JavaScriptCore，但只有Apple自己的程序才可以启用JIT编译，而第三方的则不行。所以Mobile Chrome for iOS就用不了JavaScriptCore的JIT。

    Chakra

    Chakra问世后的JScript已非当日吴下阿蒙。

    即便Chakra的解释器也是字节码解释器，它的字节码设计与老版本JScript的已经相当不同，解释器自身的速度都已经有所提升。

    Chakra里的隐藏类变迁机制叫做“type evolution”。每个产品都必须发明些新名词

    E9版Chakra里字段数量不超过16个的对象可以使用紧凑布局；IE10版Chakra将这限制放宽到30多个字段。

    IE9 Chakra的对象布局是对象头与property数组分离的。IE10版则将构造器函数里赋值的属性直接跟对象头粘在一起分配。

    Chakra里的value representation跟V8的比较类似，都是在最低的几位放tag；不过Chakra的是tagged-value，也就是在小整数的后面带上一个0x1的tag，而对象地址是8字节对齐的于是对象指针的最低3位为0。打tag的取舍正好与V8的tagged-pointer相反，而与更多其它用tagged-value的VM相似，例如说更传统的Smalltalk实现，包括现在还可以用到的Squeak，或者是像Ruby等受Smalltalk影响的VM。

    注意：IE9在x64上的版本里的Chakra只有解释器，没实现JIT编译器；到IE10才开始在x64版上提供JIT编译器。

    同样只有字节码解释器，IE9 64-bit的Chakra仍然可以比IE8 64-bit的JScript 5.8快近10倍

    JScript

    JScript 5.8（IE8里的JScript）之后版本号重新计算了，下一个大版本就是IE9里的JScript 9.0，代号Chakra，在前面有介绍。

    JScript里对象里属性的存储基本上是靠Hashtable；数组性质的对象最初也是为稀疏数组优化，背后仍然是用Hashtable来存储。到IE8/JScript 5.8才加上了对密集数组的存储/访问优化。

    执行引擎是个简单的解释器，switch-threading形式的解释器主循环，位于CScriptRuntime::Run(VAR*)。在jscript.dll里这个switch被编译为一个table-based dispatch。

    被这两处调用：

    ScrFncObj::CallWithFrameOnStack(VAR *,int,VAR *,VAR *,ulong)

    ScrFncObj::Call(VAR *,int,VAR *,VAR *,ulong)


    用于优化字符串拼接用的BuildString类。在Chakra里也继承了下来。

    不常见的JavaScript引擎

    上面的JavaScript引擎都是常见

    IronJS

    IronJS原本完全使用F#实现，后来改为只用F#来实现parser，而用C#来实现runtime部分。这是个非常妙的搭配。F#（以及许多函数式语言）天生就非常适合用来写需要大量模式匹配的程序，写parser最适合不过。而runtime部分更多是与.NET的其它部分打交道，这里用C#就会更顺手些。

    Ironjs是在Microsoft 动态语言运行时之上构建的ECMAScript 3.0实现，它使您可以将JavaScript运行时嵌入到.NET应用程序中。

    使用Ironjs环境

    • .NET 3.5（Src / CLR2.sln）

    • .NET 4.0（Src / CLR4.sln）

    • Mono 2.10（Src / mono-build.sh）

    Ironjs还具有对.NET 2.0和3.0的实验性支持，可使用CLR2解决方案进行编译并设置额外的NET2标志。

    IronJS的parser整体采用top-down operator precedence（TDOP）方式，在JavaScript的引擎实现中比较少见。不过却正好与微软自家的Managed JScript相似。不知道作者在写IronJS时是否有受Managed JScript的思路影响呢？

    如果采用TDOP不是Managed JScript的影响，那或许是受Douglas Crockford大神那篇TDOP教程的影响了。

    最初的IronJS其实用的是基于ANTLR生成的parser。不过后来用F#新写的parser比老的ANTLR生成的parser快得多。

    不过作者决定在下一版IronJS里改为完全使用C#，主要是出于性能方面的考虑。并不是F#本身不够快，而是F#的各种方便简洁的功能容易引人写出不那么快的代码，而要写比较高效的代码样子会跟C#看起来很像。于是还不如直接用C#好了。

    IronJS使用了Nan-boxing，只不过比起那些用C/C++之类的native语言所实现的NaN-boxing tagged pointer而言，IronJS版的比较“肥”一些——例如说JavaScriptCore的一个tagged pointer在x86-64上就是64位，跟一个double一样大，指针类型的值跟值类型的值可以重叠在同一个位置上；而在IronJS的则要128位，其中值类型的值与tag在头64位，而指针类型在后64位。

    虽然肥一些，作为Nan-boxing的思路和效果还是类似的。用了tagged pointer之后至少那些值类型的值的内存开销都变小了——不用tagged pointer的话自动装箱的double在32位CLR上也至少得要16字节，外加引用它的指针4字节也得要20字节了，而IronJS的BoxedValue则总共只要16字节而且不会有额外指针带来的间接层，在内存局部性上也比不用tagged pointer好。


    参考文章：

    关于 JavaScript https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/About_JavaScript

    各JavaScript引擎的简介，及相关资料/博客收集帖 https://hllvm-group.iteye.com/group/topic/37596

    用 JavaScript 解释 JavaScript 虚拟机-内联缓存（inline caches） https://segmentfault.com/a/1190000010819044

    GC的三种收集方法：标记清除、标记整理、复制算法的原理与特点，分别用在什么地方，优化收集方法的思路 https://blog.csdn.net/fateruler/article/details/81158510



    转载本站文章《JS引擎(0):JavaScript引擎群雄演义—起底JavaScript引擎》,
    请注明出处：https://www.zhoulujun.cn/html/webfront/browser/webkit/2020_0718_8521.html

    收藏
    上一篇：JS引擎(2)：Java平台上JavaScript引擎—Rhino/Nashorn概述
    下一篇：JS引擎(1):JS引擎擂台赛，JavaScript引擎的特征比较及术语科普