bytecodealliance / bytecodealliance/wasmtime
Investigate adding a "fast init" function for initializing the `VMContext`
- Dominant language
- Rust
- Stars
- 18.6k
- Forks
- 1.8k
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 121
Description
In #13487 support was added to initialize a wasm instance's "complicated" globals, tables, memories, etc. This, in theory, can go even further, however, and we could JIT initialization of an instance's `VMContext` itself. Right now `vm::Instance::initialize_vmctx` is a very branch-y and complicated function. This low-level initialization additionally doesn't need anything like fuel checks, epochs, a wasm stack, etc. Ideally we could split module initialization in two:
* A "fast" function which has a custom native ABI generated by Cranelift which initializes the `VMContext`. The signature of this function need not be related to wasm (could take native pointers) and need not be connected to things like `VMFuncRef` for example. This could largely just be a function pointer emitted by Cranelift which is virtually dispatched to during instantiation
* A "slow" function which is implemented in #13487 for full wasm initialization which needs fuel, epochs, a custom stack, etc. This function could trap (unlike the "fast" function), and is that the "module startup" is after #13487.
This in theory might make module instantiation even faster after #13487 since `initialize_vmctx` would be a JIT'd function rather than a generic one-size-fits-all function with lots of branches. Benchmarking TBD!
Contributor guide
Assessment
This issue has not been assessed yet.