mar*_*lin 4 javascript google-chrome v8
在https://v8.dev/docs/ignition上,我们可以看到:
Ignition是使用TurboFan后端编写的基于寄存器的快速底层解释器
在https://docs.google.com/document/d/11T2CRex9hXxoJwbYqVQ32yIPMh0uouUZLdyrtmMoL44/edit?ts=56f27d9d#
Ignition项目的目的是为V8构建一个解释器,该解释器执行一个低级字节码,从而使运行一次或非热码以字节码形式更紧凑地存储。
解释器本身由一组字节码处理程序代码片段组成,每个片段均处理特定的字节码,并分派给下一个字节码的处理程序。这些字节码处理程序
为了将函数编译为字节码,将对JavaScript代码进行解析以生成其AST(抽象语法树)。BytecodeGenerator遍历此AST,并根据需要为每个AST节点生成字节码。
生成字节码处理程序的图形后,该图形将通过Turbofan管道的简化版本传递,并分配给解释器表中的相应条目。
因此,似乎点火工作是将BytecodeGenerator生成的字节码转换为字节码处理程序,然后通过执行Turbofan
。
您可以看到是点火产生了字节码。
此外,在此视频中https://youtu.be/p-iiEDtpy6I?t=722点火被称为基准编译器。
那是什么 基准编译器?字节码解释器?AST转换为字节码转换器?
在这里,点火只是一个解释器,之前的一切都是无名的字节码生成器/优化器。
V8 开发人员在这里。
在https://v8.dev/docs/ignition我们可以看到:
Ignition 是一个使用 TurboFan 后端编写的基于寄存器的快速低级解释器
是的,这就是总结。要添加更多细节:
一旦生成了字节码处理程序的图形,它就会通过 Turbofan 管道的简化版本并分配给解释器表中的相应条目。
因此,Ignition 的工作似乎是将 BytecodeGenerator 生成的字节码转换为字节码处理程序并通过 Turbofan 执行它
设计文档的这一部分讨论了使用 Turbofan 的一部分“提前”(即编译 V8 时)生成字节码处理程序。在运行时,字节码不会转换为处理程序,它由现有的固定处理程序集“处理”(=运行、执行、解释),并且不涉及 Turbofan。
更重要的是,在这个视频https://youtu.be/p-iiEDtpy6I?t=722 中, Ignition 据说是一个基线编译器。
在那一刻,谈话指的是所有现代 JavaScript 引擎都有一个“基线编译器”的一般想法(在非常笼统的概念上——我同意幻灯片可以更清楚地说明这一点)。请注意,幻灯片并未提及 Ignition。在接下来的幻灯片说,点火填补了V8发动机的作用。所以更准确的说法是“Ignition代替了基线编译器”或“Ignition 是一个基线执行引擎”。或者您可以稍微重新定义您的术语并说“Ignition 是一个生成字节码然后解释它的编译器”。
点火只是一个解释器,之前的一切都是无名字节码生成器/优化器
该幻灯片将“解释器”框显示为“Ignition Bytecode Pipeline”的一部分。字节码生成器/优化器也是 Ignition 的一部分。
正如我在评论中提到的那样,令人遗憾的是有些文档已经过时,包括上面带有您的第一张图的文档。Full-codegen和Crankshaft 完全不再使用,它只是解析和Ignition + TurboFan。 (您已经从过时的文档中删除了该图片,但遗憾的是某些V8文档仍链接了该图片)
点火是一种高速字节码解释器。
V8的解析器生成点火字节码。该字节码由点火执行(解释)。仅运行一次(启动代码等)或未运行的代码通常停留在字节码级别,并继续由Ignition执行。
“热”代码进入第二阶段,在此阶段TurboFan进入:TurboFan的输入与Ignition解释的字节码相同(而不是与Crankshaft相同的源代码),然后它积极地编译为运行的高度优化的机器代码。直接(而不是被解释)。
本文探讨了退出Full-codegen和Crankshaft的动机(在前一种情况下节省内存,在第二种情况下难以实现,尤其是优化语言功能)。TurboFan的设计还帮助V8作者最大程度地减少了必须编写的特定于平台的代码量(通过具有中间表示形式,他们还可以用来编写Ignition的字节码处理程序)。
归档时间: |
|
查看次数: |
331 次 |
最近记录: |