Stream: git-wasmtime

Topic: wasmtime / issue #7652 Execute compilation step in Wasm

view this post on Zulip Wasmtime GitHub notifications bot (Dec 07 2023 at 08:20):

adambratschikaye opened issue #7652:

At DFINITY we've been looking into running the Wasmtime compilation of Wasm modules within Wasm itself (for sandboxing and determinism). It looks like we won't be able to use it at the moment because the performance hit is too large given that we lose the option to compile functions in parallel. But I have a rough POC with the changes needed to make this work and we were wondering if you'd be interested in merging them anyway, since it would be a pretty cool property of Wasmtime. There's still some cleanup needed and I'd be happy to help with that.

There's a more detailed description of the changes at the link provided, but most of it was just refactoring so that the functions Config::build_compiler and Module::build_artifacts can be compiled to wasm32 targets.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 07 2023 at 10:08):

ulan commented on issue #7652:

@alexcrichton, @tschneidereit: ^ this is the result of exploring the idea you mentioned here: https://github.com/bytecodealliance/rfcs/pull/32#issuecomment-1740930345

view this post on Zulip Wasmtime GitHub notifications bot (Dec 08 2023 at 16:39):

alexcrichton commented on issue #7652:

Thanks for working forward on this, and it's great to see something already up and running!

I've skimmed over the changes you've made and they're all looking reasonable to me. I'd personally prefer though to have a different trajectory for integrating a change like this in the sense that I already feel like we have too many internal crates and I'd prefer to move towards consolidating them instead of proliferating them. In that sense I'd prefer to not add new wasmtime-jit-runtime or wasmtime-compile crates but instead control this all through Cargo features of the wasmtime crate if possible.

Cargo features provides a good way in my mind to think about this and continue development of it into the future. It means that the Wasmtime CLI, for example, could be itself compiled to WebAssembly so long as everything except the compile command were disabled. The output of compile would be usable by Wasmtime of the same version though. Reducing the number of crates additionally helps keep things a bit more maintainable internally I think since there's less of a question of what-goes-where.

Organizationally what I'd recommend is to move all target-agnostic things, such as wasmtime_jit::ObjectBuilder, into wasmtime-environ. The wasmtime-environ crate already actually compiles to WebAssembly and is used by jco. In that sense the wasmtime-environ crate is a suitable location for "stuff things here that compile everywhere and have no system dependencies". I think that the wasmtime-compile and wasmtime-jit-runtime crates could probably be merged into wasmtime-environ. One day I'd like to merge the {wasmtime-runtime, wasmtime-jit, wasmtime} crates if possible since I don't think we're getting much mileage from the distinction right now.

I've also been wondering a bit about the threading issue you mention since I think that's important to solve. One initial way I was thinking it might be solved was explicit threading on the host, for example no shared state and a Store-per-thread where the embedder orchestrates the threads and calls cranelift once-per-function. Wiring this all up I don't think is that feasible though since it would be exposing a lot of internals of Wasmtime which wouldn't be great.

Alternatively though one option would be the wasm32-wasi-threads target. While I haven't tested it myself I think that the rayon crate should work there so in theory wasmtime run -S threads wasmtime.wasm compile ... should "just work" and have internal parallelism. That would then also work from an embedder point of view assuming you wouldn't use the literal CLI itself.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 08 2023 at 16:43):

bjorn3 commented on issue #7652:

wasm32-wasi-threads doesn't work with the wasi-preview2 based wasi-preview1 implementation in wasmtime, right?

view this post on Zulip Wasmtime GitHub notifications bot (Dec 08 2023 at 16:45):

alexcrichton commented on issue #7652:

Correct, yeah, that's tracked by https://github.com/bytecodealliance/wasmtime/issues/7551.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 11 2023 at 14:51):

adambratschikaye commented on issue #7652:

Regarding merging the crates and using features, what would you think about the following steps?:

  1. Move everything target agnostic from wasmtime-jit to wasmtime-environ.
  2. Move the remaining parts of wasmtime-jit into wasmtime and remove wasmtime-jit.
  3. Put everything target specific in wasmtime under a feature, such that we can compile it to wasm32 if that feature isn't enabled.

I'm not sure how messy step 3 would end up being. Maybe it would be easier to move the parts of wasmtime required for compilation from wasmtime to wasmtime-environ instead of 3?

view this post on Zulip Wasmtime GitHub notifications bot (Dec 11 2023 at 15:51):

alexcrichton commented on issue #7652:

Step 1/2 sound good to me.

For step 3 I agree things may get a bit messy. One possibility though is we could have:

The final crate structure of types like wasmtime::Instance would be the same but everything would be defined under crates/wasmtime/src/runtime/store.rs for example. I'd personally prefer to slurp things into the wasmtime crate rather than the other way around, but not at the cost of large contortions so if you find it's too difficult to go that direction I think it's reasonable to move agnostic things into wasmtime-environ.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 12 2023 at 08:28):

adambratschikaye commented on issue #7652:

Sounds good, I'll give it a try.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 29 2024 at 20:16):

adambratschikaye closed issue #7652:

At DFINITY we've been looking into running the Wasmtime compilation of Wasm modules within Wasm itself (for sandboxing and determinism). It looks like we won't be able to use it at the moment because the performance hit is too large given that we lose the option to compile functions in parallel. But I have a rough POC with the changes needed to make this work and we were wondering if you'd be interested in merging them anyway, since it would be a pretty cool property of Wasmtime. There's still some cleanup needed and I'd be happy to help with that.

There's a more detailed description of the changes at the link provided, but most of it was just refactoring so that the functions Config::build_compiler and Module::build_artifacts can be compiled to wasm32 targets.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 29 2024 at 20:16):

adambratschikaye commented on issue #7652:

I think we can close this as https://github.com/bytecodealliance/wasmtime/pull/7766 is merged.

Last updated: Dec 23 2024 at 12:05 UTC