Wasmtime GitHub notifications bot (Apr 20 2020 at 16:51): Wasmtime GitHub notifications bot (Apr 20 2020 at 16:51):sunfishcode commented on Issue #1560:
wasmtime-environ is meant to be usable both for JIT and AOT use cases; can you discuss how AOT use cases fit within this refactoring?
Wasmtime GitHub notifications bot (Apr 20 2020 at 17:09):alexcrichton commented on Issue #1560:
Oh sure yeah! So right now I imagine that if you're building an AOT backend then our current organization is probably not what you want. In theory you'd have to separate components, one for compilation and one for consumption of the compiled artifacts. The compiler would depend on cranelift at some point but the execution component would depend on
wasmtime-runtimeand doesn't want cranelift as a dependency. I'm hoping to refactor wasmtime internally to enable this use case.The general idea is that you should be able to statically split the wasmtime world where the runtime half doesn't depend on the compiler half. Currently the "runtime half" is the
wasmtime-runtimecrate which depends onwasmtime-environ(for shared data structures), butwasmtime-environunconditionally depends on codegen backends, making it unsuitable for this purpose.I don't mean to conflate JIT/codegen/etc, and if you'd prefer I can extract all the codegen bits to something like a
wasmtime-codegencrate or something like that.
Wasmtime GitHub notifications bot (Apr 20 2020 at 17:22):sunfishcode commented on Issue #1560:
Yeah, splitting pieces of wasmtime-environ into separate crates sounds good to me. The "environ" in the name is meant to relate to the
FuncEnvironmentandModuleEnvironmenttrait implementations that it contains, so if those move to a different crate,wasmtime-environcould benefit from a new name.
Wasmtime GitHub notifications bot (Apr 20 2020 at 17:41):alexcrichton commented on Issue #1560:
I'm mostly just assuming the original intention for these crates, so I'm likely also misinterpreting things. Today though I think we still need to change something (
wasmtime-runtimeshouldn't transitively depend on cranelift/lightbeam). It sounds like you'd like to keep the code inwasmtime-environseparate fromwasmtime-jit, so we'll need to splitwasmtime-environ. Thewasmtime-runtimecrate would depend on the new crate that doesn't depend on cranelift.Does that sound right? Would you prefer that
wasmtime-environkeep its name and a new crate is split out likewasmtime-typesorwasmtime-coreor something like that?
Wasmtime GitHub notifications bot (Apr 28 2020 at 19:21):alexcrichton commented on Issue #1560:
I think I'll try to tackle this later.
Last updated: Dec 23 2024 at 13:07 UTC