Skip to content

Refactor the interpreter module instance layout #1384

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wenyongh opened this issue Aug 12, 2022 · 0 comments
Closed

Refactor the interpreter module instance layout #1384

wenyongh opened this issue Aug 12, 2022 · 0 comments
Labels
done The feature/issue was implemented/resolved enhancement New feature or request

Comments

@wenyongh
Copy link
Contributor

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
@wenyongh wenyongh added the enhancement New feature or request label Aug 12, 2022
@wenyongh wenyongh mentioned this issue Sep 16, 2022
Merged
wenyongh added a commit that referenced this issue Sep 19, 2022
@wenyongh
Unify wasm module instance and aot module instance (#1495)
58bbb7c 
Unify the data structure of wasm module instance and aot module instance:
- Use the same structure WASMModuleInstance for both interpreter and AOT
- For the extra fields, store them into WASMModuleInstanceExtra structure and
  add a field `e` in module instance
- For field which has different meaning for interpreter and AOT, use the structure
  of interpreter to define it, and convert it to actual type in AOT before using it

Refer to #1384.
@wenyongh wenyongh mentioned this issue Sep 19, 2022
Merged
@wenyongh wenyongh added the WIP working in progress label Sep 24, 2022
wenyongh added a commit that referenced this issue Sep 26, 2022
@wenyongh
Merge some APIs of interp and AOT modes (#1509)
8f9892d 
Refer to #1384.
To unify the memory instantiate process for interpreter/AOT in the future.
@wenyongh wenyongh mentioned this issue Sep 28, 2022
Merged
@wenyongh wenyongh mentioned this issue Oct 6, 2022
Merged
wenyongh added a commit that referenced this issue Oct 18, 2022
@wenyongh
Refactor interpreter/AOT module instance layout (#1559)
a182926 
Refactor the layout of interpreter and AOT module instance:
- Unify the interp/AOT module instance, use the same WASMModuleInstance/
  WASMMemoryInstance/WASMTableInstance data structures for both interpreter
  and AOT
- Make the offset of most fields the same in module instance for both interpreter
  and AOT, append memory instance structure, global data and table instances to
  the end of module instance for interpreter mode (like AOT mode)
- For extra fields in WASM module instance, use WASMModuleInstanceExtra to
  create a field `e` for interpreter
- Change the LLVM JIT module instance creating process, LLVM JIT uses the WASM
  module and module instance same as interpreter/Fast-JIT mode. So that Fast JIT
  and LLVM JIT can access the same data structures, and make it possible to
  implement the Multi-tier JIT (tier-up from Fast JIT to LLVM JIT) in the future
- Unify some APIs: merge some APIs for module instance and memory instance's
  related operations (only implement one copy)

Note that the AOT ABI is same, the AOT file format, AOT relocation types, how AOT
code accesses the AOT module instance and so on are kept unchanged.

Refer to:
#1384
@wenyongh wenyongh mentioned this issue Oct 18, 2022
Merged
@wenyongh wenyongh added done The feature/issue was implemented/resolved and removed WIP working in progress labels Nov 3, 2022
@wenyongh wenyongh closed this as completed Nov 3, 2022
vickiegpt pushed a commit to vickiegpt/wamr-aot-gc-checkpoint-restore that referenced this issue May 27, 2024
@wenyongh
Refactor interpreter/AOT module instance layout (bytecodealliance#1559)
6fb2326 
Refactor the layout of interpreter and AOT module instance:
- Unify the interp/AOT module instance, use the same WASMModuleInstance/
  WASMMemoryInstance/WASMTableInstance data structures for both interpreter
  and AOT
- Make the offset of most fields the same in module instance for both interpreter
  and AOT, append memory instance structure, global data and table instances to
  the end of module instance for interpreter mode (like AOT mode)
- For extra fields in WASM module instance, use WASMModuleInstanceExtra to
  create a field `e` for interpreter
- Change the LLVM JIT module instance creating process, LLVM JIT uses the WASM
  module and module instance same as interpreter/Fast-JIT mode. So that Fast JIT
  and LLVM JIT can access the same data structures, and make it possible to
  implement the Multi-tier JIT (tier-up from Fast JIT to LLVM JIT) in the future
- Unify some APIs: merge some APIs for module instance and memory instance's
  related operations (only implement one copy)

Note that the AOT ABI is same, the AOT file format, AOT relocation types, how AOT
code accesses the AOT module instance and so on are kept unchanged.

Refer to:
bytecodealliance#1384
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
done The feature/issue was implemented/resolved enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@wenyongh