Qtum量子链研究院：Qtum x86虚拟机的内存映射

本文是x86虚拟机系列文档，供Qtum量子链团队成员以及所有感兴趣的用户阅读。

与EVM不同的是，在x86架构中内存使用是不连续的，内存中可能存在空白段。例如，访问0x1000处的内存可能会导致错误，因为该段内存没有被分配，但是在0x2000处可能有一些有用的内容。实际上，大多数虚拟机和CPU架构都把这作为其优势，所以EVM的内存使用方式是比较少见的。在1Mb内存还不常见的时代，8086曾规定的大多数内存都从0开始，而只读BIOS内存位于0xF0000，有时一部分内存实际上被连接到外部设备而不是RAM。

Qtum x86 虚拟机设计也运用了这个特性，以便实现某些内存区域可以共享的特性。

注意，各内存块可以在第一次读取时再进行初始化。即在合约需要读取数据之前，没有必要为某个内存块构造数据。首次访问类似的内存区域可能还需要额外的gas费用。

发生double-fault 异常时使用的应急堆栈。暂不使用，因为异常处理暂未支持。

实际加载合约代码的内存区域。出于安全性和后续优化考虑，该内存区域设置为只读。实际的大小取决于加载的合约代码大小。超出实际大小的内存只能读取不能写入，且值恒为0。

加载合约数据的内存区域。与EVM不同的是，对于变量， 无需CPU代码指定预留内存并将其设置为该变量的值。x86中的变量只是一个指向内存地址的简单指针。加载器（loader，在普通的操作系统中对应解析器和加载器，在Qtum中，对应虚拟机的初始化进程）通过这一地址获取变量值。这在实际中非常有用，因为我们可以使用高效的原生代码 （如“memcpy”）一次性完成所有变量的初始化。变量指针最终指向该内存区域。其实际大小暂定为1Mb，但在x86虚拟机原型发布之后有可能进行调整。

请注意，只读数据(取决于链接器配置)存储在代码区域。普通程序中的只读数据包括字符串、常量等。

为x86调用栈保留的内存区域。调用栈用于向函数传递参数、存储返回地址、本地变量等。之所以将其他数据和栈数据进行隔离，是因为该内存区域前后都是无效内存。也就是说，一旦栈发送溢出，将很容易被检测到，因为这将导致抛出错误。显式的抛出错误在大多数情况下都比带着错误继续运行要好得多。

只读数据，且对于每个合约调用都是特定的。这意味着当在合约中调用合约时，数据将是不同的。这些数据包括发送者地址(发起合约调用的地址)、gas limit和其他数据等。

动态长度数据，编码了触发此次合约调用的完整交易数据（包括交易的所有输入输出）。其中既包含了原始脚本的访问，也包含了诸如“发送了100 token到A地址”这样方便使用的数据。关于脚本的解析，qtum-x86会提供相关的辅助库函数。

只读的全局区块链数据，对于当前区块中的所有合约为常量。包括区块的gas limit，当前区块高度，之前区块的哈希值，当前挖矿难度等数据。

设计初衷

之所以令上述数据可直接从内存获取，而不是通过系统调用（syscall），其主要原因有两个:

l 系统调用都有不可忽视的安全风险

l 系统调用在合约代码大小、合约代码gas消耗以及虚拟机实现速度等方面，开销都比较大；

每个系统调用都是一个暴露合约代码的接口，大多数操作系统内核安全漏洞来自系统调用中的bug。因此，应尽量少地将系统调用暴露给虚拟机 ，减少安全风险。

系统调用过程总体开销较大，主要体现在以下几个方面。首先，代码虽然不大，但不可忽略。用C语言进行一次系统调用至少需要30字节，其他语言也需要或多或少的消耗内存。其次，系统调用过程中开销最大的部分在于需要在系统调用和标准C接口间进行翻译，这涉及调用帮助函数，预留寄存器，从堆栈中获取数据并将它们存储在寄存器中，执行系统调用，以及最终恢复寄存器等一系列过程。上面提到的30字节只包含帮助函数部分。实际执行的总字节数明显更多，但并没有表现在合约代码尺寸中，因为该代码只编写一次，并用于每个系统调用。

最后，除合约本身的效率问题外，每个系统调用都有可能影响虚拟机的性能。在JIT工作流中，虽然硬件CPU可以快速地缓存JIT代码和JIT编译过的合约代码，但是在离开该内存区域去运行另一段代码时，通常必须至少先清除一部分缓存，为新代码腾出空间。在一个真正使用硬件支持的虚拟化工作流中，这类操作的开销会更大，因为它可能涉及上下文切换和硬件级系统调用。这是大多数需要在虚拟机中运行的语言遇到的常见问题，包括Webassembly(据本人了解，最近Webassembly团队才在某种程度上做了一些重大改进)，Javascript/V8等等。

Qtum x86仍处在原型开发中，故本文所述的内存映射设计与最终版本可能有出入。感兴趣的读者请持续关注包括本文在内的x86系列设计文档。