Stream: git-wasmtime

Topic: wasmtime / Issue #1779 Ability to get and load compilatio...

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2020 at 14:10):

dsherret opened Issue #1779:

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("Expect 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.

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2020 at 14:11):

dsherret edited Issue #1779:

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.

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2020 at 14:27):

alexcrichton labeled Issue #1779:

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.

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2020 at 14:27):

github-actions[bot] commented on Issue #1779:

Subscribe to Label Action

cc @peterhuene

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

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

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

Learn more.
</details>

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2020 at 15:33):

alexcrichton commented on Issue #1779:

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?

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2020 at 15:39):

dsherret commented on Issue #1779:

@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.

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2020 at 15:43):

alexcrichton commented on Issue #1779:

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.

view this post on Zulip Wasmtime GitHub notifications bot (May 29 2020 at 01:52):

dsherret commented on Issue #1779:

@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).

view this post on Zulip Wasmtime GitHub notifications bot (Jun 12 2020 at 18:03):

yurydelendik assigned Issue #1779:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 17 2020 at 17:38):

yurydelendik commented on Issue #1779:

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

view this post on Zulip Wasmtime GitHub notifications bot (Jul 21 2020 at 20:05):

yurydelendik closed Issue #1779 (assigned to yurydelendik):

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.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 21 2020 at 20:23):

dsherret commented on Issue #1779:

@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.

Last updated: Oct 23 2024 at 20:03 UTC