Struct aptos_vm::move_vm_ext::MoveVmExt

pub struct MoveVmExt { /* private fields */ }

Implementations

impl MoveVmExt

pub fn new() -> VMResult<Self>

pub fn new_session<'r, S: MoveResolverExt>(
    &self,
    remote: &'r S,
    session_id: SessionId
) -> SessionExt<'r, '_, S>

Methods from Deref<Target = MoveVM>

pub fn new_session<S>(&self, remote: &'r S) -> Session<'r, '_, S> where
    S: MoveResolver, 

Create a new Session backed by the given storage.

Right now it is the caller’s responsibility to ensure cache coherence of the Move VM Loader

• When a module gets published in a Move VM Session, and then gets used by another transaction, it will be loaded into the code cache and stay there even if the resulted effects do not get commited back to the storage when the Session ends.
• As a result, if one wants to have multiple sessions at a time, one needs to make sure none of them will try to publish a module. In other words, if there is a module publishing Session it must be the only Session existing.
• In general, a new Move VM needs to be created whenever the storage gets modified by an outer envrionment, or otherwise the states may be out of sync. There are a few exceptional cases where this may not be necessary, with the most notable one being the common module publishing flow: you can keep using the same Move VM if you publish some modules in a Session and apply the effects to the storage when the Session ends.

pub fn new_session_with_extensions<S>(
    &self,
    remote: &'r S,
    extensions: NativeContextExtensions<'r>
) -> Session<'r, '_, S> where
    S: MoveResolver, 

Create a new session, as in new_session, but provide native context extensions.

pub fn load_module<S>(
    &self,
    module_id: &ModuleId,
    remote: &'r S
) -> Result<Arc<CompiledModule>, VMError> where
    S: MoveResolver, 

Load a module into VM’s code cache

Trait Implementations

impl Deref for MoveVmExt

type Target = MoveVM

The resulting type after dereferencing.

fn deref(&self) -> &Self::Target

Dereferences the value.