• home > webfront > browser > webkit >

    JS引擎(1):JS引擎擂台赛,JavaScript引擎的特征比较及术语科普

    Author:zhoulujun Date:

    V8的性能远高于当时所有其它JavaScript引擎,各大JavaScript引擎的实现者都坐不住了,像打了鸡血似的使劲优化优化再优化。当代JavaScript引擎之间有许多共通的实现技巧。多数优化会对JavaScript程序的行为做一定猜测(speculate)

    上篇介绍过JavaScript引擎的历史,《JS引擎(0):起底各种JavaScript引擎群雄争霸之路

    一些流行的 JavaScript 引擎

    • SpiderMonkey ,Brendan Eich 在Netscape创建,由 C/C++ 语言开发,可适配 ECMA-262 Edition 5 及其之后的标准版本

    • Rhino,由 Norris Boyd(归属Netscape)创建,则是一个 Java 语言开发的 JavaScript 实现,跟SpiderMonkey 

    • Google 的 V8,在 Google Chrome 浏览器和较新的 Opera 浏览器中使用。这同时也是Node.js使用的引擎。

    • JavaScriptCore (SquirrelFish/Nitro),被用在了一些 WebKit 浏览器如 Apple Safari。

    • Carakan,用在旧版本 Opera 中。

    • The Chakra 引擎

    几种较老的JavaScript引擎的特征:

    不懂的术语,可以跳转至 JavaScript引擎相关关术语解析


    SpiderMonkeyJScriptKJS
    实现语言CC++C++
    执行模式解释执行解释执行解释执行
    解释器字节码解释器:基于栈的字节码字节码解释器:基于栈的字节码树遍历解释器
    动态编译器
    自动内存管理mark-and-sweepmark-and-sweepmark-and-sweep
    对象布局?基本上是HashTable?
    针对密集数组的优化?无 (JScript < 5.7);有(JScript 5.8)?
    Inline-cache???
    值表现形式tagged-value堆对象堆对象
    Function.prototype.toString()从字节码反编译??

    在Google推出V8之后,业界受到巨大冲击。V8的性能远高于当时所有其它JavaScript引擎,可以有效支撑起当时兴起的大量使用JavaScript的Web应用。

    各大JavaScript引擎的实现者都坐不住了,像打了鸡血似的使劲优化优化再优化。先是把已在其它HLLVM上得到充分验证的优化技术引入到JavaScript引擎中,然后再针对JavaScript语言的特点做专项优化。

    现在(2013-04)几种主流的JavaScript引擎的特征:


    V8SpiderMonkeyChakraNitroNashorn
    实现语言C++/汇编C++C++C++/汇编Java
    执行模式纯编译: 两层编译解释/编译混合式: 3层执行模式解释/编译混合: 2层执行模式,后台编译解释/编译混合: 3层执行模式纯编译
    解释器字节码解释器字节码解释器:基于寄存器的字节码字节码解释器 LLInt:基于寄存器的字节码
    动态编译器初级编译器 + 优化编译器初级编译器 Baseline + 优化编译器 IonMonkey初级编译器 method JIT + 优化编译器 DFG JIT
    自动内存管理

    分代式GC: 初生代: copying收集器;

     年老代: 增量式mark-and-sweep, 可选compact

    分代式GC

    分代式GC: 初生代: copying收集;

     年老代: 并发式mark-and-sweep

    分代式GC依赖于底层JVM的GC
    对象布局紧凑+隐藏类 Map紧凑+隐藏类 Shape紧凑+隐藏类紧凑+隐藏类 Structure紧凑+隐藏类 PropertyMap
    针对密集数组的优化
    Inline-cacheMIC/PICPICPICPICMIC/PIC
    值表现形式tagged-pointer / IEEE 754 double / integerpun-boxingtagged-valueNaN-boxing  堆对象 / integer
    正则表达式编译 Irregexp编译编译编译 WREC混合
    Function. prototype. toString()保留源码原文(2012年7月前) 从字节码反编译; (761723后) 保留源码原文 ??保留源码原文


    JavaScript引擎相关术语解析

    • 树遍历解释器:tree-walking interpreter遍历抽象语法树来解释执行的解释器

    • 对象布局: object representation 或者 object layout。指在堆上分配的JavaScript对象的在内存中的布局。

    • 值表现形式: value representation。注意跟“对象布局”说的不是一件事。这个指的是原始类型数据、指向堆上分配的对象的指针之类的值的表现形式。对某些JavaScript引擎来说这是指“JSValue”背后在内存中的表现形式。新生代中的对象98%是“朝生夕死”的,所以并不需要按照1:1的比例来划分内存空间,而是将内存分为一块较大的Eden空间和两块较小的Survivor空间,每次使用Eden和其中一块Survivor。当回收时,将Eden和Survivor中还存活着的对象一次性的复制到另外一块Survivor。当回收时,将Eden和Survivor中还存活着的对象一次性的复制到另外一块Survivor空间上,最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1,也就是每次新生代中可用内存为整个新生代容量的90%(80%+10%),只有10%的内存会被“浪费”。

    • copying GC: 也叫scavenger。垃圾收集算法——复制算法,他将可用内存按容量划分为大小相等的两块,每次只使用其中一块。当这一块的内存用完了,就将还存活着的对象复制到另外一块上面,然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收,内存分配时也就不用考虑内存碎片等复杂情况,只要移动堆顶指针,按顺序分配内存即可,实现简单,运行高效。

      现在的商业虚拟机都采用这种收集算法来回收新生代,这种算法的代价是将内存缩小为了原来的一半

      • IC,Inline caching,内联缓存。实际上是一门近30年的非常古老的技术,最初用在Smalltalk虚拟机上。工作原理:创建一个高速路来绕过运行时系统来读取对象的属性:对传入的对象及其属性作出某种假设,然后通过一个低成本的方式验证这个假设是否正确,如果正确就读取上次缓存的结果。在充满了动态类型和晚绑定以及其他古怪行为——比如eval——的语言里对一个对象作出合理的假设是非常困难的,所以我们退而求其次,让我们的读/写操作能够有学习能力:一旦它们看见某个对象它们就可以以某种方式来自适应,使得之后的读取操作在遇到类似结构的对象时能够更快地进行。在某种意义上,我们将要在读/写操作上缓存关于之前见过的对象的布局的相关知识——这也是内联缓存这个名字的由来。内联缓存可以被用在几乎所有需要动态行为的操作上,只要你可以找到正确的高速路:算数操作、调用自由函数、方法调用等等。有些内联缓存还能缓存不止一条快速通道,这些内联缓存就变成了多态的。

      • MIC: monomorphic inline-cache,单态内联缓存。有一个简单的直接类型检查开销,然后是普通的直接调用开销。

    • PIC: polymorphic inline-cache,多态内联缓存

    • pun-boxing: Packed NaN unboxing,SpiderMonkey和LuaJIT似乎都在用pun boxing

    当代JavaScript引擎之间有许多共通的实现技巧

    当代JavaScript引擎之间有许多共通的实现技巧。多数优化会对JavaScript程序的行为做一定猜测(speculate),并基于猜测做激进优化(speculative optimization)。下面挑几个简单介绍一下。

    从源语言到中间表示的编译器(source-to-IR compiler)

      也叫做编译器的“前端”。

      递归下降式语法分析器(recursive-descent parser)

      运算符优先级式语法分析器(operator precedence parser)

      deferred parser / diet parser(延迟语法分析)

    从中间表示到目标代码的编译器(IR-to-target-code compiler)

      也叫做编译器的“后端”。但因为这部分编译器经常被叫做“JIT”编译器,所以单独拿出来写

      JIT style compiler: “just-in-time编译”狭义的定义是“即时编译”,也就是在某段代码即将第一次被执行时才对其编译。太早或太迟都不符合这个狭义版定义。所谓“JIT风格的编译器”通常意味着“编译是同步进行的”。这就自然的引出几个特征:

    1. 编译速度必须很快;

    2. 编译只能做有限的优化,只能选效费比高的来做。

    optimizing compiler

    • 多层编译(tiered compilation)

    • 后台编译(background compilation)

    • 类型反馈(type feedback)

    • 类型特化(type specialization)

    • SSA-form IR

    自动内存管理

    • 分代式GC(generational GC)

    • 增量式GC(incremental GC)

    • 并发式GC(concurrent GC)

    • 准确式GC(exact / accurate / type exact / type accurate / precise GC)

    对象布局

    • 紧凑对象布局 + 隐藏类

    值表现形式

    • tagger-pointer 或 tagged-value

    • NaN-boxing

    运行时系统

    • inline-cache

    • on-stack replacement

    • deoptimization

    • 用native stack实现VM stack

    • cons-string 或者叫 rope 来优化字符串拼接

    • dependent string/sliced string 来优化字符串的子串操作

    • sparse array

    • B-tree

    上面介绍的JavaScript引擎实现技巧也影响了“如何写出更高效的JavaScript代码”:尽量让代码的行为符合JavaScript引擎的猜测,效率就会高。

    写类型稳定的代码

    • 在构造器函数里声明和初始化所有属性

    • 尽量不要delete属性;不要通过delete属性来把某个属性重置,赋值为undefined都好

    • 不要把数组当一般对象用;不要把一般对象当数组用

    参考内容:

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




    转载本站文章《JS引擎(1):JS引擎擂台赛,JavaScript引擎的特征比较及术语科普》,
    请注明出处:https://www.zhoulujun.cn/html/webfront/browser/webkit/2020_0718_8522.html