Trait MemoryCreator

pub unsafe trait MemoryCreator: Send + Sync {
    // Required method
    fn new_memory(
        &self,
        ty: MemoryType,
        minimum: usize,
        maximum: Option<usize>,
        reserved_size_in_bytes: Option<usize>,
        guard_size_in_bytes: usize,
    ) -> Result<Box<dyn LinearMemory>, String>;
}

A memory creator. Can be used to provide a memory creator to wasmtime which supplies host managed memory.

Safety

This trait is unsafe, as the memory safety depends on proper implementation of memory management. Memories created by the MemoryCreator should always be treated as owned by wasmtime instance, and any modification of them outside of wasmtime invoked routines is unsafe and may lead to corruption.

Note that this is a relatively new and experimental feature and it is recommended to be familiar with wasmtime runtime code to use it.

Required Methods

fn new_memory( &self, ty: MemoryType, minimum: usize, maximum: Option<usize>, reserved_size_in_bytes: Option<usize>, guard_size_in_bytes: usize, ) -> Result<Box<dyn LinearMemory>, String>

Create a new LinearMemory object from the specified parameters.

The type of memory being created is specified by ty which indicates both the minimum and maximum size, in wasm pages. The minimum and maximum sizes, in bytes, are also specified as parameters to avoid integer conversion if desired.

The reserved_size_in_bytes value indicates the expected size of the reservation that is to be made for this memory. If this value is None than the implementation is free to allocate memory as it sees fit. If the value is Some, however, then the implementation is expected to reserve that many bytes for the memory’s allocation, plus the guard size at the end. Note that this reservation need only be a virtual memory reservation, physical memory does not need to be allocated immediately. In this case grow should never move the base pointer and the maximum size of ty is guaranteed to fit within reserved_size_in_bytes.

The guard_size_in_bytes parameter indicates how many bytes of space, after the memory allocation, is expected to be unmapped. JIT code will elide bounds checks based on the guard_size_in_bytes provided, so for JIT code to work correctly the memory returned will need to be properly guarded with guard_size_in_bytes bytes left unmapped after the base allocation.

Note that the reserved_size_in_bytes and guard_size_in_bytes options are tuned from the various Config methods about memory sizes/guards. Additionally these two values are guaranteed to be multiples of the system page size.

Memory created from this method should be zero filled.

Implementors