Try to put the Wasmi engine internals into its own crate
Robbepop opened this issue · comments
The wasmi
crate became very large over the recent years with all the added functionality and the new register-machine engine.
While compilation times are not yet an issue we might want to tackle this problem before it becomes one.
Compared with other crates in the Wasmi workspace the wasmi
crate is by far the largest and it would be nice if we could split it up into more smaller crates.
As of today (2024-04-23) the wasmi
crate has approx. 51k LoC without comments while its wasmi::engine
submodule makes up 44k LoC of the total. It should be noted though that 21k LoC of those 44k LoC are pure test code to verify that the Wasm to Wasmi bytecode translation works correctly.
I am not yet sure if this is going to work out but what we could do is to carve out the entire wasmi::engine
module and put it into its own crate. The wasmi
crate would then depend on the new wasmi_engine
crate and use it to drive execution just like the current wasmi
crate uses its internal wasmi::engine
submodule to do so.
This issue tracks progress of this work item and accumulates discussion and feasibility studies.
Problems
One problem is that for host function calls the Engine
needs to be aware of the Store
thus the Store
or its internal implementation should reside in the Engine
too. So what is ultimately left in the wasmi
crate afterwards? Maybe we could move index types such as Func
, Global
etc. to yet some other crate and entity types such as MemoryEntity
could reside in wasmi_engine
or even yet another crate that wasmi_engine
depends on.