alexcrichton opened issue #13502:
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
VMContextitself. Right nowvm::Instance::initialize_vmctxis 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 likeVMFuncReffor 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_vmctxwould be a JIT'd function rather than a generic one-size-fits-all function with lots of branches. Benchmarking TBD!
Last updated: Jun 01 2026 at 09:49 UTC