Ability to get and load compilation result bytes

[dsherret]

Feature

It would be useful to be able to get the bytes from a compilation result and additionally take bytes from a previous compilation and load them into a module.

Benefit

This would allow me to manage my own caching and reduce startup times.

Implementation

Here's how it's done in wasmer.

Compiling:

let compile_result = wasmer_runtime::compile(&wasm_bytes)?;
let artifact = compile_result.cache();
let compiled_module_bytes = artifact.unwrap().serialize().unwrap();

Loading:

let artifact = match wasmer_runtime::cache::Artifact::deserialize(&compiled_module_bytes) {
    Ok(artifact) => artifact,
    Err(err) => { return err!("Error deserializing compiled wasm module: {:?}", err); }
};
let compiler = wasmer_runtime::compiler_for_backend(wasmer_runtime::Backend::default()).expect("Expected to have a compiler");
let module = unsafe { wasmer_runtime_core::load_cache_with(artifact, &*compiler).unwrap() };
let import_object = wasmer_runtime::imports! {};
let instance = module.instantiate(&import_object)?;

Alternatives

Using the Config::cache_config_load_default is not ideal because it's wasmtime managing a cache for me and it seems I need to keep the .wasm file bytes around.

[github-actions]

Subscribe to Label Action

cc @peterhuene

This issue or pull request has been labeled: "wasmtime:api"

Thus the following users have been cc'd because of the following labels:

• peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[alexcrichton]

Thanks for the report, and seems like a reasonable feature to add to me!

I think for us the APIs this might look like are:

impl Module {
    pub fn deserialize_cache_bytes(store: &Store, bytes: &[u8]) -> Result<Module>;
    pub fn serialize_cache_bytes(&self) -> Vec<u8>;
}

(or something like that)

Our cache format is not currently where we want it to end up. One aspect we'd like for the caches eventually is that you can "mmap and go" with zero changes to what's mmap'd in, but we can probably implement that with something like deserialize_cache_file in the future.

In any case @dsherret would you be willing to work on adding this feature?

[dsherret]

@alexcrichton that API looks perfect to me.

How much work do you think it would be? Is it just hooking up a few things internally to that public api? If so, then sure!

I'm actually not using wasmtime at all, but was just evaluating it and this was a blocker for me.

[alexcrichton]

I think this may be somewhat nontrivial to implement because the code isn't well-structured this way today. Our core caching function would need to be updated to optionally have bytes passed in, or otherwise refactored elsewhere to have "get the bytes" refactored into a separate step.

Overall I don't think it'll be too too difficult of a change, but it will require some refactoring and isn't a simple "just connect the wires" sort of change.

[dsherret]

@alexcrichton thanks for pointing me in the direction of the code. I took a look at it briefly and you're right that it would be a bit non-trivial, but overall doesn't look too bad.

I'm currently dragging my head through the sand with an access violation bug so my brain is kind of fried. I'll maybe come back to this later if I don't make any progress otherwise and want to try using wasmtime... (I'd like to support this project as I really like the idea behind it).

[yurydelendik]

@dsherret there is #2020 about to be landed, can you provide any feedback related to this issue?

[dsherret]

@yurydelendik sorry, I meant to respond. I looked at the public api earlier and it looked good to me! Thanks! I'm not using wasmtime at the moment though.