Motivation

Due to history reason, the current module instance layout (and module layout) of interpreter and AOT are different, which causes some inconveniences:

• The interpreter module instance cannot be accessed by AOT code, and the AOT module instance cannot be accessed by interpreter code. It cannot meet some requirements, e.g. in the Multi-tier JIT plan, it is suppose to tier-up from the Fast JIT into the LLVM JIT, the module instance created by interpreter should be allowed to be accessed by LLVM JIT.
• There are two similar source code copies to access the interpreter module instance and aot module instance respectively, which increases the maintain burden.
• The AOT module instance layout is optimized for performance purpose, if the interpreter module instance can be the same, normally we can benefit from it in accessing the memory/global/table data, e.g. for Fast JIT.

So for the new feature development, for the code maintain and for the performance, we need to refactor the module instance layout.

Refactor strategy

As the AOT calling convention is currently used, we had better keep AOT module instance layout, so the current AOT machine code in AOT file can access the AOT module instance correctly (some field offsets are compiled into constant offsets in AOT code). So we decided to refactor the interpreter module instance layout.
And as it is a big risk and it will take lot of efforts to refactor both the interpreter module instance layout and the interpreter module layout, we decided to only refactor the interpreter module instance layout in the first stage.

The main changes

• The data structures of WASMMemoryInstance, WASMTableInstance, WASMModuleInstance and so on. The layout of wasm module instance will be refactored to be like AOT module instance:
  • The memory instance structure, the global data, the table instance structure are to be appended at the end of WASMModuleInstance structure while the latter is created.
• The related APIs in interpreter
• The Fast JIT frontend