This commit exposes some various details and config options for having finer-grain control over mlock-ing the memory of modules. This amounts to three different changes being present in this commit: * A new `Module::image_range` API is added to expose the range in host memory of where the compiled image resides. This enables embedders to make mlock-ing decisions independently of Wasmtime. Otherwise though there's not too much useful that can be done with this range information at this time. * A new `Config::force_memory_init_memfd` option has been added. This option is used to force the usage of `memfd_create` on Linux even when the original module comes from a file on disk. With mlock-ing the main purpose for Wasmtime is likely to be avoiding major page faults that go back to disk, so this is another major source of avoiding page faults by ensuring that the initialization contents of memory are always in RAM. * The `memory_images` field of a `Module` has gone back to being lazily created on the first instantiation, effectively reverting #3914. This enables embedders to defer the creation of the image to as late as possible to allow modules to be created from precompiled images without actually loading all the contents of the data segments from disk immediately. These changes are all somewhat low-level controls which aren't intended to be generally used by embedders. If fine-grained control is desired though it's hoped that these knobs provide what's necessary to be achieved.
Wasmtime Embedding API
The wasmtime crate is an embedding API of the wasmtime WebAssembly runtime.
This is intended to be used in Rust projects and provides a high-level API of
working with WebAssembly modules.
If you're interested in embedding wasmtime in other languages, you may wish to
take a look a the C embedding API instead!