v8优化之代码缓存-code caching

简介

  一份JavaScript代码从Blink交给V8开始到执行，经历了解析，编译，运行，优化以及包括GC这些过程。下面这张图展示了V8在运行中实际测量得出的数据


  可以看到解析Parse和编译Complie所花费的时间占到了整个运行周期总时间的三分之一。所以，这是为什么V8需要做code cache,引擎希望尽可能的减少解析和编译所用的时间。其总体思想就是，既然解析和编译花费的时间占据这么大，那么满足一定条件后，V8会把编译和解析的结果缓存下来，等到下次遇到相同的文件，直接跳过这个过程，把直接缓存好的数据拿来使用。如果你熟悉HTTP，你会发现这个过程和HTTP缓存如出一辙。
  首先，我们先来介绍下，什么是code cache以及它的的实现过程。
  目前在V8中实现了两种code cache方案，分别是isolate caches（隔离缓存），以及Resourse cache（资源缓存）。前者是储存在内存中，后者保存在计算机的硬盘上。下面将分别介绍它们。

isolate caches in V8

隔离缓存位于内存中，如果你了解过chrome架构中的站点隔离（site isolation），你应该大致想得到这种缓存所面向的适用对象。
该缓存以hashtable的形式存在V8的堆中。它的储存结构如下：
                
  在这个结构中，用源码作为key，编译后生成的数据（字节码）作为对应的值。

  下面来看下简单的运行过程：

• 当V8编译一个脚本文件，V8首先会用脚本源码去检索缓存的hashtable中是否存在相同key的对象，如果存在，直接返回已经存在的字节码。否则，V8正常进行编译，并将编译后生成的字节码储存在缓存的hashtable中（V8分配的堆内存上），由脚本的源代码作为key。

  根据观察得出的结论，这种缓存技术在real world的网页中能够达到80%的命中率。并且由于这种缓存直接存在于内存中，所以它的速度会比接下来介绍的第二种快很多。

  但是隔离缓存有一个很严重的问题，是关于tab。如果你有两个标签页，它们都加载了一份相同的脚本文件（指向同一个URL），比如a.js。在第一个标签页已经将a.js缓存到了堆上的hashtable中后，
  第二个标签页开始去加载a.js。由