You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
This has been implemented in parts by #1152 and #1184.
At this point I am not sure how (technically) viable it is to move even more parts of the engine submodule into their own crates.
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 itswasmi::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. Thewasmi
crate would then depend on the newwasmi_engine
crate and use it to drive execution just like the currentwasmi
crate uses its internalwasmi::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 theStore
thus theStore
or its internal implementation should reside in theEngine
too. So what is ultimately left in thewasmi
crate afterwards? Maybe we could move index types such asFunc
,Global
etc. to yet some other crate and entity types such asMemoryEntity
could reside inwasmi_engine
or even yet another crate thatwasmi_engine
depends on.The text was updated successfully, but these errors were encountered: