利用wasm的jit加速功能对代码进行加速

wasm代码的运行一共有三种模式。最早的有两种：binaryen模式和wavm模式。最近还加了一种叫wabt的基于栈的bytecode模式。

binaryen模式是基于bytecode的解释器的。而wavm模式是基于JIT的，速度可以达到运行native code的级别。但是wavm模式有一个致命的硬伤：JIT时编译速度太慢。以编译源代码里的eosio.system这个系统智能合约为例，需要5秒左右的时间。这已经不是慢的问题的，而是在每个块0.5秒的情况下，已经根本无法满足需求了。另外，现在的wavm模式占用的内存比较大，大得让大部分的智能合约的发布者无法承受，所以，除非是后面wavm模式有比较大的优化，要不然，在目前情况下，直接给wavm模式的大量使用宣判了死刑。

那说了这么多，wavm模式还有什么用呢？

其中一个作用是在replay的时候加快replay的速度。但是这会占用大量额外的内存。

还有一个作用是给特权级别的合约进行加速。最常用的就是eosio.token和eosio.system这两个合约。

另外，wavm JIT模式虽然不能被大量使用，但是可以把它定义为一种稀缺资源。像短帐户名称一样通过竞价的方式来获取。另一种更为简单的的方式就是就是让智能合约的账户来承担wavm JIT模式下的额外内存费用。

说了wavm JIT加速的应用场景，接下来就是实现的问题了。由于wavm JIT加速模式的加载时间比较长，所以必须采用异步加载的模式。在加载过程中，合约可以运行在wabt这种解释器的模式之下。

但是上面的方法还是要解决一个问题。就是wasm的代码目前只支持单线程运行，另外，由于wasm的设计问题，并不支持wavm和wabt两种模式的共存。也就是说，在程序的初始化的过程中必须指定一种运行模式，wabt模式或者wavm模式。但是在程序跑起来后，就只能以wabt模式或者wavm模式运行了，否则会因为内存冲突导致程序的崩溃。这个问题也应该是后面Eos的要面对的一个问题。PyEos的解决办法是采用将相同的代码编译成两个动态库，这两个动态库是不会共享内存的，从而解决了wavm模式和wabt模式下内存冲突导致程序崩溃的问题。

实现的代码在如下的路径：libraries/vm/vm_wasm，感兴趣的可以找到代码研究下，这里就不展开了。