near_vm_runner
has to deal with two distinct UniversalEngines when artifact is already loaded in memory
#10837
Labels
A-contract-runtime
Area: contract compilation and execution, virtual machines, etc
T-contract-runtime
Team: issues relevant to the contract runtime team
In the current runtime whenever we evaluate a function call action, we will create a new instance of the contract runtime engine (e.g.
near_vm::UniveralEngine
.) Normally this is quite alright -- we then load the executable with this engine to obtain aUniversalArtifact
, which represents a loaded but not instantiated wasm module for that runtime.This process of loading the
UniversalArtifact
stores some data withinUniversalEngine
-- things like type descriptors and such.Now in some instances we may want to store some of these
UniversalArtifact
s warmed up in memory ready to instantiate quickly. However that poses a problem -- next time around a new call comes in, we create a newUniversalEngine
, find the artifact within a cache and suddenly the code is dealing with two distinct instances of theUniversalEngine
in the same area of the code.Ideally we get this fixed somehow so that only one
UniversalEngine
of relevance exists at a given time.Good things to explore:
UniversalEngine
s at all? Could we use just one that we create at startup?Artifact
s be self-contained?The text was updated successfully, but these errors were encountered: